ing compaction can trigger schema migration and deadlock
> the system
> ---
>
> Key: PHOENIX-4537
> URL: https://issues.apache.org/jira/browse/PHOENIX-4537
>
Exception like happens client-side)?
> RegionServer initiating compaction can trigger schema migration and deadlock
> the system
> ---
>
> Key: PHOENIX-4537
> URL
;t
initiate the migration if it's set.
> RegionServer initiating compaction can trigger schema migration and deadlock
> the system
> ---
>
> Key: PHOENIX-4537
>
em that I see there is that in our code we mostly rely on the
configuration property, but not the actual state of the system tables, so I
expect that something else may not work correctly.
> RegionServer initiating compaction can trigger schema migration and deadlock
r it
comes from client or server. I have explicitly looked at this code in
ConnectionQueryServicesImpl and confirmed that this is how it works ("intent"
of how it is meant to work aside). We are in agreement that schema migration of
the System tables does not happen on Connections init
oked at this code in
ConnectionQueryServicesImpl and confirmed that this is how it works ("intent"
of how it is meant to work aside). We are in agreement that schema migration of
the System tables does not happen on Connections initiated from the server.
bq. If we're going to go t
);
}
{code}
Sounds like we need a bit more discussion on this one before committing given
the comfort level, [~elserj]. What about the idea I outlined above of doing
PHOENIX-4530 and removing the clearTsOnDisabledIndexes altogether?
> RegionServer initiating compaction can trigger sch
exes altogether?
> RegionServer initiating compaction can trigger schema migration and deadlock
> the system
> ---
>
> Key: PHOENIX-4537
> URL: https://issues.apache.o
nd I agree with you. Treating as separate issues seem best to me.
Let me add a comment to this change in the Observer and then I'll commit.
Thanks!
> RegionServer initiating compaction can trigger schema migration
egionServer initiating compaction can trigger schema migration and deadlock
> the system
> ---
>
> Key: PHOENIX-4537
> URL: https://issues.apache.org/jira/browse/PHOENI
an IT for this, but I have reproduced the
problem locally and verified that this fix addresses the issue.
[~jamestaylor], [~sergey.soldatov], [~an...@apache.org], you guys think this is
good to go?
> RegionServer initiating compaction can trigger schema migration and deadlock
this tonight, but I haven't been successful
in reproducing the problem. I'm not sure why it wouldn't work -- will have to
try to do it in a real cluster, I guess.
> RegionServer initiating compaction can trigger schema migration and
uld be this deadlock where a compaction gets queued which
keeps the table from becoming disabled (until that RS is taken down)
> RegionServer initiating compaction can trigger schema migration and deadlock
> the system
> ---
xes as it wouldn't be necessary ([~an...@apache.org]
excellent idea). We might need to start adding secondary indexes to system
tables, so I'd hate to have too many assumptions here.
> RegionServer initiating compaction can trigger schema migration and
t in our documentation, we are saying
that the migration would happen on the first connection
Yeah, agreed.
[~jamestaylor], don't want to misinterpret the silence, but how does this
approach strike you?
> RegionServer initiating compaction can trigger schema migration and deadlock
e is that in our documentation, we are saying that
the migration would happen on the first connection. That might surprise the end
user that it actually happens without his involvement.
> RegionServer initiating compaction can trigger schema migration and deadlock
>
r won't upgrade system tables, it
> *will* try to migrate them into the schema mapped variants (e.g.
> SYSTEM.CATALOG to SYSTEM:CATALOG).
> However, one of the first steps in the schema migration is to disable the
> SYSTEM.CATALOG table. However, the SYSTEM.CATALOG table can&
[
https://issues.apache.org/jira/browse/PHOENIX-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned PHOENIX-4537:
---
Assignee: Josh Elser
> RegionServer initiating compaction can trigger schema migration
will
break badly otherwise?
Let me try to put this together.
> RegionServer initiating compaction can trigger schema migration and deadlock
> the system
> ---
>
> Key: PHOENIX-4537
&g
ion can trigger schema migration and deadlock
> the system
> ---
>
> Key: PHOENIX-4537
> URL: https://issues.apache.org/jira/browse/PHOENIX-4537
> Project:
ilva]
> RegionServer initiating compaction can trigger schema migration and deadlock
> the system
> ---
>
> Key: PHOENIX-4537
> URL: https://issues.apache.org/ji
tem tables, it
*will* try to migrate them into the schema mapped variants (e.g. SYSTEM.CATALOG
to SYSTEM:CATALOG).
However, one of the first steps in the schema migration is to disable the
SYSTEM.CATALOG table. However, the SYSTEM.CATALOG table can't be disabled until
the region is CLOSED,
Josh Elser created PHOENIX-4537:
---
Summary: RegionServer initiating compaction can trigger schema
migration and deadlock the system
Key: PHOENIX-4537
URL: https://issues.apache.org/jira/browse/PHOENIX-4537
Hi all
Do you guys had any info/ideas/discussions about anything regarding schema
migration tooling for the PHOENIX ?
What you guys use now?
Any preferable direction like http://flywaydb.org/ or
http://www.liquibase.org/ or anything else?
Since PHOENIX seats on top of hbase should we possibly
24 matches
Mail list logo
