[
https://issues.apache.org/jira/browse/ZOOKEEPER-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976084#action_12976084
]
Thomas Koch commented on ZOOKEEPER-970:
---------------------------------------
I've two ideas, that may help.
1) Think of the outgoingQueue as an entity, a class. ( ZOOKEEPER-879 ) It
knows, when it is closed and may not accept additional packets. It knows how to
clean itself up. It must give the sendThread permission to terminate.
2) Think of a pipeline consisting of outgoingQueue, SendThread, waitingEvents,
EventThread. Currently we try to shutdown the whole pipeline at once and wonder
that we run in concurrency issues everywhere. Instead this pipeline must be
rolled up from the beginning. Every member of the pipeline shuts itself down
and tells it's successor to shutdown.
> Review and refactor Java client close logic
> -------------------------------------------
>
> Key: ZOOKEEPER-970
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-970
> Project: ZooKeeper
> Issue Type: Sub-task
> Reporter: Thomas Koch
> Assignee: Thomas Koch
>
> There have been several jira tickets to fix the close logic but there are
> still possibilities for blocks as discovered in ZOOKEEPER-911.
> 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().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
