[
https://issues.apache.org/jira/browse/PHOENIX-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16225997#comment-16225997
]
Karan Mehta commented on PHOENIX-4328:
--------------------------------------
bq. Can the result be cached in a static location? The check only needs to
happen once. We aren't going to switch mapping strategy at runtime.
This is not for one-time. This concern is at run time only. We might have some
clients (app-servers) with the property
{{phoenix.schema.isNamespaceMappingEnabled}} SET and others with
{{phoenix.schema.isNamespaceMappingEnabled}} UNSET. Thus there is a mismatch.
We need to find runtime resolution if we don't want downtime. The way it
currently works is it that if there is a mismatch, it throws up an exception
and doesn't allow client to connect to it.
> 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
>
> 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)
