hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Berlin" <sber...@gmail.com>
Subject NHttpXXHandler Impl Improvements?
Date Tue, 12 Feb 2008 18:49:22 GMT
Hi Folks,

I think this issue might have been brought up awhile ago (by Steffen,
maybe?), but as we're coming around to using HttpCore for downloading,
I think it's worthwhile to bring it up again.

It seems that there are two default implemenations for
NHttpServiceHandler or NHttpClientHandler, a Buffering & Throttling
variety.  The throttling variety requires a thread for each request
and the buffering variety buffers the entire contents in memory.
We've modified the BufferingHttpServiceHandler to provide asynchronous
handling by using a new interface that extends HttpEntity with the
additional methods:

 int consumeContent(ContentDecoder decoder, IOControl ioctrl);
 void produceContent(ContentEncoder encoder, IOControl ioctrl);
 void finished();

In sendResponse where it normally would ask the entity to write itself
to an outputStream, it instead checks to see if the entity is an
instance of this new HttpEntity subinterface, and if so, sets it
within the ConnState.  In the outputReady method, it retrieves the
entity from the ConnState and asks the entity to produce content
itself (via the above produceContent method), instead of asking the
ContentOutputBuffer to do it.  This bypasses the buffer and allows the
entity some finer-grained control over the writing.  The control is
better because of access to the IOControl object.  This is
particularly useful when reading from disk -- if multiple files are
being uploaded at once and there's a disk-reading service that is
backed up, the entity can ask the control to suspend output requests
until the disk service has returned with some data that can be
written.  As a neat optimization, bypassing the ContentOutputBuffer
avoids allocating some extraneous ByteBuffers, since the entity can
write directly into the ContentEncoder.

What are the chances that changes like this can go into HttpNIO
itself?  Or do you see any way something like this can be done within
the existing framework of the ContentOutputBuffer?  (I'm not married
to the optimization of avoiding allocating the ByteBuffers, but do
require access to the IOControl to suspend/resume input & output.)

My reasons for asking are mainly because right now we maintain our own
implementation of NHttpServiceHandler (and shortly,
NHttpClientHandler), but I'd prefer to see them folded into the
distro, rather than keeping our fork updated.

Thanks,
 Sam

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


Mime
View raw message