After looking through things, there seems to already be somewhat of an
infrastructure for NIO entities using the
o.a.http.nio.entity.HttpNIOEntity and its subclasses. Those entities
appear to expose a 'getChannel' method (used right now just in the
NHttpFileServer example). I propose a change in that interface, to
make it a little more analagous to the HttpEntity interface.
Currently HttpEntity has a blocking 'writeTo' method and a
'getContent' method returning the InputStream. HttpNIOEntity just has
the 'getChannel' method, but no non-blocking 'produceContent' method.
Is it OK right now to completely change interfaces/classes in
http-nio? If so, I would like to make HttpNIOEntity into a copy of
the HttpNIOEntity we're using internally. That is:
/**
* Defines an interface for event based HTTP entities.
*/
public interface HttpNIOEntity extends HttpEntity {
/**
* Reads data from <code>decoder</code>.
*
* @param decoder the decoder for reading input
* @param ioctrl I/O control for suspending and resuming events
* @return the number of bytes read
* @throws IOException indicates an I/O error which will abort the
* connection
*/
int consumeContent(ContentDecoder decoder, IOControl ioctrl)
throws IOException;
/**
* Writes data to <code>encoder</code>.
*
* @param encoder the encoder for writing output
* @param ioctrl I/O control for suspending and resuming events
* @throws IOException indicates an I/O error which will abort the
* connection
*/
void produceContent(ContentEncoder encoder, IOControl ioctrl)
throws IOException;
/**
* Invoked when processing has completed. This completes the transfer of the
* entity and is invoked when processing finishes normally, i.e.
* [EMAIL PROTECTED] ContentEncoder#isCompleted()} or
* [EMAIL PROTECTED] ContentDecoder#isCompleted()} return true, or when an
exception
* occurs.
*/
void finished();
}
This moves the burden of reading/writing non-blocking content to the
entity itself (much like it already does for writing, using writeTo).
Retrieving the channel is removed because it becomes unnecessary (and
could be cumbersome for some entities). The 'finished' method is to
signal that the entity can reclaim resources, and would be called when
the connection closes or the entity has completed its writing|reading
(according to the encoder|decoder).
Given that all entities are created within the Service|ClientHandlers
or within NHttpConnectionBase, it should be pretty easy to require
that all entities used in an NIO context implement this new
HttpNIOEntity. And the fact that the interface & some implementations
already exist makes things a little easier, because the planning
already is done. It's just the use of the classes (and when they're
used) that needs to change.
Any thoughts on the approach? I haven't fully examined the 'client'
side of it yet -- am mostly approaching it on the server-side right
now, so there could be hitches there.
Sam
On 2/12/08, Sam Berlin <[EMAIL PROTECTED]> wrote:
> > Pretty much 100% if this code comes with a reasonable test coverage.
> > Moreover, the contributor of this code will qualify for a full
> > committership on the project for such such a substantial contribution,
> > in my opinion.
>
> Cool, Ok. I'll see how it goes (and if the buffered scheme can be
> deprecated).
>
> Sam
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
