[
https://issues.apache.org/jira/browse/HBASE-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13648290#comment-13648290
]
Nicolas Liochon commented on HBASE-8482:
----------------------------------------
bq. The two chores were spinning because the outer chore check of
currentTimeMillis was using the EEM but the sleep was not (so we'd never
sleep). I suppose it would pass sometimes on a particular architecture but not
local here on my desktop (Thanks Anoop Sam John)
+1. Also, it means that we're using 100% of a CPU and doing a bunch system
calls.
In v2 I try replacing all of them.
> 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
> Assignee: stack
> Priority: Critical
> Fix For: 0.95.1
>
> Attachments: 8482.txt
>
>
> 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
