[ https://issues.apache.org/jira/browse/HBASE-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609194#comment-13609194 ]
Enis Soztutar commented on HBASE-7848: -------------------------------------- bq. Looking at https://github.com/apache/hbase/blob/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/TableLockManager.java#L223 it seem that when interruptions and timeouts exceptions are thrown, the lock could be taken but reported as an exception. On timeout, we delete the lock znode already, ZKInterProcessLockBase, line 199. In case of interruptions, I think we should ensure that the lock znode is deleted before throwing the exception. This seems to be the model taken by ReentrantLock in java. I'll open a jira for that. bq. Can you give me a pointer to some tests that exercies the timeout and/or interrupt path? There are timeout tests in TestTableLockManager, and TestZKInterProcessReadWriteLock. bq. A quick solution may be to use the is a slight modification of the canonical java lock pattern – put the acquire inside the try block >From the javadoc >http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/ReentrantLock.html, > the canonical model is not to put acquire() in try, but rest of the code >after acquire(). {code} public void m() { lock.lock(); // block until condition holds try { // ... method body } finally { lock.unlock() } } {code} Though you are right that we have to ensure lock is properly cleaned up on Interruption. This has not been a problem, since currently only the server shutdown interrupts the lock waiting, and zk cleans the znodes since they are EPHEMERAL. bq. HBASE-8131 modifies the way CreateTableHandler releases the lock. It was me who changed that. Yes, in CreateTableHandler, we should have guarded against the whole process(), instead of the subcall handleCreateTable(). Your patch fixes the condition where lock is acquired(). What Jonathan is pointing to is inside the acquire() call. > Use ZK-based read/write lock to make flush-type snapshot robust against table > enable/disable/alter > -------------------------------------------------------------------------------------------------- > > Key: HBASE-7848 > URL: https://issues.apache.org/jira/browse/HBASE-7848 > Project: HBase > Issue Type: Improvement > Components: snapshots > Affects Versions: 0.96.0 > Reporter: Ted Yu > Assignee: Ted Yu > Attachments: 7848-v1.txt, 7848-v2.txt, hbase-7848_v2.patch > > > Current region split following flush would fail snapshot. > We can utilize ZK-based read/write lock to make flush-type snapshot robust -- 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