[
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)
