"And by confirming you mean you saw the 200 response arrive locally from
the network? "
Yes I did.

"And those 5 still "not processed" responses, they were really complete (ie
had ending indicators according to the HTTP 1.1 spec) and ended or how do
you mean "not processed" exactly? "

That's right. I saw 200 OK responses captured in Wireshark for 200 GETs but
I was handed over 195.

"What did the counter in curl_multi_perform() say about number of pending
transfers?"
It didn't show any. I also added a static counter in multi_addmsg()
function and printed the counter. It was 195.

"What libcurl version on what platorm are you using?"
Curl-7.37

"Was this only plain HTTP requests?"
Yes

 "Can you repeat the problem with (much) fewer requests? Like 5?"
This is not seen with less number of requests.

"After 2000K what? Are you talking about TCP reset? Can you please
elaborate on what you mean."
I meant 200 OK. Yes connection is getting TCP reset. This is less
frequently seen.

If it helps the code is modelled like the one in hiperfifo.c

On Mon, Oct 6, 2014 at 5:31 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Mon, 6 Oct 2014, nikhil ap wrote:
>
> For example, 200 requests are sent but only 195 responses are processed
>> even though 200 OK responses are received by the client.
>> I used wireshark to confirm that all requests are getting responses.
>>
>
> And by confirming you mean you saw the 200 response arrive locally from
> the network? And those 5 still "not processed" responses, they were really
> complete (ie had ending indicators according to the HTTP 1.1 spec) and
> ended or how do you mean "not processed" exactly?
>
> What did the counter in curl_multi_perform() say about number of pending
> transfers?
>
> What libcurl version on what platorm are you using? Was this only plain
> HTTP requests? Can you repeat the problem with (much) fewer requests? Like
> 5?
>
> Which means curl_multi_info_read() is handing over only 195 responses.
>> This is not a right behavior. Any idea as to why this could happen?
>>
>
> I'm not convinced your analysis is correct so I cannot really comment on
> exactly what you see and why. I've never seen this happen nor heard it
> reported before and right now I can't think of a way it can happen. Other
> than that they in fact maybe didn't really end and thus libcurl was waiting
> for the remainder of the reponses...
>
> In certain other cases, after 200OK is processed but curl is immediately
>> sending reset. I would also like to know why.
>>
>
> After 2000K what? Are you talking about TCP reset? Can you please
> elaborate on what you mean.
>
> Is there a way to see what happens behind the scene? Like enable logging
>> so
>> that I can see info level and error logs generated by libcurl
>>
>
> We offer CURLOPT_VERBOSE and CURLOPT_DEBUGFUNCTION, but no more info than
> so. The next step after that is plain old debugging and added
> infof()/printf() statements!
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html

-- 
niks

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-10-07