zookeeper-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrico Olivelli (Jira)" <j...@apache.org>
Subject [jira] [Updated] (ZOOKEEPER-911) move operations from methods to individual classes
Date Fri, 06 Sep 2019 15:44:02 GMT

     [ https://issues.apache.org/jira/browse/ZOOKEEPER-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Enrico Olivelli updated ZOOKEEPER-911:
--------------------------------------
    Fix Version/s: 3.5.7

> move operations from methods to individual classes
> --------------------------------------------------
>
>                 Key: ZOOKEEPER-911
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-911
>             Project: ZooKeeper
>          Issue Type: New Feature
>          Components: java client
>            Reporter: Thomas Koch
>            Assignee: Thomas Koch
>            Priority: Major
>             Fix For: 3.6.0, 3.5.6, 3.5.7
>
>         Attachments: ZOOKEEPER-911.patch
>
>
> Copied from my email to the ZK dev list from 2010/05/26:
> For my current code I'm using zkclient[1] and have also looked at cages[2] for 
> some ZK usage examples. I observed, that there's a common pattern to wrap ZK 
> operations in callables and feed them to a "retryUntilConnected" executor.
> Now my idea is, that ZK should already come with operations in classes, e.g.:
> o.a.z.operation.Create extends Operation implements callable{
>   
>   private path, data[], acl, createMode
>   public Create( .. all kind of ctors .. )
>   public call(){
>     .. move code from Zookeeper.create() here
>   }
> }
> Similiar classes should be provided for getChildren, delete, exists, getData, 
> getACL, setACL and setData.
> One could then feed such operations to an ZkExecutor, which has the necessary 
> knowledge about the ZkConnection and can execute a command either 
> synchronously or asynchronously.
> One could also wrap operations in an ExceptionCatcher to ignore certain 
> Exceptions or in a RetryPolicy.
> This is only an idea so far, but I wanted to share my thoughts before starting 
> to try it out. (BTW: You can meet me at BerlinBuzzwords.de)
> [1] http://github.com/sgroschupf/zkclient
> [2] http://code.google.com/p/cages/
> And a reply from Patrick Hunt at my mail:
> Hi Thomas, you might take a look at this JIRA
> https://issues.apache.org/jira/browse/ZOOKEEPER-679
> there's definitely been interest in this area, however there are some 
> real challenges as well. Most users do end up wrapping the basic api 
> with some code, esp the "retry" metaphor is a common case, so I think it 
> would be valuable. At the same time getting the semantics right is hard 
> (and covering all the corner cases). Perhaps you could sync up with 
> Aaron/Chris, I'd personally like to see this go into contrib, but I 
> understand the extra burden the patch process presents -- it may make 
> more sense to rapidly iterate on something like github and then move to 
> contrib once you have something less frequently changing, where the 
> patch issue would be less of a problem (see 679, there's discussion on 
> this there). Regardless which way you take it we'd be happy to work with 
> you.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Mime
View raw message