Hi,<br><br>Was busy with some other stuff and could not work on this earlier.<br>Tried with inets - 5.6 latest version as well and see the same problem there as well. <br>Now I am able to isolate the cause for this issue. There seems to be a bug with the timeout handling code in http client.<br>
<br>Will try to explain the issue - <br><br>1. Lets say we send request R1 at time T1<br> <br>2. At time T2 =  T1 + 60 secs, R1 errors out with {error, timeout} from http client <br><br>3. At time T3  from the same process we send Request R2 . <br>
<br>4. At time T4 we get a response for R2 with the R1's request id and R1's response data/headers which was supposed to have timed out  at T2 and cleared from the request table.  I could figure this out from the Request ids given by http client for R1 and R2. This is causing a cascading failure of all subsequent requests from the same process. All requests after a timeout from http client are failing   <br>
<br>Can you pls let me know if I can work around this by trying out something on my end or does it require a fix on http client? <br><br>Thanks<br>Suma<br><br><br><br><br><br><br><br><div class="gmail_quote">On Tue, Jun 7, 2011 at 9:19 PM, Ingela Andin <span dir="ltr"><<a href="mailto:ingela@erlang.org" target="_blank">ingela@erlang.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi!<br>
<br>
Do you still get this using inets-5.6? In that case we must<br>
investigate this further?<br>
In such case do you have a minimal example that will reproduce the error?<br>
<br>
Regards Ingela Erlang/OTP team - Ericsson AB<br>
<br>
2011/6/6 Suma Shivaprasad <<a href="mailto:sumasai.shivaprasad@gmail.com" target="_blank">sumasai.shivaprasad@gmail.com</a>>:<br>
<div><div></div><div>> Our app makes a lot of HTTP requests and we are facing this issue with both<br>
> inets-5.5.1 and 5.3.2.<br>
><br>
> Basically our receive clause for the response is trying to match the request<br>
> id returned in httpc:request call<br>
> and we see that the match always fails with the wrong Request Id .<br>
><br>
> We gave seen this mismatch in all 3 receive clauses for<br>
> stream_start, stream and stream_end<br>
><br>
> What we observed after a lot of trial and error  is that if the same pid<br>
> makes  the http requests , the responses get kind of muddled up but if we<br>
> spawn a separate process for the httpc:request ,  it is better . But here<br>
> too we have seen some occurrences of this faulty behaviour.<br>
><br>
> Has anyone faced this issue ?<br>
><br>
</div></div></blockquote></div><br>