Skip to main content

Get Rhythm

Posted by editor on February 13, 2007 at 7:58 AM PST

The back-and-forth of high-performance servers

If you're working with the low-level I/O of a server, it's pretty much a no-brainer that performance concerns will probably compel you to use the NIO package, introduced in Java 1.4. But once you've made that choice, do the rest of the pieces fall into place easily? Hardly. You also have significant threading issues to consider. It's easy enough to dispatch each request to its own thread, but this ends up not scaling particularly well.

In our Feature Article,

Architecture of a Highly Scalable NIO-Based Server , Gregor Roth argues for a different architecture, one which responds to events (such as requests) and employs a thread pool to do the non-blocking IO work needed for each request.

An event-driven non-blocking architecture is a fundamental layer to implement highly efficient, scalable, and reliable servers. The challenge is to minimize the thread synchronization overhead and to optimize the connection/buffer management. This will be the hardest part to program.

Of course, easier said than done. Check out the article for both the ideas behind the architecture, and links to servlet frameworks that already implement this approach for you.

In Java Today,
the ROME project offers a popular set of parsers and generators for various RSS and Atom syndication formats, and the wiki page Products or sites powered by ROME reveals just how widespread its use is. Take a look and see how many major sites you recognize. The page also offers a set of "Powered By ROME" badges to put on your site.

Jiri Sedlacek's article Uncovering Memory Leaks Using NetBeans Profiler discusses memory management in Java, how it can go wrong, and how NetBeans can help you fix it. "This article will cover [a] scenario when there are many small objects that are continuously accumulating without being released. This type of leak can be more difficult to detect because typically it's not related to any concrete action and doesn't use a noticeable amount of memory until the program has run for a long time. This scenario is dangerous especially with Java EE applications that are expected to run for long periods of time. After some time the leak starts to consume memory and may slow down performance of the application or cause an OutOfMemoryError crash without any visible cause."

Google blogger Steve Yegge is getting a lot of notice with a new blog that tries to predict the traits of The Next Big Language. "People are still always trying to make new languages, because we have yet to see a language that is (a) popular and (b) doesn't suck. Do you disagree? If so, I don't mind. It just means your standards aren't as high as mine. Nothing wrong with that."