Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Tue, 24 Oct 2017 19:11:00 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: dev@phoenix.apache.org
Message-ID: <JIRA.13060807.1490994869000.48911.1508872260504@Atlassian.JIRA>
In-Reply-To: <JIRA.13060807.1490994869000@Atlassian.JIRA>
References: <JIRA.13060807.1490994869000@Atlassian.JIRA> <JIRA.13060807.1490994869966@jira-lw-us.apache.org>
Subject: [jira] [Commented] (PHOENIX-3757) System mutex table not being
 created in SYSTEM namespace when namespace mapping is enabled
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 24 Oct 2017 19:11:06 -0000


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

ASF GitHub Bot commented on PHOENIX-3757:
-----------------------------------------

Github user twdsilva commented on a diff in the pull request:

    https://github.com/apache/phoenix/pull/277#discussion_r146663164
  
    --- Diff: phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java ---
    @@ -3101,49 +3124,68 @@ void ensureSystemTablesUpgraded(ReadOnlyProps props)
                     // Regardless of the case 1 or 2, if the NS does not exist, we will error expectedly
                     // below. If the NS does exist and is mapped, the below check will exit gracefully.
                 }
    -            
    +
                 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 UpgradeInProgressException
    +
    +            // 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(), props).getNameAsString();
    +            UpgradeUtil.mapTableToNamespace(admin, sysMutexSrcTableName, sysMutexDestTableName, PTableType.SYSTEM);
    +
                 byte[] mappedSystemTable = SchemaUtil
                         .getPhysicalName(PhoenixDatabaseMetaData.SYSTEM_CATALOG_NAME_BYTES, props).getName();
                 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, PTableType.SYSTEM,
                                 null);
    +                    // Invalidate the client-side metadataCache
                         ConnectionQueryServicesImpl.this.removeTable(null,
                                 PhoenixDatabaseMetaData.SYSTEM_CATALOG_NAME, null,
                                 MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP_4_1_0);
                     }
                     tableNames.remove(PhoenixDatabaseMetaData.SYSTEM_CATALOG_HBASE_TABLE_NAME);
                 }
    -            tableNames.remove(PhoenixDatabaseMetaData.SYSTEM_MUTEX_HBASE_TABLE_NAME);
    --- End diff --
    
    I think you still need to remove SYSTEM.MUTEX from tableNames.


> System mutex table not being created in SYSTEM namespace when namespace mapping is enabled
> ------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-3757
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3757
>             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
>
>
> 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 table.


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