[MUD-Dev] TECH: Servers in Java

[Daniel.Harman at barclayscapital.com]

> -----Original Message-----
> From: Brian Hook [mailto:brianhook at pyrogon.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?).

Well I wrote a bridging system between two banking messaging APIs in
Java 1.3 and had a fair amount of trouble not blowing up the GC due
to the number of tempories being created. After a lot of
optimisation it seemed stable, but I was never completely happy
about it. As an STL kinda guy, I was pretty horrified to have to
take out iterators to save on tempories, and remove almost all
logging as well.

It only ran into problems when running flat out (a few thousand
messages a second or so), and I don't have the expertise to tune the
JVM. So it may not be an issue for others who are more Java
literate.

I also wrote another Java application that just received banking
market data, and was _really_ pleased at the performance. It was
coping with 2000+ updates a second of small price update messages
and updating objects consisting of name/value pairs. Both the speed
of the grid controls, and the update speed of these fairly
inefficient name/value pair objects impressed me. We put a lot of
effort into thinking up effective ways of indexing the objects using
hash tables and it seemed to work out nicely.

So as you can see, my experience with high performance messaging in
Java has been mixed. All the applications mentioned here used
TCP/IP, but I never touched it directly as I had to code to other
peoples APIs. The first problem I had is likely down to one of these
being a little careless with its use of temporaries. Hard for me to
recommend one way or the other in light of my experience I'm afraid
- like most technologies, I expect you can make it work in the end.

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