[erlang-questions] Http client sending http response to wrong handler

[Suma Shivaprasad]

Hi,

Was busy with some other stuff and could not work on this earlier.
Tried with inets - 5.6 latest version as well and see the same problem there
as well.
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.

Will try to explain the issue -

1. Lets say we send request R1 at time T1

2. At time T2 =  T1 + 60 secs, R1 errors out with {error, timeout} from http
client

3. At time T3  from the same process we send Request R2 .

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

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?

Thanks
Suma







On Tue, Jun 7, 2011 at 9:19 PM, Ingela Andin <ingela@REDACTED> wrote:

> Hi!
>
> Do you still get this using inets-5.6? In that case we must
> investigate this further?
> In such case do you have a minimal example that will reproduce the error?
>
> Regards Ingela Erlang/OTP team - Ericsson AB
>
> 2011/6/6 Suma Shivaprasad <sumasai.shivaprasad@REDACTED>:
> > Our app makes a lot of HTTP requests and we are facing this issue with
> both
> > inets-5.5.1 and 5.3.2.
> >
> > Basically our receive clause for the response is trying to match the
> request
> > id returned in httpc:request call
> > and we see that the match always fails with the wrong Request Id .
> >
> > We gave seen this mismatch in all 3 receive clauses for
> > stream_start, stream and stream_end
> >
> > What we observed after a lot of trial and error  is that if the same pid
> > makes  the http requests , the responses get kind of muddled up but if we
> > spawn a separate process for the httpc:request ,  it is better . But here
> > too we have seen some occurrences of this faulty behaviour.
> >
> > Has anyone faced this issue ?
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110713/e6bd40f2/attachment.htm>