move operations from methods to individual classes

                 Key: ZOOKEEPER-911
             Project: Zookeeper
          Issue Type: New Feature
          Components: java client
            Reporter: Thomas Koch

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


And a reply from Patrick Hunt at my mail:

Hi Thomas, you might take a look at this JIRA

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 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to