> From: curl-library [curl-library-bounces_at_cool.haxx.se] on behalf of Joe Mason > [jmason_at_rim.com] > Sent: Tuesday, February 26, 2013 12:24 PM > To: libcurl development > Subject: RE: New pipelining patch > > 530 and 584 seem to be completing successfully but then not exiting, so they > time out. I added debug output around the call to multi_perform in lib530.c: + fprintf(stderr, "Calling multi_perform...\n"); multi_perform(m, &running); + fprintf(stderr, "running now %d\n", running); And set WRITEFUNC to print all data to stderr so that I can see the exact timing compared to the curl events: fprintf(stderr, "handle %d read [%s]\n", i, buf); Now, test530 returns data broken up between requests in a weird way: <data1> HTTP/1.1 200 OK Date: Thu, 09 Nov 2010 14:49:00 GMT Server: test-server/fake Content-Length: 47 file contents should appear once for each file </data1> <data2> HTTP/1.1 200 OK </data2> <data3> Date: Thu, 09 Nov 2010 14:49:00 GMT </data3> <data4> Server: test-server/fake Content-Length: 47 file contents should appear once for each file HTTP/1.1 200 OK Date: Thu, 09 Nov 2010 14:49:00 GMT Server: test-server/fake Content-Length: 47 file contents should appear once for each file HTTP/1.1 200 OK Date: Thu, 09 Nov 2010 14:49:00 GMT Server: test-server/fake Content-Length: 47 file contents should appear once for each file </data4> And stderr530 (attached) shows that 4 handles are created (#0 through #3), and one request each is sent out on each of the four handles. At this point running is 4. Then the response data1 is read on #0, whose state is set to DONE, and running becomes 3. Then data2, data3, and data4 are all read on #3, but its state is not set to DONE, so running remains at 3. Then this loops until timeout: Calling multi_perform... running now 3 I also notice in the log, when the requests after the first are sent: * STATE: INIT => CONNECT handle 0x99c1ddc; line 992 (connection #-5000) * Found bundle for host 127.0.0.1: 0x99d796c * Server doesn't support pipelining * About to connect() to 127.0.0.1 port 8990 (#1) * Trying 127.0.0.1... And then later when we first receive a response: Calling multi_perform. * HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 200 OK That's correct, right? All servers are marked as "do not support pipelining" at first, in case they only support HTTP/1.0, so the 4 requests get sent out on 4 different connections. But it seems odd to me that the responses are read on the same connection. Shouldn't data2 have been sent to handle #1, data3 to handle #2, and data4 to handle #3? (This would seem to be a bug in the test server.) That doesn't explain why #0's state gets set to DONE but #3's does not, though. Even if there's a server bug, I'd expect #3 to be set to DONE at some point after reading the first "Content-Length: 47" plus 47 bytes of body, and then the test to loop at "running now 2".
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html