hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hsieh (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 22:13:16 GMT

    [ https://issues.apache.org/jira/browse/HBASE-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609578#comment-13609578
] 

Jonathan Hsieh commented on HBASE-7848:
---------------------------------------

bq. 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.

Actually, can these more detailed semantics be added to the TableLock.acquire() javadoc (follow
on issue)?  From what currently exists I don't know what to expect in those error situations
and would have needed to dig through a few layers to get to it.  Also I don't know the behavior
from the release java doc either if a lock wan't held.   http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/master/TableLockManager.TableLock.html

bq. Though you are right that we have to ensure lock is properly cleaned up on Interruption

Follow on issue? I think after an interrupts you'd have to check somehow or force a release.


                
> 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