[
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267802#comment-13267802
]
Phabricator commented on HBASE-5494:
------------------------------------
Kannan has commented on the revision "[jira] [HBASE-5494] [89-fb] Table-level
locks for schema changing operations.".
INLINE COMMENTS
src/test/java/org/apache/hadoop/hbase/util/DelayInducingInjectionHandler.java:75
It is not clear why we need eventsToWaitFor structure at all.
For events that a test is not interested in, it seems odd that we are putting
those in the eventsToWaitFor structure.
eventToDelayTimeMS seems sufficient.
src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperWrapper.java:1321
spoke with Alex offline.
We need to handle the case where after the create failed (because the node
already exists), but before we could set a watch on this, if the znode was
deleted, then we should handle that case correctly. Currently, we'll return
false even in that case, and the caller will wait for CountDownLatch to reach
0, but it'll never reach zero since we missed the delete event.
REVISION DETAIL
https://reviews.facebook.net/D2997
> Introduce a zk hosted table-wide read/write lock so only one table operation
> at a time
> --------------------------------------------------------------------------------------
>
> Key: HBASE-5494
> URL: https://issues.apache.org/jira/browse/HBASE-5494
> Project: HBase
> Issue Type: Improvement
> Reporter: stack
> Attachments: D2997.3.patch
>
>
> I saw this facility over in the accumulo code base.
> Currently we just try to sort out the mess when splits come in during an
> online schema edit; somehow we figure we can figure all possible region
> transition combinations and make the right call.
> We could try and narrow the number of combinations by taking out a zk table
> lock when doing table operations.
> For example, on split or merge, we could take a read-only lock meaning the
> table can't be disabled while these are running.
> We could then take a write only lock if we want to ensure the table doesn't
> change while disabling or enabling process is happening.
> Shouldn't be too hard to add.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
