[
https://issues.apache.org/jira/browse/PHOENIX-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16237181#comment-16237181
]
Sergey Soldatov commented on PHOENIX-4328:
------------------------------------------
my 2 cents. I think that migration should be a part of upgrade tool rather than
running automatically when the first client is connected. And server in
checkClientServerCompatibiltiy should set the state whether namespace mapping
is enabled to real state (so if upgrade didn't happen yet, return false) but
not the value that is in the hbase-site.xml.
As for the retry mechanism on table not found we may call
checkClientServerCompatibility again as we do for ensureTableCreated. If the
value has not been changed => fail, otherwise => modify the internal property
and retry.
> Support clients having different "phoenix.schema.mapSystemTablesToNamespace"
> property
> -------------------------------------------------------------------------------------
>
> Key: PHOENIX-4328
> URL: https://issues.apache.org/jira/browse/PHOENIX-4328
> Project: Phoenix
> Issue Type: Bug
> Reporter: Karan Mehta
> Priority: Major
> Labels: namespaces
> Fix For: 4.13.0
>
>
> Imagine a scenario when we enable namespaces for phoenix on the server side
> and set the property {{phoenix.schema.isNamespaceMappingEnabled}} to true. A
> bunch of clients are trying to connect to this cluster. All of these clients
> have
> {{phoenix.schema.isNamespaceMappingEnabled}} to true, however
> for some of them {{phoenix.schema.isNamespaceMappingEnabled}} is set to
> false and it is true for others. (A typical case for rolling upgrade.)
> The first client with {{phoenix.schema.mapSystemTablesToNamespace}} true will
> acquire lock in SYSMUTEX and migrate the system tables. As soon as this
> happens, all the other clients will start failing.
> There are two scenarios here.
> 1. A new client trying to connect to server without this property set
> This will fail since the ConnectionQueryServicesImpl checks if SYSCAT is
> namespace mapped or not, If there is a mismatch, it throws an exception, thus
> the client doesn't get any connection.
> 2. Clients already connected to cluster but don't have this property set
> This will fail because every query calls the endpoint coprocessor on SYSCAT
> to determine the PTable of the query table and the physical HBase table name
> is resolved based on the properties. Thus, we try to call the method on
> SYSCAT instead of SYS:CAT and it results in a TableNotFoundException.
> This JIRA is to discuss about the potential ways in which we can handle this
> issue.
> Some ideas around this after discussing with [~twdsi...@gmail.com]:
> 1. Build retry logic around the code that works with SYSTEM tables
> (coprocessor calls etc.) Try with SYSCAT and if it fails, try with SYS:CAT
> Cons: Difficult to maintain and code scattered all over.
> 2. Use SchemaUtil.getPhyscialTableName method to return the table name that
> actually exists. (Only for SYSTEM tables)
> Call admin.tableExists to determine if SYSCAT or SYS:CAT exists and return
> that name. The client properties get ignored on this one.
> Cons: Expensive call every time, since this method is always called several
> times.
> [~jamestaylor] [~elserj] [~an...@apache.org] [~apurtell]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
