NIO

["Noel J. Bergman" <no...@devtech.com>]

Michael Remijan wrote:

> I thought it would be assumed that the NIO packages would be the way to
go.

I agree.  The problem is that most people have no idea how to use NIO and
J2EE properly.  I have had this discussion with the NIO lead, and I hope
that if we can provide a high signal, low noise opprotunity, he can provide
his input.  As a start, I've a pending e-mail to him asking for an outline
of how he sees NIO employed in a J2EE container.  I know how *I* believe it
should work (and works well), but I want to have his input for everyone.

	-- Noel

Re: NIO

[Aaron Mulder <am...@alumni.princeton.edu>]

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

Re: NIO

[Richard Monson-Haefel <Ri...@Monson-Haefel.com>]

+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.

"Noel J. Bergman" wrote:

> Michael Remijan wrote:
>
> > I thought it would be assumed that the NIO packages would be the way to
> go.
>
> I agree.  The problem is that most people have no idea how to use NIO and
> J2EE properly.  I have had this discussion with the NIO lead, and I hope
> that if we can provide a high signal, low noise opprotunity, he can provide
> his input.  As a start, I've a pending e-mail to him asking for an outline
> of how he sees NIO employed in a J2EE container.  I know how *I* believe it
> should work (and works well), but I want to have his input for everyone.
>
>         -- Noel

--
Richard Monson-Haefel
Author of J2EE Web Services (Addison-Wesley 2003)
Author of Enterprise JavaBeans, 3rd Edition  (O'Reilly 2001)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.Monson-Haefel.com