[
https://issues.apache.org/jira/browse/HBASE-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510158#comment-13510158
]
Alex Feinberg commented on HBASE-5991:
--------------------------------------
Oh great! Didn't know there was a hackathon going on.
I actually looked at curator code, but found it a bit overkill for this
specific use case (particularly because we already had an implementation of the
recovery logic in RecoveringZooKeeper -- so we'd either have to migrate
wholesale or keep two implementations of the same code). I did borrow a few
ideas from there (even though I didn't follow the exact logic used, I believe),
however, so it wasn't purely from the wiki + scratch.
After I wrote this patch, we've also open sourced a library that Puma and
several other apps use to handle ZK. They use a slightly different version of
RecoveringZooKeeper, however, that doesn't embed additional information into
the data (like we do).
https://github.com/facebook/jcommon/tree/master/zookeeper/src/main/java/com/facebook/zookeeper
There are implementations of different recipes there as well. I have no strong
preference on which part is better, there's a lot I like about curator (I would
seriously consider using it for something I start from scratch). I'd just avoid
having multiple implementations of the same ZK abstraction in the codebase.
One approach could be to just implement the interfaces with curator and then
run this through the unit tests.
Good luck! Feel free to put me on the diff(s). I am even more excited about
what could now be done on top of these abstractions.
- af
> Introduce sequential ZNode based read/write locks
> --------------------------------------------------
>
> Key: HBASE-5991
> URL: https://issues.apache.org/jira/browse/HBASE-5991
> Project: HBase
> Issue Type: Improvement
> Reporter: Alex Feinberg
> Assignee: Alex Feinberg
> Fix For: 0.89-fb
>
>
> This is a continuation of HBASE-5494:
> Currently table-level write locks have been implemented using non-sequential
> ZNodes as part of HBASE-5494 and committed to 89-fb branch. This issue is to
> track converting the table-level locks to sequential ZNodes and supporting
> read-write locks, as to solve the issue of preventing schema changes during
> region splits or merges.
--
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
