[
https://issues.apache.org/jira/browse/ACCUMULO-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13757078#comment-13757078
]
John Vines commented on ACCUMULO-715:
-------------------------------------
I'm thinking about scrapping the work I've done on this. Besides it being a bit
antiquated, it really hasn't simplified the code much. The exception handling
in Curator isn't that great yet and leaves me wanting. The recipes are nice,
but the locks do not behave in a way that are interchangeable with what we're
doing. I may contribute some to the project to bring features into it that
would benefit us, but for now I'm skeptical about the gains from switching to
Curator.
I was initially hoping with all of this we could abolish the ZooReader,
ZooReaderWriter, and ZooCache, but ultimately they turned into management
interfaces for Curator that, while less complex then the straight Zookeeper,
were marginally less code. I was hoping for a big chunk of code being
offloaded, but I wasn't quite seeing it. Unless anyone had another strong
reason for this migration, I'm thinking we may want to push off for Curator to
become a bit more fitting for our purposes.
> use curator
> -----------
>
> Key: ACCUMULO-715
> URL: https://issues.apache.org/jira/browse/ACCUMULO-715
> Project: Accumulo
> Issue Type: Improvement
> Components: master, tserver
> Reporter: Eric Newton
> Assignee: John Vines
> Fix For: 1.6.0
>
>
> Curator seems to have distilled a lot of zookeeper lesson's learned. Consider
> using it as our interface to zookeeper.
> Curator advantages:
> * handles zookeeper retries, via configurable policies
> * works around some very strange failure scenarios
> * simplified API
> * unlike ZooCache and ZooLock, Curator does not need to be maintained by
> Accumulo developers
--
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
