That certainly makes sense, speed up performance for network ports IO.
Peter Jones wrote:
Just to be clear, the "com.sun.jini.jeri.tcp.useNIO=true" mode of the
JERI TCP endpoint implementation still uses multiple threads to
dispatch remote invocations-- RMI behavior would be drastically
impacted if it only used a single thread for that (for reasons like
you describe below). It just uses a single thread for performing I/O
operations, at least those that "would block".
-- Peter
On Tue, Jul 14, 2009 at 4:12 PM, Gregg Wonderly<[email protected]> wrote:
The Jini 2.0 software includes the ability to use NIO in the TCP endpoint.
This is activated by system property "com.sun.jini.jeri.tcp.useNIO". If you
look at TcpEndpoint and TcpServerEndpoint, you'll not find much different
going on. The biggest issue with a typical network "distributed" system, is
circular wait that can occur as systems "randomly" develop new connections
to other system. Using a single thread to dispatch events in a server for
"load handling" is not a good thing for any "work" that can have "external"
contact. So, the use of NIO for
"scalability" is find for things that don't end up interacting circularly.
For things that you have no idea how they will interact, it's better to
make sure that you have "new inbound call == new inbound thread" so that you
don't get into problems. It may be that there is some work that you can do
in a single thread, but that usually is something that a specific
application optimizes.
One way to do that is to use inbound calls to "queue" work. But then you
need to use "callbacks" to notify the caller of the results of there
request, unless you design a very custom invocation layer that allows the
use of a "Future" or some other "signaling" mechanism to control when the
result is sent back to the caller.
Gregg Wonderly
