You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hive.apache.org by "Eugene Koifman (JIRA)" <ji...@apache.org> on 2016/07/08 00:31:11 UTC

[jira] [Created] (HIVE-14192) False positive error due to thrift

Eugene Koifman created HIVE-14192:
-------------------------------------

             Summary: False positive error due to thrift
                 Key: HIVE-14192
                 URL: https://issues.apache.org/jira/browse/HIVE-14192
             Project: Hive
          Issue Type: Bug
          Components: Metastore, Transactions
    Affects Versions: 2.1.0, 1.3.0
            Reporter: Eugene Koifman
            Assignee: Eugene Koifman


Given Thrift definition like this
{noformat}
struct LockComponent {
    1: required LockType type,
    2: required LockLevel level,
    3: required string dbname,
    4: optional string tablename,
    5: optional string partitionname,
    6: optional DataOperationType operationType = DataOperationType.UNSET,
    7: optional bool isAcid = false
}
{noformat}

The generated LockComponent has 
{noformat}
  public LockComponent() {
    this.operationType = org.apache.hadoop.hive.metastore.api.DataOperationType.UNSET;

    this.isAcid = false;

  }
  public boolean isSetOperationType() {
    return this.operationType != null;
  }
  public boolean isSetIsAcid() {
    return EncodingUtils.testBit(__isset_bitfield, __ISACID_ISSET_ID);
  }
{noformat}

So bottom line is even if LockComponent is created by old version of the client which doesn't have operationType filed, isSetOperationType() will still return true on the server.

This causes a false positive exception in TxnHandler.enqueueLockWithRetry() during Rolling Upgrade scenarios.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)