[jira] [Commented] (PHOENIX-4328) Support clients having different "phoenix.schema.mapSystemTablesToNamespace" property
[
https://issues.apache.org/jira/browse/PHOENIX-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (PHOENIX-4328) Support clients having different "phoenix.schema.mapSystemTablesToNamespace" property
[
https://issues.apache.org/jira/browse/PHOENIX-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16237158#comment-16237158
]
Karan Mehta commented on PHOENIX-4328:
--
bq. 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?
This can be useful for new clients trying to establish connection. But what
about the clients already connected? A common retry mechanism needs to be
established for them. This property is used on server side as well, so the
solution should be even more generic. Also, the first migration is controlled
by the client property and I believe that we shouldn't migrate the SYSTEM
tables to SYSTEM namespace based on server side decision.
bq. we may close https://issues.apache.org/jira/browse/PHOENIX-3288 as
duplicate if this JIRA is trying to do the same.
What was your motivation behind this JIRA? We may probably end up doing
something similar but it's not sure.
> 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)
[jira] [Commented] (PHOENIX-4328) Support clients having different "phoenix.schema.mapSystemTablesToNamespace" property
[
https://issues.apache.org/jira/browse/PHOENIX-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16237122#comment-16237122
]
Ankit Singhal commented on PHOENIX-4328:
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 [~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)
[jira] [Commented] (PHOENIX-4328) Support clients having different "phoenix.schema.mapSystemTablesToNamespace" property
[
https://issues.apache.org/jira/browse/PHOENIX-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16236635#comment-16236635
]
Karan Mehta commented on PHOENIX-4328:
--
bq. Would it be reasonable just to override the client configuration with the
value instead of throwing an exception about inconsistent namespace mapping
property?
We can't do that since the properties are read from
{{ConnectionQueryServicesImpl}} {{properties}} object is an instance of class
{{ReadOnlyProps}}.
As [~jamestaylor] suggested, one potential option is create a
{{DelegateHTableInterface}} since every call to
{{SchemaUtil#getPhysicalName()}} is used for getting a {{HTableInterface}}.
This happens in the method {{CQSI#getTable()}}. This delegate class can have
retry logic built in for certain type of tables (For example, SYSTEM tables).
For the rest, we can bubble up the exception.
We need to look into detail about potential corner cases here and how it will
affect server and client side.
[~twdsi...@gmail.com] FYI.
> 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)
[jira] [Commented] (PHOENIX-4328) Support clients having different "phoenix.schema.mapSystemTablesToNamespace" property
[
https://issues.apache.org/jira/browse/PHOENIX-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226387#comment-16226387
]
Sergey Soldatov commented on PHOENIX-4328:
--
We already have that property and check for that in the
checkClientServerCompatibility. Would it be reasonable just to override the
client configuration with the value instead of throwing an exception about
inconsistent namespace mapping property?
> 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)
[jira] [Commented] (PHOENIX-4328) Support clients having different "phoenix.schema.mapSystemTablesToNamespace" property
[
https://issues.apache.org/jira/browse/PHOENIX-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226074#comment-16226074
]
Karan Mehta commented on PHOENIX-4328:
--
bq. So all other clients with "phoenix.schema.isNamespaceMappingEnabled" set to
true or false will both failing while one client is upgrading from sys. to sys:
?
Clients with {{phoenix.schema.isNamespaceMappingEnabled}} to true will only
fail if both of them try to acquire the connection at the same time and try to
migrate the System tables to System namespace. If a client connects to the
cluster after the migration is completed then it will be fine.
Clients with {{phoenix.schema.isNamespaceMappingEnabled}} to false will fail
because of the two scenarios mentioned in the description.
Clients will anyways fail since this involves disabling of SYSCAT table, which
is a downtime for sure.
> 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)
[jira] [Commented] (PHOENIX-4328) Support clients having different "phoenix.schema.mapSystemTablesToNamespace" property
[
https://issues.apache.org/jira/browse/PHOENIX-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226068#comment-16226068
]
Ethan Wang commented on PHOENIX-4328:
-
bq. 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.
So all other clients with "phoenix.schema.isNamespaceMappingEnabled" set to
true or false will both failing while one client is upgrading from sys. to sys:
?
> 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)
[jira] [Commented] (PHOENIX-4328) Support clients having different "phoenix.schema.mapSystemTablesToNamespace" property
[
https://issues.apache.org/jira/browse/PHOENIX-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (PHOENIX-4328) Support clients having different "phoenix.schema.mapSystemTablesToNamespace" property
[
https://issues.apache.org/jira/browse/PHOENIX-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16225706#comment-16225706
]
Andrew Purtell commented on PHOENIX-4328:
-
bq. Cons: Expensive call every time, since this method is always called
several times.
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.
> 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)
