[ https://issues.apache.org/jira/browse/ZOOKEEPER-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Nauroth updated ZOOKEEPER-911: ------------------------------------ Fix Version/s: (was: 3.5.2) 3.5.3 > 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.6.0, 3.5.3 > > 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.4#6332)