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 >
