Hi, Jetty uses a default output buffer of 64KB, although the echo implementation I referenced works beyond this buffer size too. When the internal buffer is full it writes to response channel, only closing (and flushing?) the channel once the request has been fully read and processed and response written.
Forgetting Jetty now, playing around more with HttpCore I see this behaviour when debugging my implementation. Is this right? - When the buffer size is smaller that the request body I'm using IoCtrl to suspend input and request output. - Because the ContentDecoder is not completed AsyncHttpHandler#handle is never called and my HttpAsyncResponseProducer never submitted (using httpexchange.submitResponse). - As such, when org.apache.http.nio.protocol.HttpAsyncService#responseReady is called there is no HttpAsyncResponseProducer available. - Because there is not HttpAsyncResponseProducer available, the buffer is never read and IoCtrl.requestInput is never called to continue reading the body. I know what i'm trying to implement to learn httpcore may seem kind of artificial, but i'm struggling to make sense of this behaviour in the implementation. Or is it simply that this is deliberate because handling the request and processing the response makes no sense at all until the request body has been fully read? Am i Ignoring what i've been playing with, what is the best, most efficient way, of implementing a AsyncEchoHandler with httpcore? thanks! On Tue, Sep 16, 2014 at 12:25 PM, Oleg Kalnichevski <[email protected]> wrote: > 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 <[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] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
