[
https://issues.apache.org/jira/browse/ZOOKEEPER-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977175#action_12977175
]
Thomas Koch commented on ZOOKEEPER-911:
---------------------------------------
Summary of this patch:
- includes ZOOKEEPER-837, so that ClientCnxn doesn't need a reference to
ZooKeeper anymore
- ClientCnxn instantiates the WatchManager itself. Before that ZooKeeper and
ClientCnxn both had references to the WatchManager. We could later inject the
WatchManager again to ClientCnxn.
- Some classes have been moved to their own files to make them visible for
other internal classes. It has been documented, that they're not part of the
public API. These classes are: Packet, WatchManager, WatchRegistration
- A new class "Executor" with two public methods "execute" and "send". These
methods take an instance of "Operation" and either execute it synchronously or
send it for asynchronous execution. Introducing these two methods made it
possible to remove a lot of redundant code in the API methods of the ZooKeeper
class.
- A set of Operation classes have been introduced, like "Create", "GetData",
"GetChildren", "Exists". Calling a ZK method now happens internaly like:
- Instantiate an operation class,
- give the operation class to the Executor, either through the send() or
execute() call.
- ClientCnxn.queuePacket now has an instance of Packet as parameter as the name
suggests. The instantiation of a Packet instance is done in the Executor or at
other places where needed.
- The ClientCnxn.submitRequest method has been removed. Instead one calls
queuePacket() and Packet.waitForFinish().
- ClientCnxn.watcher has been renamed to ClientCnxn.watchManager, because it
holds an instance of a WatchManager, not a Watcher
- PathUtils got to new methods appendChroot(chrootPath, path) and
removeChroot(chrootPath, path)
- WatchRegistration.register() got the watchManager instance as additional
parameter. When these classes were still inside the ZooKeeper, the
WatchRegistration could "see" the watchManager directly.
- Move the ClientCnxn. packetLen constant to Packet.MAX_LENGTH and provide a
method Packet.isValidPacketLength()
- New method Packet.getAsByteBuffer(). Creates the ByteBuffer only when needed
and not in the Ctor. This is necessary, since the Xid of the Packet is only set
in ClientCnxn.queuePacket, after the Packet has already been instantiated.
The operation classes could be used for ZOOKEEPER-965. It's also my intention
that the Executor and the Operation classes could later become an alternative
public API in addition to the ZooKeeper class.
> 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.4.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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
