Closed GoogleCodeExporter closed 8 years ago
memcached ascii protocol will wait indefinitely for a newline at least.
Original comment by dorma...@rydia.net
on 30 Nov 2014 at 1:45
In case the client closes its side the newline cannot obviously arrive. I'd
expect that an end-of-stream instead of newline could be treated as parsing
error. Is this case documented somewhere?
When you say that the protocol will wait indefinitely for newline in that case,
doesn't it mean that the server will keep the connection state which
effectively leaks it?
Original comment by tgrab...@gmail.com
on 30 Nov 2014 at 9:45
end of stream will close the connection internally. there's no way for it to
write an error out at that point, since the connection is now closed.
Original comment by dorma...@rydia.net
on 30 Nov 2014 at 10:25
Is this a limitation which results from the way memcached is implementated?
TCP connections can be closed independently by each side. The client may
shutdown its side, triggering EOF on the server's input pipe and continue to
receive data. The server may still send data and decide on its own when it
closes its side.
Original comment by tgrab...@gmail.com
on 1 Dec 2014 at 8:45
It's not really built to do half-close situations I think... if it detects that
it just blows out.
That might be the wrong thing to do in some situations I guess. I'll give it
some more thought. We do have the quit command, and since it's a
request/response protocol the client is supposed to wait until it receives an
END before dc'ing. This doesn't work well with echo and netcat but isn't
generally a problem with real clients.
Original comment by dorma...@rydia.net
on 1 Dec 2014 at 9:05
Original issue reported on code.google.com by
tgrab...@cloudius-systems.com
on 21 Oct 2014 at 11:39