stack created HBASE-8482:
----------------------------
Summary: TestHBaseFsck#testCheckTableLocks broke;
java.lang.AssertionError: expected:<[]> but was:<[EXPIRED_TABLE_LOCK]>
Key: HBASE-8482
URL: https://issues.apache.org/jira/browse/HBASE-8482
Project: HBase
Issue Type: Bug
Reporter: stack
I've been looking into this test failure because I thought it particular to my
rpc hackery.
What I see is like the subject:
{code}
java.lang.AssertionError: expected:<[]> but was:<[EXPIRED_TABLE_LOCK]>
{code}
and later in same unit test:
{code}
java.lang.AssertionError: expected:<[EXPIRED_TABLE_LOCK]> but
was:<[EXPIRED_TABLE_LOCK, EXPIRED_TABLE_LOCK]>
{code}
The test creates a write lock and then expires it. In subject failure, we are
expiring the lock ahead of the time it should be. Easier for me to reproduce
is that the second write lock we put in place is not allowed to happen because
of the presence of the first lock EVEN THOUGH IT HAS BEEN JUDGED EXPIRED:
{code}
ERROR: Table lock acquire attempt found:[tableName=foo,
lockOwner=localhost,60000,1, threadId=387, purpose=testCheckTableLocks,
isShared=false, createTime=129898749]
2013-05-02 00:34:42,715 INFO [Thread-183] lock.ZKInterProcessLockBase(431):
Lock is held by: write-testing utility0000000000
ERROR: Table lock acquire attempt found:[tableName=foo,
lockOwner=localhost,60000,1, threadId=349, purpose=testCheckTableLocks,
isShared=false, createTime=28506852]
{code}
Above, you see the expired lock and then our hbck lock visitor has it that the
second lock is expired because it is held by the first lock.
I can keep looking at this but input would be appreciated.
It failed in recent trunk build
https://builds.apache.org/view/H-L/view/HBase/job/HBase-TRUNK/4090/testReport/junit/org.apache.hadoop.hbase.util/TestHBaseFsck/testCheckTableLocks/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
