Suhas Dantkale created ZOOKEEPER-3420:
-----------------------------------------
Summary: With newer ZK C Client and older ZK server, recv_buffer()
could potentially return 0 continuously on non-blocking socket
Key: ZOOKEEPER-3420
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3420
Project: ZooKeeper
Issue Type: Bug
Components: c client
Affects Versions: 3.5.3
Reporter: Suhas Dantkale
With newer ZK C Client (3.5.*) and older ZK server(3.4.*), recv_buffer() could
potentially return 0 continuously on non-blocking socket.
Following in the recv_buffer() snippet:-
Here, should the check be:
if (buff == &zh->primer_buffer && buff->curr_offset + rc == buff->len +
sizeof(buff->len) - 1) ++rc;
instead of
if (buff == &zh->primer_buffer && rc == buff->len - 1) ++rc;
if (buff->buffer) {
/* want off to now represent the offset into the buffer */
off -= sizeof(buff->len);
rc = recv(zh->fd, buff->buffer+off, buff->len-off, 0);
/* dirty hack to make new client work against old server
* old server sends 40 bytes to finish connection handshake,
* while we're expecting 41 (1 byte for read-only mode data) */
if (buff == &zh->primer_buffer && rc == buff->len - 1) ++rc;
switch(rc) {
case 0:
errno = EHOSTDOWN;
case -1:
#ifdef _WIN32
if (WSAGetLastError() == WSAEWOULDBLOCK) {
#else
if (errno == EAGAIN) {
#endif
break;
}
return -1;
default:
buff->curr_offset += rc;
}
}
return buff->curr_offset == buff->len + sizeof(buff->len);
Probably the given code assumes that recv() operation will read in one go.
But on non-blocking socket, that assumption doesn't hold true.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
