avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Iourovitski, Ilia" <iiourovit...@ydyn.com>
Subject RE: Non Blocking IO for Cornerstone
Date Thu, 29 Nov 2001 18:11:33 GMT
You may want to look at Medusa, select based web server written in
Python which implements Reactor Pattern.
http://www.nightmare.com/medusa/

The uml diagram is here:

http://www.objectsbydesign.com/projects/python_example.html

Ilia
 

-----Original Message-----
From: Peter Donald [mailto:peter@apache.org]
Sent: Thursday, November 29, 2001 5:19 AM
To: Avalon Developers List
Subject: Re: Non Blocking IO for Cornerstone


On Thu, 29 Nov 2001 09:25, Berin Loritsch wrote:
> I am almost done with the first iteration of Non-Blocking IO for
> Cornerstone. I will commit it as soon as I can get it to compile :p.
That
> way anyone who wants to play with it can--although it probably doesn't
> work.

sounds interesting.

> There is one more abstraction to the whole Connection paradigm to
really
> make Non-Blocking IO effective.  The reason is that the read/write
> mechanisms require the user to know what on earth they are doing.  It
would
> almost be better to have a higher-level block that only has the
> read/write/close methods available.

the best architecture I know about is to change paradigms completely. 
Currently almost all java based applications follow the single thread
per  
connection model. Each thread reads data from a single thread and the 
operates on it and sends it back. Even non-java applications are mainly 
written like this.

However this is woefully innefficient performance wise - much easier to
write 
code though, much much easier to verify that that code is correct and is
less 
buggy.

However if you want to go for real network performance it is pretty much
a 
given that you need to change to an event based architecture. What this
means 
is you usually allocate one thread per CPU to do all your processing.

This single thread does a select() on the relevent resources (ie sockets
in 
our case) and receives events like. 

* 7 bytes received for connection 42
* 7 bytes sent on connection 2 (and thus ready to buffer to send again).

I have seen systems that were previously capable of handling 10
connections 
go up to handling 130 or so using an architecture similar to this. 

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.

Anyways great for performance but can be hell to write servers using
that 
architecture... its part of what I do for my "fun" stuff ... and lets
just 
say it is not fun .. the best it could be described as is "a good
challenge" 
;)

> However, this is probable best as a JDK
> 1.4 only thing as I would like to take advantage of a pool of
> DirectByteBuffers that further speed up communication. If the
communication
> is done via char arrays, byte arrays, or strings, we might be able to
> provide an abstraction--but the issue remains that we still incur a
copy
> overhead.
>
> Maybe we can hash it out later....

kool.

-- 
Cheers,

Pete

*------------------------------------------------------*
| "Common sense is the collection of prejudices        |
|  acquired by age 18. " -Albert Einstein              |
*------------------------------------------------------*

--
To unsubscribe, e-mail:
<mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:avalon-dev-help@jakarta.apache.org>

Mime
View raw message