[
https://issues.apache.org/jira/browse/ZOOKEEPER-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893618#action_12893618
]
Alexis Midon commented on ZOOKEEPER-794:
----------------------------------------
Hi Benjamin,
thanks a lot for the review.
One thing I noticed is that setting wasKilled in the method queueEventOfDeath
might affect the order in which events are processed. Actually if
queueEventOfDeath is invoked while the waitingEvents queue is not empty, any
subsequent calls to queuePacket might invoke processEvent for the received
Packet before the packets already queued are processed (since wasKilled is
true).
I guess this could happened if there are a lot of events queued in
waitingEvents.
0. Let's assume that, initially, the queue waitingEvents contains N events:
Event-0,...,Event-N
1. queueEventOfDeath is invoked, wasKilled is now true and the queue contains:
Event-k,...,Event-N, Event-Death
2. a new Packet comes in, queuePacket is invoked. Since wasKilled is true, the
new event Event-N+1 is processed right away before Event-N might have been
processed.
On the other hand, my initial patch will let Event-N+1 in the queue and it will
never get processed since the event of death will break the loop. Which is
worse.
I attached a new patch that aims to fix the ordering issue. The idea is to keep
queueing Event-N+i until the event of death has been processed and the queue is
empty. I see one downside with this approach: if events keep coming in, the
EventThread might not stop since the queue will never get empty.
Please review.
Alexis
> Callbacks are not invoked when the client is closed
> ---------------------------------------------------
>
> Key: ZOOKEEPER-794
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-794
> Project: Zookeeper
> Issue Type: Bug
> Components: java client
> Affects Versions: 3.3.1
> Reporter: Alexis Midon
> Assignee: Alexis Midon
> Fix For: 3.3.2, 3.4.0
>
> Attachments: ZOOKEEPER-794.patch.txt, ZOOKEEPER-794.txt,
> ZOOKEEPER-794_2.patch, ZOOKEEPER-794_3.patch
>
>
> I noticed that ZooKeeper has different behaviors when calling synchronous or
> asynchronous actions on a closed ZooKeeper client.
> Actually a synchronous call will throw a "session expired" exception while an
> asynchronous call will do nothing. No exception, no callback invocation.
> Actually, even if the EventThread receives the Packet with the session
> expired err code, the packet is never processed since the thread has been
> killed by the ventOfDeath. So the call back is not invoked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
