Not reading server responses will hang the server

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Issue a lot of commands
2. Don't read the responses from the server
3. Eventually the server will hang and lockup

What is the expected output? What do you see instead?

The server should probably disconnect the client when the client exhibits this 
bad behavior

What version of the product are you using? On what operating system?

memcached 1.2.8

ubuntu jaunty

Please provide any additional information below.

Original issue reported on code.google.com by fallenpe...@gmail.com on 28 Oct 2009 at 1:08

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I am pretty sure this is a client bug and not a server bug due to the way the 
server
works. The server will read one command from the client, process the request 
and then
start sending the response. The server will use nonblocking IO, and when it 
blocks on
writing it will just suspend that client and start serving the next client. Some
clients will however use blocking IO causing them to block on write because the 
input
buffer is full. It may appear that the server is stuck but if you try to add a 
second
connection to the server you will see that you are able to execute commands 
there.

I've pushed a test case for 1.4.x to
http://github.com/trondn/memcached/tree/issue_101 that verifies this. The test 
case
starts a memcached server and creates two non-blocking connections to send the 
stats
command without reading the response. When I have filled both pipes, I fork off 
a
child and runs the noop command to the server before it exits.

Original comment by trond.no...@gmail.com on 28 Oct 2009 at 9:26

• Changed state: Invalid

[GoogleCodeExporter]

I pushed this test in anyway.  I figured the test shows that it doesn't break.  
If
someone is dissatisfied with the test at some point, it'd be a good starting 
point
for coming up with a better one.

In the meantime, the test shows that this behavior does not occur.

Original comment by dsalli...@gmail.com on 29 Oct 2009 at 3:14

[GoogleCodeExporter]

I just built memcached-1.4.20 on RHEL6 against libevent-1.4.13, that come from 
RedHat and had no problems.

I then read, that using libevent-2.x improves performance substantially, and 
tried using that. Memcached builds fine:
% ldd ...../BUILD/memcached-1.4.20/memcached-debug 
        linux-vdso.so.1 =>  (0x00007fffe17ff000)
        libevent-2.0.so.5 => /local/packages/libevent/lib64/libevent-2.0.so.5 (0x00007fab2c0af000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fab2bea6000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fab2bc89000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fab2b8f6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fab2c308000)

but the self-test fails:
...
ok 8 - strtol
ok 9 - strtoll
ok 10 - strtoul
ok 11 - strtoull
ok 12 - issue_44
ok 13 - vperror
< HANG >

The stderr fills up with messages repeated as much as the xterm can handle:
[warn] libevent2 event_del: event has no event_base set

I disabled the warning-message with the attached patch, but the test 14 
(issue_101) still hangs.

Again, when using libevent-1.4.x everything is fine... Please, advise -- I 
would like to use libevent-2.x if possible. Thank you!

Original comment by virtuale...@gmail.com on 13 May 2014 at 6:41

Attachments:

• patch-event_del

[GoogleCodeExporter]

Commented-out issue_101 from testapp.c and tried again. The "start_server" -- 
one after "issue_101" -- succeeded, but the subsequent "issue_92" hangs...

Original comment by virtuale...@gmail.com on 13 May 2014 at 7:05

[GoogleCodeExporter]

Why did you decide to necro a dead issue rather than open a new one?

this is an incredibly obnoxious habit people have, but I don't see any way to 
lock issues without deleting them..

This old issue isn't related to what you're asking about at all, please file a 
new one.

Original comment by dorma...@rydia.net on 13 May 2014 at 8:02