Comment #10 on issue 106 by [email protected]: binary protocol parsing can
cause memcached server lockup
http://code.google.com/p/memcached/issues/detail?id=106
The incoming packet is consumed in try_read_udp(), so if you get into a
conn_close state after reading one packet, calling an empty recvfrom will
consume the *next*, unseen packet.
Unless there is some case you're talking about which causes the next packet
on the wire to be an error?
I did push my tree though, so take a look at what I ended up with:
https://github.com/dormando/memcached/commit/954f6dddc41c80d2e625bce63744df5556a425bb
... I can't break it with your tests anymore, and it doesn't hang before
responding. If you look at how TCP connections are intialized, you'll see
they're set to conn_new_cmd, but the UDP listeners are initialized to
conn_read. The latter makes sense in the flow.
Either way, can you try the patch and see if you can still break it? :)
