[
https://issues.apache.org/jira/browse/PHOENIX-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302148#comment-16302148
]
Karan Mehta commented on PHOENIX-4487:
--------------------------------------
I ran into this issue when one of the older clients connected to a fresh
cluster and then a newer client tried connecting to the same cluster. However
as discussed offline with [~twdsi...@gmail.com], we decided that since we
_officially_ support only 2 client backward versions, this should be fine.
However, it is always good to fix things and make them as much stable as
possible. There is also a plausible race condition addressed below, which was
also one of the reasons we decided not to create SYSMUTEX table and instead
throw the exception.
{code}
Lines: 3205 - 3211
if
(!tableNames.contains(PhoenixDatabaseMetaData.SYSTEM_MUTEX_HBASE_TABLE_NAME)) {
TableName mutexName =
SchemaUtil.getPhysicalTableName(PhoenixDatabaseMetaData.SYSTEM_MUTEX_NAME,
props);
if
(PhoenixDatabaseMetaData.SYSTEM_MUTEX_HBASE_TABLE_NAME.equals(mutexName) ||
!tableNames.contains(mutexName)) {
createSysMutexTable(admin, props);
}
}
{code}
The first line checks if SYSTEM.MUTEX table exists or not. This can be in 2
cases, either the table doesn't exist at all ot its being migrated to SYSTEM
namespace. There is no clear way of differentiating them and hence there arises
a plausible race condition here. If it's at all required, we can directly call
{{createSysMutexTable}} method, since it will check for the table according to
client properties and create one if none of them exists.
{code}
if (currentServerSideTableTimeStamp <=
MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP_4_10_0 &&
!SchemaUtil.isNamespaceMappingEnabled(PTableType.SYSTEM,
ConnectionQueryServicesImpl.this.getProps())) {
{code}
I don't see the need for checking if namespace mapping is enabled or not.
SYSMUTEX table needs to be created for any client who is jumping from 4.7 to
4.13 (since it was introduced in 4.10 version). Namespaces can be either
enabled or disabled. SYSMUTEX will be used once again when client wants to
migrate the SYSTEM tables to SYSTEM namespace.
Please update the comments on this change to address the concern mentioned.
[~jamestaylor] Also, how do we test this? Any UT or directly tried with a
cluster?
> Missing SYSTEM.MUTEX table upgrading from 4.7 to 4.13
> -----------------------------------------------------
>
> Key: PHOENIX-4487
> URL: https://issues.apache.org/jira/browse/PHOENIX-4487
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.14.0, 4.13.1, 4.13.2-cdh5.11.2
> Reporter: Flavio Pompermaier
> Assignee: James Taylor
> Attachments: PHOENIX-4487.patch
>
>
> Upgrading from the official Cloudera Parcel equipped with Phoenix 4.7 to the
> last unofficial parcel (4.13 on CDH 5.11.2) I had the same error of
> https://issues.apache.org/jira/browse/PHOENIX-4293 (apart from the fact that
> the from version was 4.7...).
> The creation of system.mutex table fixed the problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
