hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eugene Koifman (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HIVE-14192) False positive error due to thrift
Date Fri, 08 Jul 2016 17:29:11 GMT

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

Eugene Koifman commented on HIVE-14192:
---------------------------------------

The idea was that the "default" value is never the right value.  It's set when the object
(in 2.1) is created and the caller is expected to set the appropriate value for the given
context.  Then the assert on the server side check to see if it gets an object with "default"
value and thus it knows that there is a bug somewhere.  I wanted to rely on isSetOperationType()
to know if the message is sent by a buggy 2.1 client or by an older client (which doesn't
set this at all).  Unfortunately, this is not how isSetOperationType() behaves - thus there
is no way to tell a message from old client and buggy 2.1 client.  That's why I changed the
assert to only apply in test mode where we know there is only 1 version of Thrift objects
involved.

> 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: 1.3.0, 2.1.0
>            Reporter: Eugene Koifman
>            Assignee: Eugene Koifman
>         Attachments: HIVE-14192.2.patch, HIVE-14192.patch
>
>
> 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)

Mime
View raw message