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 
I guess this could happened if there are a lot of events queued in 

0. Let's assume that, initially, the queue waitingEvents contains N events: 
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 

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 

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.


> 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.

Reply via email to