hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DELHOSTE Fabrice <Fabrice.DELHO...@gemalto.com>
Subject Re: Re: Status of AsyncHttpClient
Date Mon, 08 Feb 2010 14:09:10 GMT
Thanks!

> 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.

Actually, in my very first analysis, I think I may be in an architecture that requires NIO
at both server & client sides.
To sum up, I need to build kind of transcoding proxy, supporting thousands of client connections
and connecting to a few web sites on behalf of those clients.
That would allow managing client requests as fast as possible to the backend web servers without
blocking sending threads.

For sure, I want to prototype before and found your interesting code.

> 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.



Ok. It is a good starting point for me, no more :-)






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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message