[MUD-Dev] RE: TECH: Servers in Java

[justice at softhome.net]

From: Brian Hook <brianhook at pyrogon.com>

> 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).

jdk1.4 is coming out with a java.nbio package to handle this, but
there is a third party package you can use for it as well.

  http://www.cs.berkeley.edu/~mdw/proj/java-nbio/

What I've done fairly successfully was to write my own handler which
checks if there are any characters to read from the stream and
limiting itself to reading only that many characters.  The problem
with this method is java doesn't provide a mechanism to check
disconnects.  Generally you catch an IOException or
NullPointerException from the read.  By hacking the non-blocking
I've had to catch it on ouput, if you can assure output.

> 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?).

Java's GC isn't really that bad, but you have to take it into
consideration.  Using alot of throw-away temp objects will cause
object churn and lower performance, and you have to make sure that
you dereference objects completely so they are available for GC.
What you could do is make all "temp" references using reference
objects which don't prevent the GC from claiming them.

The reference objects are located in java.lang.ref

Performance information can be found at:

  http://www.javaolympus.com/java/PerformanceDirectory.html

> If anyone has first hand experience on this, I'd love to hear
> about it.  I've done some cursory examination of the archives and
> haven't found much.

Hope this helps,

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