accumulo-notifications mailing list archives

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

    [ https://issues.apache.org/jira/browse/ACCUMULO-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13692429#comment-13692429
] 

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: 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

Mime
View raw message