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? On Tue, Sep 16, 2014 at 10:33 AM, Oleg Kalnichevski <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
