HTML5 Canvas
Written by: Simon Sarris
Featured Refcardz: Top Refcardz:
  1. Apache Hadoop
  2. Web Driver
  3. MVVM
  4. REST
  5. ADO.NET
  1. HTML5
  2. Ajax
  3. jQuery Selectors
  4. CSS Part 1
  5. Git

Link Details

Link 77029 thumbnail
User 111696 avatar

By bloid
via technfun.wordpress.com
Published: Apr 22 2008 / 13:52

Starting from version 1.4 Java has a new library called NIO. Everyone who writes scalable network software uses this library because it supports non-blocking network operations. Without this library, you will have a separate Thread for each connection, and Java doesn’t scale well with threads. Of course, this library is not just about non-blocking network operations. It also accelerates access to files, and has whole architecture for byte-to-char conversion and back.
  • 4
  • 5
  • 2265
  • 0

Comments

Add your comment
User 161039 avatar

mheath replied ago:

1 votes Vote down Vote up Reply

This article sounds like something written by someone who has never built and maintained a real NIO application before. NIO is tricky. Read/write buffer management can be tricky to achieve good performance. Dealing with packet fragmentation is difficult. Write buffer overruns have to be dealt with effectively. This post is suggesting that we reinvent the wheel for every new network application that needs to built. This is asinine.

These frameworks make the code manageable. Make the code harder to understand? Are you serious? These frameworks provide separation of concerns which makes the code MUCH more readable and easier to test. Just because the author don't understand the benefits of these frameworks doesn't make them bad.

In one breath the author says these framework are "too generic" and in the next he claims that you have to change your problem to fit with these frameworks. What?!! If you're going to use event-driven networking you have to think about the problem very differently than with blocking I/O. This isn't a framework problem. This article demonstrates a fundamental lack of understanding of what NIO provides and how it can be leveraged to build highly scalable applications.

Better final advice would be, use NIO if you need to scale to thousands of concurrent connections or have a situation where asynchronism is important. But don't use NIO directly. Take advantage of the knowledge others use one of these frameworks. If you don't need such a high level of scalability or asynchronism, using blocking I/O is fine.

As a side note, we're using MINA for an application. MINA is faster than the plain NIO version of the app we started with because of its dynamic buffer management. Our tests show that using MINA's APR transport is about 10% faster than NIO and scales *much* better than the blocking I/O version of the application we're replacing. Did I mention that we can switch between NIO and APR changing only a single line of code? Oh wait. This is bad because MINA is "too generic." This article is a load of BS.

MINA has made our life much simpler and has given us far more performance and flexibility than would be possible using NIO directly.

Add your comment


Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.

Voters For This Link (4)



Voters Against This Link (5)