phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ankit Singhal (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (PHOENIX-4328) Support clients having different "phoenix.schema.mapSystemTablesToNamespace" property
Date Fri, 03 Nov 2017 05:51:00 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16237122#comment-16237122
] 

Ankit Singhal edited comment on PHOENIX-4328 at 11/3/17 5:50 AM:
-----------------------------------------------------------------

bq. We can't do that since the properties are read from ConnectionQueryServicesImpl properties
object is an instance of class ReadOnlyProps.
You can use an instance variable(isNamespaceMappingEnabled) in ConnectionQueryServicesImpl
which can be set by current logic in checkClientServerCompatibility and use it everywhere
where the conversion of SYSTEM tables names are required?

we may close https://issues.apache.org/jira/browse/PHOENIX-3288 as duplicate if this JIRA
is trying to do the same.


was (Author: ankit@apache.org):
bq. We can't do that since the properties are read from ConnectionQueryServicesImpl properties
object is an instance of class ReadOnlyProps.
You can use an instance variable(isNamespaceMappingEnabled) in ConnectionQueryServicesImpl
which can be set by current logic in checkClientServerCompatibility and use it everywhere
where the conversion of SYSTEM tables names are required?

> 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 [~twdsilva@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] [~ankit@apache.org] [~apurtell] 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message