[erlang-bugs] inets: HTTP client race condition

[Tomas Abrahamsson]

> Today I have encountered strange problem in simple scenario with inets.
> when I'm doing concurrent requests to the same server which responds
> slowly.

Hi, I too have got bitten by this now, so I extended your
test program to not rely on any external web server,
to make it a bit easier to trigger and observe the bug.
Attached is a program that triggers the bug fairly often
in a local environment. Compile it and run it like this:
   erl -s http_client_race_condition go -s erlang halt

Attached is also a patch fixing the problem.
The patch is against R13B01/inets-5.1

It seems the problem is that if one calls http:request and
the httpc_manager selects a session where there's already
a pending request, then the connection handler for that
session effectively resets its parser, readying it for the
response to the second request, but sometimes there are
still some more inbound packets for the response to the
first request, and that's when things get confused.

I did some research: The bug first appeared in
R13A/inets-5.0.13, in which a queue for keep-alive requests
seems to have been introduced. In inets-5.0.12 (R12B-5)
there was only one pipeline queue, but in 5.0.13 there's
also another queue for keep-alive. (I don't know the reason
for there being two queues).

Incidentally, when fixing the problem, the code for handling
the keep-alive queue more and more grew to resemble the
code that handles the pipeline queue. Now it looks much like
two copies of the same code. So someone more knowledgeable
in the art of inets and the pipeline/keep-alive queues might
want to refactor the patched code into something more beautiful.

As you already observed, creating separate profiles works
around the bug. With this patch, it is no longer necessary
to create extra profiles if one wants to send http requests
concurrently.


BRs
Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: http_client_race_condition.erl
Type: text/x-erlang
Size: 4811 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20090820/93e27385/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: httpc_handler.erl.patch
Type: text/x-patch
Size: 3443 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20090820/93e27385/attachment-0001.bin>