On Mon, 2010-02-08 at 15:09 +0100, DELHOSTE Fabrice wrote:
> 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.
>
This is a whole different story. In this particular scenario the NIO
model makes good sense. Actually, HttpCore NIO was developed primarily
to facilitate development of HTTP services intended to act as a proxy or
a gateway to external services, where a great number of concurrent
outgoing ('client') connections may be required in order to provide
content for a great number of concurrent incoming ('server')
connections.
Cheers
Oleg
> 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: [email protected]
> > For additional commands, e-mail: [email protected]
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
