On Mon, 2006-10-30 at 02:21 -0800, Dave Irving wrote: > > > Oleg Kalnichevski wrote: > > > > ... If I understand it right, the content generated by > > individual async workers always end up in an intermediate expandable > > buffer, before it gets written to the underlying socket channel. If so, > > under heavy load there is always a chance that the buffer can no longer > > grow due to OFM condition. In my _humble_ and _personal_ option this > > totally defeats all benefits of an async transport versus threaded one. > > > > > > Well yes, in MINA buffers are provided back in to the framework which are > ultimately queued for (NIO) writing by dedicated selector thread(s). Right > now, asyncweb has its own write buffer - but with ASYNCWEB-21 we'll be > writing straight in to these MINA managed buffers. MINA already does buffer > pooling (as does asyncweb for everything except responses pre ASYNCWEB-21) - > so for the most part it is unlikely that there will be a lot of allocation > going on. > With MINA going TLP, it is going to be getting used and tested in a whole > range of high-end network applications. I would certainly expect it to be > very robust (and I think it is already). The challange will be to ensure > that AsyncWeb makes best use of what MINA offers it to ensure that this > robustness is carried across in to asyncWeb. > > But, of course, with any high end server there is going to need to be some > capacity planning. On the incoming side, use of connection throttling, and > per connection + per connector memory usage limits (from MINA) will help > with this. On the outgoing side, we'll again be using pooled buffers. > However, if some application thread does blow up - AsyncWeb will detect this > anyway (timeout) and respond to the ultimate client with an HTTP internal > server error. >
Dave, I'll certainly give AsyncWeb another look when the functionality you are describing is there. Generally, however, it find MINA's memory management framework to be its weakest point. In HttpCore NIO extensions I took especial care to make sure content gets written directly to the socket channel whenever possible, avoiding intermediate buffering altogether. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
