I received this on the Chicago Java User Group list and thought I would post my findings.
I’m not a Dr. Dobbs subscriber, so forgive me if this is redundant.
I tried to rewrite a lighweight, stateful IO-and-thread-based server as an NIO-and-selector-based one, but gave up when I ran into a hard limit on the number of channels that a selector can handle (I believe it was 64). I could’ve scaled this with a multi-threaded, multi-selector approach, but the result would have been even more complex than the original. Am I missing something? Thanks in advance.
This is an interesting comment. I’ve heard that NIO on indows has many problems. We have never seen these types of limits or other limitations with NIO running on Linux. Currently, the solution that the article covers is a single selector with a limit of 200 channels. I’ve done a little digging and seen that a 64 channel limit was a win32 library bug that only allowed 64 objects to be in a wait state during IO operations. The bug at Sun is:
This states that this issue was fixed in the 1.4.1 release. If this isn’t the case and you are running 1.5 or 1.4.2, you should re-open the issue with Sun, or if you are brave enough, with Microsoft (hehe). Many folks appear to have solved this using a multi-selector multi-threaded approach.
In terms of a multi-threaded approach, a general good rule of thumb is one selector per CPU. Therefore, if you need more bandwidth and have extra CPUs, you could implement a multi-selector multi-threaded solution. I’ve also seen people suggest that 2-3 selectors and threads per CPU is okay, but I’ve not tried any of these solutions in a high volume production application, so I can’t speak to performance, load and stability. I’d consider upgrading JDK versions to the latest of the line you are using (i.e. 1.4.2_08 for 1.4 and 1.5.0_04 for 1.5) to ensure that you have as many bug fixes in you JVM as possible. This might clear up the problems and not force you to use multiple threads.