[
https://issues.apache.org/jira/browse/ZOOKEEPER-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Koch updated ZOOKEEPER-911:
----------------------------------
Attachment: ZOOKEEPER-911.patch
Thx. to the awesomeness of GIT it wasn't to hard to filter the whitespace
changes out from the commits... :-)
There are some test failures that hudson reports on this patch. I believe, that
most/all of them are bugs that already exists in trunk but are revealed by this
patch.
For example the failing server.InvalidSnapshotTest times out because the
ClientCnxn.close() call blocks in Packet.waitForFinish().
However the only change introduced is that instead of
synchronize(packet) while(!packet.finished) packet.wait()
I call packet.waitForFinish() which is a synchronized method.
The bug is in ClientCnxn.queuePacket:
ClientCnxn.closing is set to true before the closeSession Packet is added to
outgoingQueue. Between these two steps, the SendThread already terminate so
that there's nobody left to call packet.notifyAll().
The whole close logic of the ZooKeeper client is totally broken and should be
rethought from the beginning. I doesn't help to put more and more patchwork on
this as has been done before.
Opened ZOOKEEPER-970 for this.
> 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
> Attachments: ZOOKEEPER-911.patch, ZOOKEEPER-911.patch,
> ZOOKEEPER-911.patch, ZOOKEEPER-911.patch, 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.
