[
https://issues.apache.org/jira/browse/ZOOKEEPER-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119557#comment-13119557
]
Camille Fournier commented on ZOOKEEPER-1197:
---------------------------------------------
One more update for this. After talking to some folks here that are more
networking experts than I am, it appears that the only way to truly fix this
bug is to allow the client to initiate the close of the socket, not the server.
Because a socket close event (especially in recent Linux kernels) may cause the
kernel to give up on sending data even when the server has not
finished/received acks, the only way to guarantee that a client has actually
received all the data is to wait for the client to close the connection. We can
add a timeout in the server to clean up 4lw clients that have not closed their
connection, but we cannot rely on all of the data getting to the client without
an explicit client close.
> Incorrect socket handling of 4 letter words for NIO
> ---------------------------------------------------
>
> Key: ZOOKEEPER-1197
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1197
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.3.3, 3.4.0
> Reporter: Camille Fournier
> Assignee: Camille Fournier
> Priority: Blocker
> Fix For: 3.3.4, 3.4.0, 3.5.0
>
> Attachments: ZOOKEEPER-1197.patch
>
>
> When transferring a large amount of information from a 4 letter word,
> especially in interactive mode (telnet or nc) over a slower network link, the
> connection can be closed before all of the data has reached the client. This
> is due to the way we handle nc non-interactive mode, by cancelling the
> selector key.
> Instead of cancelling the selector key for 4-letter-words, we should instead
> flag the NIOServerCnxn to ignore detection of a close condition on that
> socket (CancelledKeyException, EndOfStreamException). Since the 4lw will
> close the connection immediately upon completion, this should be safe to do.
> See ZOOKEEPER-737 for more details
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
