> Drop the "Content" prefix?
Done.
> This sounds a lot like the Incoming/Outgoing entities
> I originally suggested for HttpCore and which were
> thrown out because they generated too much problems.
> But at the time we also had the distinction between
> modifiable and non-modifiable entities. Is that the
> reason why the approach should now work for HttpNIO?
Not sure on the reasons for HttpCore -- but it's working out real well
for HttpNIO. I've avoided trying to even think about what can change
in HttpCore, mainly because I think it's pretty solid as-is, and don't
wanna rock the boat too much.
....
I've got an AsyncNHttpServiceHandler pretty much nailed down, for the
server side. There's a few rough spots I'm hitting with the client
side. For starters, the ConsumingNHttpEntity had to change a bit.
The current incarnation is:
public interface ConsumingNHttpEntity extends NHttpEntity {
int consumeContent(ContentDecoder decoder, IOControl ioctrl) throws IOException;
void setContentListener(ContentListener listener);
public static interface ContentListener {
int contentAvailable(ContentDecoder decoder, IOControl ioctrl)
throws IOException;
}
}
The idea is that someone in order to have something equivalent to
getContent() in a non-blocking context, you need to be notified when
content is available so you can read it. In this scheme, when
something is handed the ConsumingNHttpEntity, it installs a listener
and that listener is then told when content is available in that
entity. This calls for a DefaultConsumingNHttpEntity class (somewhat
similar to BasicHttpEntity), and removes the need for
ContentBufferEntity.
I'm having a little trouble fitting this into the current service
handling scheme. In the ThrottlingServiceHandler, the handler's given
the entity in a new thread, so it can leisurely read data out of it
while the I/O thread pushes data in. In the BufferingServiceHandler,
the entity is buffered into memory before the handler's given the
request, so the handler can guarantee it won't block any I/O. The
problem is that with the new scheme, there doesn't seem to be a good
way to require that the handler not use getContent() -- because if it
does, the only way to make it work is to do it in a new thread (and
we'd only figure that out after-the-fact). One potential solution is
to introduce a new subinterface of HttpRequestHandlerResolver &
HttpRequestHandler (NHttpRequestHandlerResolve & NHttpRequestHandler)
that do the exact same thing, except implementions of
NHttpRequestHandler are told *not* to use getContent(). (There can be
an implementation that delegates to non NHttpRequestHandlers that
handles them in a new thread, to take care of migration.)
Do you think the new NHandler interfaces are necessary or even useful?
Would it be better to just not worry about it, and if existing code
changes to use an AsyncHttpServiceHandler, it also has to update its
HttpRequestHandlers?
On a side note -- I think there's a small bug in
ThrottlingHttpServiceHandler. What happens if a POST comes in for
which there's no handler? It looks like a response SC_NOT_IMPLEMENTED
will be sent, then it flows through and the connState is reset, but
not all the data could have been read out of the inbuffer. I think
this will cause further requests to read the wrong stuff.
Thanks.
Sam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
