[
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
