[
https://issues.apache.org/jira/browse/HBASE-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13608947#comment-13608947
]
Jonathan Hsieh commented on HBASE-7848:
---------------------------------------
Then I'm concerned that all the other handlers may have the same problem.
Other operations (ZK nodes in splitting for example) have had a history of
assuming exn means failure (when it could mean success but temporary network
partition). 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.
Can you give me a pointer to some tests that exercies the timeout and/or
interrupt path?
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, and make sure the
release is called and is able to differentiate between the different lock
acquire failure modes or can release when acquire returned in the questionable
state)
> 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
