I know this is not what you want to hear, but I ended up writing my own http client :-/<div><br></div><div>Sincerely,</div><div><br></div><div>jw</div><div><br clear="all"><br>--<br>Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. <br>
<br>
<br><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 5:21 AM, Suma Shivaprasad <span dir="ltr"><<a href="mailto:sumasai.shivaprasad@gmail.com">sumasai.shivaprasad@gmail.com</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>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>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>