On Sat, 2006-10-07 at 12:33 -0400, Sam Berlin wrote: > The third choice should be an option for users who want to take the > full advantage that NIO offers. Anything less is giving up some of > the main features of NIO. But you're correct -- not as many > developers are familiar with channels / buffers as they are with > streams. I recommend exposing the API via the third choice, but > having an additional layer that can wrap the buffer into a stream. > > You can do this via something like: > Pipe pipe = Pipe.open(); > SinkChannel /* a WritableByteChannel */ sink = pipe.sink(); > // written to with: sink.write(myBuffer); > SourceChannel /* a ReadableByteChannel */ source = pipe.source(); > InputStream input = Channels.newInputStream(source); > // Now all data written to 'sink' can be read from 'input' > > The only difficult is that sink.write(...) has the potential to block > until input gobbles data from it. This would mean that writing from > the buffer into the sink would have to be done in a different thread > than the Selector thread. > > Sam >
Hi Sam, I am still quite skeptical about usefulness of a fully event-driven HTTP transport for one simple reason: asynchronous (non-blocking) I/O transport makes no sense of what so ever if the process of content generation or content consumption is asynchronous (blocking). If one needs a worker thread to generate / process content anyways, what is the point of having an even driven transport? One is much better off using streams. The only type of channels in Java that are non-blocking is socket channels. File channels are blocking. I see only a few scenarios where the third choice (event callbacks) may prove advantageous, primarily in HTTP proxies and gateways. If the HTTP service is not intended to generate any content but rather to dispatch all data it receives (with some modifications) to another target, in this scenario one does not really need a worker thread per request / response and may actually want to employ an event based API. I think ultimately we need both options. I suggest we start with the second option, release ALPHA3 and then consider implementing the third option before ALPHA4 / BETA1. Many thanks for your input. Cheers Oleg > On 10/7/06, Roland Weber <[EMAIL PROTECTED]> wrote: > > Hi Oleg > > > > > Yes, something similar but not quite the same. I am thinking about > > > having an event driven architecture of some sort, but I certainly do not > > > want to go the same route asyncweb folks did with regards to memory > > > management. As far as I know asyncweb buffers content in memory and can > > > be prone to 'out of memory' conditions even when serving moderate > > > amounts of data under heavy load. In my humble opinion this is way worse > > > then dropping incoming connections due to the worker thread pool > > > depletion, because the former gives the clients a very clean and > > > reliable recovery mechanism, whereas the latter does not. Dropping the > > > connection due to the out of memory condition after having processed the > > > request while sending out the response is a complete insanity. > > > > I was already wondering what drawbacks asyncweb might have. > > The story of never blocking anything just sounded too good. > > > > > So, in my opinion there are several options we could pursue. > > > > > > (1) Never ever block I/O in HTTP service. As a consequence always buffer > > > content in memory. This approach is flawed, but is relatively simple. > > > > Rather not. > > > > > (2) Always block I/O in HTTP service when serving potentially large > > > entities in order to prevent session buffer overflow. Requires a worker > > > thread per large entity content stream. > > > > Based on my limited understanding of NIO, this option sounds best. > > It should allow for both blocking and non-blocking operation, with > > a mix of buffering and non-buffering. Or am I getting something wrong? > > > > > (3) Do not use streams. Use callbacks for I/O events that take NIO > > > buffers as parameters. > > > > This *sounds* good, but somehow I don't buy the story. Our entities > > are based on streams. File IO is based on streams. Many developers > > are familiar with streams. There's nothing wrong with having callbacks > > as an option, but I'd rather not have them as the only option. > > > > cheers, > > Roland > > > > > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
