geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: NIO
Date Sat, 09 Aug 2003 22:01:34 GMT
On Sat, 9 Aug 2003, Richard Monson-Haefel wrote:
> +1.  NIO is very important to creating a J2EE application server that is high
> performance.  I/O (to file or network) is the biggest bottle neck in
> application servers (and just about everything else for that matter.). Using
> NIO should be a priority for this project.

	Can we talk about where?  It's fairly new to me, but:

 - when accepting connections in the first place, we can use asynchronous 
I/O to have a small number of threads pull requests from a larger number 
of sockets

 - one a request is in, we are pretty much stuck with one thread escorting 
it through its life (right?), except:

 - theoretically, if the thread ends up making a remote call, we could go
asynchronous again until the call returns fully (the processor thread
could go on to do something else in the mean time).  But if the original
thread does not resume processing when the call returns, we'll need to set
up the thread context again when the call returns, which may or may not be
more trouble than it's worth

 - if the thread ends up making a DB call, there's little we can do since 
the JDBC driver is responsible for the networking in that case

 - if we're doing large scale file I/O (when originally processing an EAR, 
I guess?), perhaps we can use memory-mapped files and other trickery?  I'm 
not sure what types of operations would really be sped up by this.

	Are there other places we can use NIO to our advantage?

Aaron


Mime
View raw message