accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Vines (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-715) use curator
Date Mon, 24 Jun 2013 22:04:20 GMT


John Vines commented on ACCUMULO-715:

Update for those paying attention-

The current state of the branch is mostly functional. I've done one pass which migrated a
lot of the underlying functionality into the existing structures. I'm not 100% what I'm going
to do on the next pass, but on the list are-
# CuratorFramework reuse - I'm seeing a fair amount of repeats in curator creation that I'd
like to reduce
# Use curator namespaces - pretty much everything I'm doing is in the scope of the root. At
the very least I want to switch it to /accumulo, but I may want to see about giving different
item scopes different operational namespaces to keep things simple
# Get rid of the various iZooReader/ReaderWriters - that's straightforward
# Utilize additional curator recipes to replace a lot of our existing locks & process
management - This would further decrease our code commitment to making things work, but I'm
not sure if there are existing recipes for the way we currently use zookeeper, service discovery
- this is also going to be after the purge of old ZK management code
# Make the retry policy more pluggable
# Improved use of listeners - There are some places I think that we can utilize more ZK notifications
to do things harder, better, faster, stronger.
# And there are probably other things I will stumble across as I do other things.

FYI- net code change lines: -208
> use curator
> -----------
>                 Key: ACCUMULO-715
>                 URL:
>             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:

View raw message