You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Michael Han (JIRA)" <ji...@apache.org> on 2017/03/13 16:22:00 UTC
[jira] [Updated] (ZOOKEEPER-911) move operations from methods to
individual classes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Han updated ZOOKEEPER-911:
----------------------------------
Fix Version/s: (was: 3.5.3)
3.5.4
> 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
> Fix For: 3.5.4, 3.6.0
>
> 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
(v6.3.15#6346)