On Tue, 2008-02-12 at 13:49 -0500, Sam Berlin wrote: > Hi Folks, > > I think this issue might have been brought up awhile ago (by Steffen, > maybe?), but as we're coming around to using HttpCore for downloading, > I think it's worthwhile to bring it up again. > > It seems that there are two default implemenations for > NHttpServiceHandler or NHttpClientHandler, a Buffering & Throttling > variety. The throttling variety requires a thread for each request > and the buffering variety buffers the entire contents in memory. > We've modified the BufferingHttpServiceHandler to provide asynchronous > handling by using a new interface that extends HttpEntity with the > additional methods: > > int consumeContent(ContentDecoder decoder, IOControl ioctrl); > void produceContent(ContentEncoder encoder, IOControl ioctrl); > void finished(); > > In sendResponse where it normally would ask the entity to write itself > to an outputStream, it instead checks to see if the entity is an > instance of this new HttpEntity subinterface, and if so, sets it > within the ConnState. In the outputReady method, it retrieves the > entity from the ConnState and asks the entity to produce content > itself (via the above produceContent method), instead of asking the > ContentOutputBuffer to do it. This bypasses the buffer and allows the > entity some finer-grained control over the writing. The control is > better because of access to the IOControl object. This is > particularly useful when reading from disk -- if multiple files are > being uploaded at once and there's a disk-reading service that is > backed up, the entity can ask the control to suspend output requests > until the disk service has returned with some data that can be > written. As a neat optimization, bypassing the ContentOutputBuffer > avoids allocating some extraneous ByteBuffers, since the entity can > write directly into the ContentEncoder. > > What are the chances that changes like this can go into HttpNIO > itself?
Pretty much 100% if this code comes with a reasonable test coverage. Moreover, the contributor of this code will qualify for a full committership on the project for such such a substantial contribution, in my opinion. > Or do you see any way something like this can be done within > the existing framework of the ContentOutputBuffer? (I'm not married > to the optimization of avoiding allocating the ByteBuffers, but do > require access to the IOControl to suspend/resume input & output.) > I'll happily deprecate the buffering kind of protocol handlers in favor of the new one, instead. > My reasons for asking are mainly because right now we maintain our own > implementation of NHttpServiceHandler (and shortly, > NHttpClientHandler), but I'd prefer to see them folded into the > distro, rather than keeping our fork updated. > > Thanks, > Sam > > --------------------------------------------------------------------- > 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]
