[
https://issues.apache.org/jira/browse/ZOOKEEPER-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14294749#comment-14294749
]
Rakesh R commented on ZOOKEEPER-2111:
-------------------------------------
Thanks [~hdeng] for reporting this. I think there is no straight forward case
of missing the packet notification to the user, right?. Because
{{SendThread#run}} will be running till the {{state#isAlive}}. The
{{cleanup()}} call would be called after seeing the {{!state#isAlive()}}
{code}
// When it comes to this point, it guarantees that later queued packet to
outgoingQueue will be
// notified of death.
{code}
But after going through code several times, I could see a corner case like,
step-1) Thread-1 : invoke {{zk#close}} and is waiting for the response from the
server
step-2) Thread-2 : Interrupt 'Thread-1' which is waiting for step-1 operation.
Now it will {{disconnect();}} and mark {{state=CLOSED}}
step-3) Thread-3 : user is adding a new request to the {{outgoingqueue}}
Probably a possible race between Thread-2 and Thread-3. Are you thinking
similar lines?
> Not isAlive states should be synchronized in ClientCnxn
> -------------------------------------------------------
>
> Key: ZOOKEEPER-2111
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2111
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
> Reporter: Hongchao Deng
> Assignee: Hongchao Deng
> Attachments: ZOOKEEPER-2111.patch, ZOOKEEPER-2111.patch,
> ZOOKEEPER-2111.patch
>
>
> In ClientCnxn.queuePacket, it checks variables of state and closing and then
> make decisions. There is toctou race in queuePacket():
> {code}
> if (!state.isAlive() || closing) {
> conLossPacket(packet);
> } else {
> ...
> }
> {code}
> A possible race:
> in SendThread.run():
> {code}
> while (state.isAlive()) {
> ...
> }
> cleanup();
> {code}
> When it checks in queuePacket(), state is still alive. Then state isn't
> alive, SendThread.run() cleans up outgoingQueue. Then queuePacket adds packet
> to outgoingQueue. The packet should be waken up with exception. But it won't
> at this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
