Uploaded image for project: 'ZooKeeper'
  1. ZooKeeper
  2. ZOOKEEPER-911

move operations from methods to individual classes

    Details

    • Type: New Feature
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.5.4, 3.6.0
    • Component/s: java client
    • Labels:
      None

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                thkoch Thomas Koch
                Reporter:
                thkoch Thomas Koch
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: