hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7848) Use ZK-based read/write lock to make flush-type snapshot robust against table enable/disable/alter
Date Thu, 21 Mar 2013 17:53:17 GMT

    [ 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

Mime
View raw message