On Fri, 30 Nov 2001 08:38, Jeff Turner wrote: > On Fri, Nov 30, 2001 at 12:18:34AM +1100, Peter Donald wrote: > [..] > > > Actually a while back there was some hubub because someone wrote a java > > webserver that behaved like this and it beat the pants off all the major > > native webservers (even those with all the fancy kernel hooks). Can't > > remember exact details but I believe the guy was one of the people on the > > spec for NIO and that he had already written his own non-blocking io API > > as part of an academic project. > > I think you're referring to Matt Welsh's SEDA and nbio projects: > > http://www.cs.berkeley.edu/~mdw/proj/seda/ > "SEDA is an acryonym for staged event-driven architecture, and > decomposes a complex, event-driven application into a set of stages > connected by queues. This design avoids the high overhead associated > with thread-based concurrency models, and decouples event and thread > scheduling from application logic." > > http://www.cs.berkeley.edu/~mdw/proj/java-nbio/ > > The PDF paper on SEDA makes for good reading on the train.
yep - thats the one. Brilliant work. Another tasty look is the ACE framework (Adaptive Communication Environment?) which has extensive documentation on these sort of patterns. Great documentation ... slightly overdesigned and made a few C++ specific assumptions but great work none the less. > Makes me wonder.. do people *want* massive concurrency? Is performance > really an issue with current server architectures? I'm sure it is in > some cases, but the rest.. in some cases it is vital. When you need to support massive concurency - like I do with my simulation/game architecture then there is no real alternative. It becomes a lot easier to support these kind of architectures when you are dealing with a request/response architecture that has clearly defined PDUs and so forth. > I suspect plain old manageability and ease of use are more important. yep - most of the time ease will win out. However with a number of our abstraction layers (ie servlets for webpages) it could easily be implemented. We could send and receive data from one thread and then send "events" to ServletContainer when the full request has arrived or all data has been flushed or whatever. That way you could minimize the amount of time that the servlets will spend blocking on data and so forth. > Still, it would be fun to play with. I don't know if fun is the word to I would use to describe it - maybe "challenging" ;) -- Cheers, Pete The big mistake that men make is that when they turn thirteen or fourteen and all of a sudden they've reached puberty, they believe that they like women. Actually, you're just horny. It doesn't mean you like women any more at twenty-one than you did at ten. --Jules Feiffer (cartoonist) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
