[erlang-bugs] httpc:request_cancel oddities

[Chris King]

One more issue:

The design of httpc_manager/_handler, wherein sessions are (a) committed  
to the DB asynchronously, and (b) not committed until a request is  
complete, results in max_sessions being grossly violated when many  
requests are made in rapid succession.  This makes max_sessions, and  
pipelining in general, nearly worthless -- rapid requests are exactly the  
situation you want pipelining for!


On Wed, 04 Sep 2013 22:39:42 -0400, Chris King <colanderman@REDACTED>  
wrote:

> Furthermore, there's a race condition in the cancel_request handler here:
>
>      case ets:lookup(HandlerDb, RequestId) of
> [...snip...]
>      [{_, Pid, _}] ->
>          httpc_handler:cancel(RequestId, Pid, From),
>          {noreply,
>           State#state{cancel =
>                       [{RequestId, Pid, From} | State#state.cancel]}}
>
> After the ets:lookup, thread death & reuse races with  
> httpc_handler:cancel.  The handler thread then dies when it receives a  
> cancel message for an unknown request.  Easiest (and probably most  
> correct) solution is for the handler thread to ignore cancel messages  
> for unknown requests, rather than dying with function_clause as it  
> currently does.