<div dir="ltr">We've taken a similar approach, inspired by Fred's fork of lhttpc, but built on top of ibrowse. For us as well, the use case is handling many connections to a small set of servers.<div><br></div><div>
<a href="https://github.com/opscode/opscoderl_httpc">https://github.com/opscode/opscoderl_httpc</a><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 9, 2013 at 5:14 AM, Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You might be interested in my fork of lhttpc:<br>
<a href="https://github.com/ferd/lhttpc" target="_blank">https://github.com/ferd/lhttpc</a><br>
<br>
It's pretty much regular lhttpc, but I added sharded connection pools to<br>
it. It has been especially optimized for doing a lot of requests to a<br>
limited set of endpoints, and was developed during my stay at AdGear for<br>
real time bidding purposes. It's also used at other real time bidding<br>
shops now.<br>
<br>
It will not do request cancelling the way you mention it. It has a<br>
central load-balancer per endpoint, where you ask for sockets. It's easy<br>
to cancel a task once you have the connection yourself, but not during<br>
the time it's in the queue to the manager.<br>
<br>
If you kill the process that made the request, the manager will find out<br>
once it tries to give away the process and keep going until it hits a<br>
request that works<br>
(<a href="https://github.com/ferd/lhttpc/blob/master/src/lhttpc_lb.erl#L98" target="_blank">https://github.com/ferd/lhttpc/blob/master/src/lhttpc_lb.erl#L98</a>)<br>
<br>
That might be suboptimal behavior in your case.<br>
<br>
I also have a fork of that very load balancer done using dispcount<br>
called dlhttpc: <a href="https://github.com/ferd/dlhttpc" target="_blank">https://github.com/ferd/dlhttpc</a><br>
<br>
Dispcount is a low-latency pool (<a href="https://github.com/ferd/dispcount" target="_blank">https://github.com/ferd/dispcount</a>) that<br>
basically will tell you right away if you can have a resource or not.<br>
There will be no such thing as a blocking request using dlhttpc because<br>
the pooling model doesn't allow for an explicit request queue. It<br>
instead uses a pool of workers that may or may not be connected (in the<br>
case of dlhttpc, each worker will only connect once asked for it, but<br>
processes will be started already), and assumes you will retry until you<br>
hit one you need. It's been designed with cases of constant overload in<br>
mind, where you may arbitrarily decide to drop a request from the<br>
call-site.<br>
<br>
Depending on how flexible your requirements are, I'd try at least one of<br>
these libraries to see how they fare.<br>
<br>
lhttpc has been in production for a long while now and has been fairly<br>
stable as far as I can tell, everywhere it's been deployed. dlhttpc has<br>
seen no real production use, but dispcount has, so it's not too likely<br>
to be a terrible thing to deploy.<br>
<br>
Regards,<br>
Fred.<br>
<div class="HOEnZb"><div class="h5"><br>
On 09/08, Chris King wrote:<br>
> On Sun, 08 Sep 2013 19:33:05 -0400, Bob Ippolito <<a href="mailto:bob@redivi.com">bob@redivi.com</a>> wrote:<br>
><br>
> >Async cancelable and synchronous are basically isomorphic in<br>
> >Erlang, just start a process to wrap the sync call and kill >it if<br>
> >you want to cancel.<br>
><br>
> Not quite -- the HTTP request remains outstanding and blocks the<br>
> request queue.  I need to clear those requests out, as I need to<br>
> process new requests ASAP.  This should be handled by the HTTP<br>
> client itself, as only it knows how many requests it has actually<br>
> sent to the server.  (The alternative would be for the HTTP client<br>
> to expose a crediting mechanism; though this would complicate the<br>
> application.)<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<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>
_______________________________________________<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Seth Falcon | @sfalcon | <a href="http://userprimary.net/">http://userprimary.net/</a>
</div>