

Grizzly - Java NIO library to build scalable network applications - jwilliams
https://grizzly.dev.java.net/

======
axod
Whilst this is obviously a comprehensive library, Java NIO is very easy to
use. Gone are the days of trying to get networking to work well in Java.

You can write a very simple highly scalable and reliable http server in a few
pages of code (There's a few such examples from sun, including https etc).

Obviously it depends on wether this is a core component of your app, if you
need anything out of the box, or massive scalability or other optimizations
that the library can't do easily.

~~~
davidw
Idle question from someone unfamiliar with NIO:

My understanding is that it's basically a layer on top of
select/poll/events/whatever. Right? select/etc... are a great way of whipping
out static content, but if you have to stop to do some processing, you're
going to lock things, unless you then spawn a thread, process, or something
else to do concurrent work. What does one generally do with NIO?

~~~
axod
Generally you make sure your network code is separate from any blocking
activity.

For example, make a light "network plugin" that deals with your core
functionality, then if it needs to go to DB, or do some potentially blocking
action, have it call a "helper" which has it's own thread.

For instance, Mibbit handles around 7,000 connections at the peak of the day
(3.5k in, 3.5k out). Those are all handled in a single thread. There's an
additional thread that handles dns lookups, one to do database stuff. Each one
of those just has a synchronized queue listing the jobs, each with a callback
to update the network plugin with a reply.

The dns could actually be done asynchronously easily enough, but the gain
wouldn't be worth it right now.

It depends on how lengthly other processing is going to be. Quite often you
can separate the work up into chunks and just do a little each time (Kind of
like your own time slicing). Or split it out into its own dedicated thread and
have a job queue as above.

~~~
davidw
> Quite often you can separate the work up into chunks and just do a little
> each time (Kind of like your own time slicing).

I was going to mention this above, but this is one of the things that makes
Erlang cool - it does that automatically, so that you just write your code,
and it takes care of the scheduling.

