hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: NHttpXXHandler Impl Improvements?
Date Fri, 15 Feb 2008 11:09:44 GMT

On Thu, 2008-02-14 at 15:40 -0500, Sam Berlin wrote:
> > 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;
> }
> }
> 

Hi Sam,

This starts getting quite complex. It also seems to deviate from the
current design of message elements being plain java beans. Anyways, get
something that works for you and we can spend more time on refining the
API later.


> 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() 

Just throw NotImplementedException or some such 

Adding #getContent() to the base HttpEntity class was the shortcut
Roland had been referring to. It was primarily meant to make HttpEntity
a little friendlier by eliminating the need to case it to sub-interface
in order to make entity's content accessible. Of course, on the downside
this shortcut made things somewhat uglier for non-blocking HTTP, where
it may not always be possible to represent entity content as a stream.


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

I do not think so. It does not seem to be worth the trouble.

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

Could you please open a JIRA ticket for that?

Cheers

Oleg


> Thanks.
> 
> Sam
> 
> ---------------------------------------------------------------------
> 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
View raw message