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