phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3757) System mutex table not being created in SYSTEM namespace when namespace mapping is enabled
Date Wed, 25 Oct 2017 17:11:00 GMT


ASF GitHub Bot commented on PHOENIX-3757:

Github user karanmehta93 commented on a diff in the pull request:
    --- Diff: phoenix-core/src/main/java/org/apache/phoenix/query/
    @@ -3101,49 +3124,68 @@ void ensureSystemTablesUpgraded(ReadOnlyProps props)
                     // Regardless of the case 1 or 2, if the NS does not exist, we will error
                     // below. If the NS does exist and is mapped, the below check will exit
                 List<TableName> tableNames = getSystemTableNames(admin);
                 // No tables exist matching "SYSTEM\..*", they are all already in "SYSTEM:.*"
                 if (tableNames.size() == 0) { return; }
                 // Try to move any remaining tables matching "SYSTEM\..*" into "SYSTEM:"
                 if (tableNames.size() > 5) {
                     logger.warn("Expected 5 system tables but found " + tableNames.size()
+ ":" + tableNames);
    +            // Try acquiring a lock in SYSMUTEX table before migrating the tables since
it involves disabling the table
    +            // If we cannot acquire lock, it means some old client is either migrating
SYSCAT or trying to upgrade the
    +            // schema of SYSCAT table and hence it should not be interrupted
    +            acquiredMutexLock = acquireUpgradeMutex(0, mutexRowKey);
    +            if(acquiredMutexLock) {
    +                logger.debug("Acquired lock in SYSMUTEX table for migrating SYSTEM tables
to SYSTEM namespace");
    +            }
    +            // We will not reach here if we fail to acquire the lock, since it throws
    +            // Handle the upgrade of SYSMUTEX table separately since it doesn't have
any entries in SYSCAT
    +            String sysMutexSrcTableName = PhoenixDatabaseMetaData.SYSTEM_MUTEX_NAME;
    +            String sysMutexDestTableName = SchemaUtil.getPhysicalName(sysMutexSrcTableName.getBytes(),
    +            UpgradeUtil.mapTableToNamespace(admin, sysMutexSrcTableName, sysMutexDestTableName,
                 byte[] mappedSystemTable = SchemaUtil
                 metatable = getTable(mappedSystemTable);
                 if (tableNames.contains(PhoenixDatabaseMetaData.SYSTEM_CATALOG_HBASE_TABLE_NAME))
                     if (!admin.tableExists(mappedSystemTable)) {
    +                    // Actual migration of SYSCAT table
                         UpgradeUtil.mapTableToNamespace(admin, metatable,
                                 PhoenixDatabaseMetaData.SYSTEM_CATALOG_NAME, props, null,
    +                    // Invalidate the client-side metadataCache
                                 PhoenixDatabaseMetaData.SYSTEM_CATALOG_NAME, null,
    -            tableNames.remove(PhoenixDatabaseMetaData.SYSTEM_MUTEX_HBASE_TABLE_NAME);
                 for (TableName table : tableNames) {
                     UpgradeUtil.mapTableToNamespace(admin, metatable, table.getNameAsString(),
props, null, PTableType.SYSTEM,
                     ConnectionQueryServicesImpl.this.removeTable(null, table.getNameAsString(),
    -            if (!tableNames.isEmpty()) {
    -                clearCache();
    -            }
    +            // Clear the server-side metadataCache when all tables are migrated so that
the new PTable can be loaded with NS mapping
    +            clearCache();
    --- End diff --
    > My assumption was that the intent was to drop any cached PTables if we moved any
system tables around. Given the above, it sounds like this is (now?) unnecessary.
    That's correct. We indeed need to remove it from cache because once the migration is complete,
we add a row in `SYSCAT` indicating that `IS_NAMESPACE_MAPPED` to true. Although it seems
unnecessary, I don't really want to rely on the coprocessor hook as it may change any time.
An explicit `clearCache()` should not harm it, I believe.
    > Is that being down in a CP too? If so, would it make sense to do this cache-clearing
there (instead of client side)?
     What is CP? I didn't quite get you.

> System mutex table not being created in SYSTEM namespace when namespace mapping is enabled
> ------------------------------------------------------------------------------------------
>                 Key: PHOENIX-3757
>                 URL:
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Josh Elser
>            Assignee: Karan Mehta
>            Priority: Critical
>              Labels: namespaces
>             Fix For: 4.13.0
>         Attachments: PHOENIX-3757.001.patch, PHOENIX-3757.002.patch, PHOENIX-3757.003.patch
> Noticed this issue while writing a test for PHOENIX-3756:
> The SYSTEM.MUTEX table is always created in the default namespace, even when {{phoenix.schema.isNamespaceMappingEnabled=true}}.
At a glance, it looks like the logic for the other system tables isn't applied to the mutex

This message was sent by Atlassian JIRA

View raw message