Do you like playing detective and solving mysteries? Performance problems come in many guises, giving you ample opportunity to indulge your clue-hunting proclivities to identify and resolve them. The main man behind the MegaJogos multi-player game site and a member of the Java Games community, recently altered the application behind the site to use the NIO package to enhance its scalability.
MegaJogos: The case of the fully utilized CPU
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
and how trivial can an article about nio and scalability be?
The reason behind the 1000 threads limit was not explored at all, in spite of the insights into java & linux that can be gained.
Not Eugenia’s fault though. Just surprised that such a shallow article appears in ibm’s developer’s library.
This article was nice and light and a good sell for NIO.
I have written a few trivial servers without NIO, in the traditional one-thread-per-client manner. Seems that his new approach outlined is much more like thttpd.
So how does this select() differ from just using available() and only reading what you know is in the buffer with the old blocking sockets code?
I have written a few trivial servers without NIO, in the traditional one-thread-per-client manner. Seems that his new approach outlined is much more like thttpd.
So how does this select() differ from just using available() and only reading what you know is in the buffer with the old blocking sockets code?
Select allows you to pass the task of monitoring the connections to the application to Java. This allows you to handle more concurrent connections then you could with the more traditional method of one-thread-per-client. Honestly I think the article could have done a better job at explaining the concepts of the Selector but who am I to criticize. The 100% CPU usage sounds more like a bug or misuse in his code then NIO. My guess would be that the channel is getting marked as writable but when data is written to the socket it is never cleared from the Selector. I would need to see more of the code to be sure though.
Code bug indeed, and problem encountered by all novice developers, be in in C or Java nio.
The 100% cpu is just because the selector select() call return immediately because you *could* write to it without blocking.
If you don’t actually have anything to write, *do not register* to the selector for the WRITE op and the select() will block, consuming 0% cpu.
If you don’t actually have anything to write, *do not register* to the selector for the WRITE op and the select() will block, consuming 0% cpu.
You are of course correct. I made an (unwise) assumption that they had something to write immediately upon connection.