hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Implementing a simple non-blocking echo server
Date Tue, 16 Sep 2014 11:25:50 GMT
On Tue, 2014-09-16 at 11:34 +0100, Daniel Feist wrote:
> Hi,
> 
> This makes sense yes.  I thought it might be related to this, but at the
> same time I'm unsure why the jetty implementation works.  (see
> http://pastebin.com/1Ennis2m)
> 
> Potentially because writing to the ServletOutputStream isn't writing
> directly to the channel as the httpcore ContentEncoder is?

Exactly. Jetty's internal buffer might simply be dynamically expandable.
Generally servlet engines always buffer content in memory at least to a
certain threshold simply because servlet APIs make it very easy to do
stuff like writing out response content and then setting a response
header or a response status.  

Oleg

> 
> On Tue, Sep 16, 2014 at 10:33 AM, Oleg Kalnichevski <olegk@apache.org>
> wrote:
> 
> > On Tue, 2014-09-16 at 00:59 +0100, Daniel Feist wrote:
> > > Hi,
> > >
> > > I'm struggling to implement a simple echo server using http components
> > > aysnc api (HttpAsyncRequestHandler, HttpAsyncResponseProducer,
> > > HttpAsyncRequestConsumer) without using: "response.setEntity(new
> > > InputStreamEntity(requestEntity.getContent(),..,..)".
> > >
> > > This is my attempt:
> > >
> > > http://pastebin.com/Tbz0rxDH
> > >
> > > It seems to work for small http bodies, but as soon as the body size is
> > > larger than the buffer it hangs.
> > >
> > > Anything obvious i'm doing wrong?
> > >
> > > thanks,
> > > Dan
> >
> > Dan
> >
> > I think what is happening is this. Echoer content handler allocates a
> > fixed buffer of 2048 bytes. When the buffer fills up the content handler
> > suspends input. However, HTTP/1.1 is not a full duplex protocol! Well
> > behaved protocol handler is not going to submit a response until the
> > incoming request has been fully consumed. So, in your case the content
> > buffer will never get flushed and the content handler will get stuck
> > forever.
> >
> > One can naturally implement so called 'out of sync' response scheme
> > whereby the server can send a response prematurely. It is subject to
> > discussion as to whether 'out of sync' response scheme is actually
> > legal. Many HTTP clients cannot handle out of sync responses gracefully.
> > (Apache HttpClient, for instance). For compatibility sake the default
> > protocol handler in HttpCore never responds out of sequence.
> >
> > Hope this helps
> >
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >



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


Mime
View raw message