Status of AsyncHttpClient

[DELHOSTE Fabrice <Fa...@gemalto.com>]

Hi,

In the scope of an important project, I'm strongly interested in the high-level asynchronous http client (pooling, ...) available only in the SVN repo rather than reinventing the wheel (round if possible ;-)
I've read the exchange discussed a few months ago and the code drop.

What's the status today on this toolkit? Is it planned to become part of HttpCore NIO?
Do you think it is far from production quality?
If not, what would you recommend as a reliable HTTP client layer with pooling/server facilities, ... ?

Thanks,
Fabrice

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

Re: Status of AsyncHttpClient

[Oleg Kalnichevski <ol...@apache.org>]

On Mon, 2010-02-08 at 11:49 +0100, DELHOSTE Fabrice wrote:
> Hi,
> 
> In the scope of an important project, I'm strongly interested in the high-level asynchronous http client (pooling, ...) available only in the SVN repo rather than reinventing the wheel (round if possible ;-)
> I've read the exchange discussed a few months ago and the code drop.
> 
> What's the status today on this toolkit? Is it planned to become part of HttpCore NIO?

It may eventually evolve into a subproject within HC provided there are
enough people willing to contribute to it. I see no point in developing
it all by myself, as I am not a great believer in benefits of NIO model
for client side HTTP in the first place.

> Do you think it is far from production quality?

The async client currently lack even the most basic features and nowhere
near production quality. Currently it is nothing more than HttpCore NIO
plus connection pooling.


> If not, what would you recommend as a reliable HTTP client layer with pooling/server facilities, ... ?
> 

I took a very brief look at the latest Jetty HttpClient and had an
impression it was always buffering the entire response body in memory,
which in my opinion makes it unfit for anything other than highly
special use cases where content entity are known to be of limited
length. I may well be wrong, though, as I only had a cursory look at the
source code.

Oleg


> Thanks,
> Fabrice
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org