[jira] [Updated] (HIVE-14357) TestDbTxnManager2#testLocksInSubquery failing in branch-2.1
[
https://issues.apache.org/jira/browse/HIVE-14357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HIVE-14357:
Resolution: Fixed
Fix Version/s: 2.1.1
2.2.0
Target Version/s: 2.1.1 (was: 1.3.0, 2.1.1)
Status: Resolved (was: Patch Available)
Committed to master and branch-2.1
> TestDbTxnManager2#testLocksInSubquery failing in branch-2.1
> ---
>
> Key: HIVE-14357
> URL: https://issues.apache.org/jira/browse/HIVE-14357
> Project: Hive
> Issue Type: Bug
>Affects Versions: 2.1.1
>Reporter: Rajat Khandelwal
>Assignee: Sergey Shelukhin
> Fix For: 2.2.0, 2.1.1
>
> Attachments: HIVE-14357.patch
>
>
> {noformat}
> checkCmdOnDriver(driver.compileAndRespond("insert into R select * from S
> where a in (select a from T where b = 1)"));
> txnMgr.openTxn("three");
> txnMgr.acquireLocks(driver.getPlan(), ctx, "three");
> locks = getLocks();
> Assert.assertEquals("Unexpected lock count", 3, locks.size());
> checkLock(LockType.SHARED_READ, LockState.ACQUIRED, "default", "T", null,
> locks.get(0));
> checkLock(LockType.SHARED_READ, LockState.ACQUIRED, "default", "S", null,
> locks.get(1));
> checkLock(LockType.SHARED_READ, LockState.ACQUIRED, "default", "R", null,
> locks.get(2));
> {noformat}
> This test case is failing. The expected order of locks is supposed to be T,
> S, R. But upon closer inspection, it seems to be R,S,T.
> I'm not much familiar with what these locks are and why the order is
> important. Raising this jira so while I try to understand it all. Meanwhile,
> if somebody can explain here, would be helpful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HIVE-14357) TestDbTxnManager2#testLocksInSubquery failing in branch-2.1
[
https://issues.apache.org/jira/browse/HIVE-14357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eugene Koifman updated HIVE-14357:
--
Affects Version/s: 2.1.1
Target Version/s: 1.3.0, 2.1.1
> TestDbTxnManager2#testLocksInSubquery failing in branch-2.1
> ---
>
> Key: HIVE-14357
> URL: https://issues.apache.org/jira/browse/HIVE-14357
> Project: Hive
> Issue Type: Bug
>Affects Versions: 2.1.1
>Reporter: Rajat Khandelwal
>Assignee: Sergey Shelukhin
> Attachments: HIVE-14357.patch
>
>
> {noformat}
> checkCmdOnDriver(driver.compileAndRespond("insert into R select * from S
> where a in (select a from T where b = 1)"));
> txnMgr.openTxn("three");
> txnMgr.acquireLocks(driver.getPlan(), ctx, "three");
> locks = getLocks();
> Assert.assertEquals("Unexpected lock count", 3, locks.size());
> checkLock(LockType.SHARED_READ, LockState.ACQUIRED, "default", "T", null,
> locks.get(0));
> checkLock(LockType.SHARED_READ, LockState.ACQUIRED, "default", "S", null,
> locks.get(1));
> checkLock(LockType.SHARED_READ, LockState.ACQUIRED, "default", "R", null,
> locks.get(2));
> {noformat}
> This test case is failing. The expected order of locks is supposed to be T,
> S, R. But upon closer inspection, it seems to be R,S,T.
> I'm not much familiar with what these locks are and why the order is
> important. Raising this jira so while I try to understand it all. Meanwhile,
> if somebody can explain here, would be helpful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HIVE-14357) TestDbTxnManager2#testLocksInSubquery failing in branch-2.1
[
https://issues.apache.org/jira/browse/HIVE-14357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HIVE-14357:
Status: Patch Available (was: Open)
[~ekoifman] [~wzheng] can you take a look?
> TestDbTxnManager2#testLocksInSubquery failing in branch-2.1
> ---
>
> Key: HIVE-14357
> URL: https://issues.apache.org/jira/browse/HIVE-14357
> Project: Hive
> Issue Type: Bug
>Reporter: Rajat Khandelwal
>Assignee: Sergey Shelukhin
> Attachments: HIVE-14357.patch
>
>
> {noformat}
> checkCmdOnDriver(driver.compileAndRespond("insert into R select * from S
> where a in (select a from T where b = 1)"));
> txnMgr.openTxn("three");
> txnMgr.acquireLocks(driver.getPlan(), ctx, "three");
> locks = getLocks();
> Assert.assertEquals("Unexpected lock count", 3, locks.size());
> checkLock(LockType.SHARED_READ, LockState.ACQUIRED, "default", "T", null,
> locks.get(0));
> checkLock(LockType.SHARED_READ, LockState.ACQUIRED, "default", "S", null,
> locks.get(1));
> checkLock(LockType.SHARED_READ, LockState.ACQUIRED, "default", "R", null,
> locks.get(2));
> {noformat}
> This test case is failing. The expected order of locks is supposed to be T,
> S, R. But upon closer inspection, it seems to be R,S,T.
> I'm not much familiar with what these locks are and why the order is
> important. Raising this jira so while I try to understand it all. Meanwhile,
> if somebody can explain here, would be helpful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HIVE-14357) TestDbTxnManager2#testLocksInSubquery failing in branch-2.1
[
https://issues.apache.org/jira/browse/HIVE-14357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HIVE-14357:
Attachment: HIVE-14357.patch
Removed the order dependency from test. When it fails, the error looks like
this:
{noformat}
java.lang.AssertionError: Could't find {SHARED_READ, ACQUIRED, default, XYZY,
null} in [ShowLocksResponseElement(lockid:2, dbname:default, tablename:xyz,
state:ACQUIRED, type:SHARED_READ, txnid:0, lastheartbeat:1469837191676,
acquiredat:1469837191676, user:XYZ, hostname:reznor-mbp-2.local,
agentInfo:sergey_20160729170623_e1153b39-54d3-4cab-9766-c1349c8efa4a,
lockIdInternal:1)]{noformat}
> TestDbTxnManager2#testLocksInSubquery failing in branch-2.1
> ---
>
> Key: HIVE-14357
> URL: https://issues.apache.org/jira/browse/HIVE-14357
> Project: Hive
> Issue Type: Bug
>Reporter: Rajat Khandelwal
>Assignee: Sergey Shelukhin
> Attachments: HIVE-14357.patch
>
>
> {noformat}
> checkCmdOnDriver(driver.compileAndRespond("insert into R select * from S
> where a in (select a from T where b = 1)"));
> txnMgr.openTxn("three");
> txnMgr.acquireLocks(driver.getPlan(), ctx, "three");
> locks = getLocks();
> Assert.assertEquals("Unexpected lock count", 3, locks.size());
> checkLock(LockType.SHARED_READ, LockState.ACQUIRED, "default", "T", null,
> locks.get(0));
> checkLock(LockType.SHARED_READ, LockState.ACQUIRED, "default", "S", null,
> locks.get(1));
> checkLock(LockType.SHARED_READ, LockState.ACQUIRED, "default", "R", null,
> locks.get(2));
> {noformat}
> This test case is failing. The expected order of locks is supposed to be T,
> S, R. But upon closer inspection, it seems to be R,S,T.
> I'm not much familiar with what these locks are and why the order is
> important. Raising this jira so while I try to understand it all. Meanwhile,
> if somebody can explain here, would be helpful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
