[MUD-Dev] TECH: Servers in Java

[Emil Eifrem]

At 01:44 AM 12/30/01 , Brian Hook wrote:

> The first thing I've noticed is that Java's UDP implementation
> doesn't seem to have a non-blocking mode receive().  The apparent
> recommended strategy is to park your receive() on a separate
> thread.  I assume I'll be multiplexing incoming data based on the
> client's IP/port combo, as opposed to some proposals of forking
> off a new thread per client (which would obviously not be tenable
> with, say, 2000 clients).

Ah yes, good ole Java IO. You have one master thread that accepts
incoming connections and quickly delegates them to a bunch of client
threads that perform the actual work. Fundamentally you use N+1
threads if you serve N concurrent clients. (In some cases you even
end up using _two_ client threads per connection -- one for reading
and one for writing -- resulting in 2N+1 total threads.) This works
fine on the low end, but in enterprise servers you usually end up
multiplexing connections and threads in order to minimize the
overhead of thread contexts. But regardless of multiplexing,
thread-pooling, event-driven priority queues and other tricks, the
one-thread-per-connection paradigm just isn't a good way to use our
scarce server-side resources.

However, there's a light at the end of the tunnel. The above
approach actually _IS_ good "ole" Java IO. There's also good "new"
Java IO. The java.nio package (nio == new or non-blocking IO)
contains an object-oriented version of select(), amongst other
things, and has been designed with enterprise scalability in
mind. However, it's only available in "Merlin," version 1.4 of the
JDK. Merlin is currently in beta. If you're not aiming to get your
server out RSN and don't have a problem with waiting for Merlin to
stabilize on your platform, I'd suggest you look into java.nio. A
good starting point may be this JavaWorld article

	http://www.javaworld.com/javaworld/jw-09-2001/jw-0907-merlin.html

as well as the API documentations at java.sun.com.

> Other issues include the robustness of the various JVM
> implementations and the usability/predictability of Java GC
> implementations (that's a real big unknown for me -- is Java's GC
> going to be bad enough that it will affect a server's
> reliability?).

IMHO and in general:

  Worry not, enterprise Java is beginning to approach a quite mature
  state.  Companies such as BEA, Oracle, HP, Sun and IBM have been
  wrestling with these issues for a few years now and good things
  have come out of it. The aforementioned companies (no lightweights
  in the industry!) and thousands of others bet their server-side
  market share on Java's scalability. Java, correctly used, can
  handle any scalability demands that today's and tomorrow's
  commercial or non-commercial muds may have.

FMHE (From My Humble Experience) and in practice:

Sun's latest incarnations of the Hotspot JVM are rock solid on
Solaris and Windows. Linux may be there as well, but as we're in the
progress of migrating our application servers from Windows to Linux
I don't yet have any practical experience of Hotspot under Linux in
a production environment. (I use it as a development environment
every day and have no problems whatsoever... but dev env !=
production environment.)

IBM's JVM is very efficient and I have only good experiences with it.
However, since we run our production systems on Hotspot and only a few
smaller services on IBM's JVM, I again don't have enough real high-end
production experience to make an educated statement.

Garbage collection, although still out of reach for the programmer
(System.gc() just suggests GC to the runtime), is nowadays highly tweakable
by the system administrator. If you're masochistic, check out the docs at:

	http://java.sun.com/docs/hotspot/

For garbage collection, I've found this one

	http://java.sun.com/docs/hotspot/gc/index.html

to be particularly useful. The bottom end is that you can tweak today's
Java runtimes from here to the moon as far as server-side scaling is
concerned, although there's still much room for improvement.

Try to avoid full garbage collection when your heap grows big (> 500 megs
with 1-2 Ghz CPUs) until your production JVM supports parallell GC (none
does today) or you'll lock up one of your CPUs with GC for a substantial
amount of time. Avoiding full GC usually boils down to using incremental GC
and sizing/tuning your heap generations cleverly, which is a complex and
tedious task -- but not harder than tuning any other enterprise platform or
application.

Garbage collection issues (like most other things) become increasingly
complex when you go distributed, btw. Just communicating via RMI, for
example, forces a full GC every minute on both client and server side with
most JVM's default parameters. But this is also tunable, of course.

In conclusion, yea, don't worry about Java's validity on the server side.
It's the industry standard for writing enterprise servers. It may not be
everyone's favorite language, but all new enterprise applications are
written in Java and tons of legacy systems are being ported or at the very
minimum provide Java adapters. All the big boys (save Microsoft) are
investing big money in making Java be a scalable, reliable, etc etc
server-side development platform. So I think us mud server coders are
fairly safe for now.

The really interesting question is whether Java in three years time will be
a better choice than Microsoft's .NET. But that's a completely different
discussion (and one I believe is off topic for this list).

- - -
Emil Eifrem   [ emil at eifrem.com || www.eifrem.com || www.javamud.org ]

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev