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)