asynchronous disk access ?

[Vincent Cantin]

Hello,

Somebody told me that Java is not suitable for an online game server because
it have nothing to access the hardisk in an asynchonous way (something like
the NIO but applied to the filesystem) and when the server have thousands of
connections it might become a problem.

I would like to know what you think about this .. is it true what that
person told me ?

I guess there is a jini way to fix the problem if there is a way to do that
in C, what do you think about this ?

Thank you,
vincent

 

[Vincent Cantin]

Hello,

Somebody told me that Java is not suitable for an online game server
because it have nothing to access the hardisk in an asynchonous way
(something like the NIO but applied to the filesystem) and when the server
have thousands of connections it might become a problem.

I would like to know what you think about this .. is it true what that
person told me ?

I guess there is a jini way to fix the problem if there is a way to do
that

Typo.. I mean JNI, not jini.

 

[Kevin McMurtrie]

Hello,

Somebody told me that Java is not suitable for an online game server because
it have nothing to access the hardisk in an asynchonous way (something like
the NIO but applied to the filesystem) and when the server have thousands of
connections it might become a problem.

I would like to know what you think about this .. is it true what that
person told me ?

I guess there is a jini way to fix the problem if there is a way to do that
in C, what do you think about this ?

Thank you,
vincent

Java does support non-blocking I/O. I'm not sure why you'd need it for
disk I/O, though. Use it for the network layer so you don't temporarily
loose a thread if a client is unresponsive.

Java is capable of managing thousands of threads. The JVM can map Java
threads to a pool of native threads on systems needing that. I don't
see a problem with well written Java running at full network bandwidth
unless you need serious bitwise number crunching.

 

[Vincent Cantin]

Java does support non-blocking I/O.

Yes, that's what I actually do.

I'm not sure why you'd need it for disk I/O, though.

The person I was speaking to was supposing that of lot of change of the game
data (for example, inventory changes in a MMORPG) will require an update of
some data on the filesystem. He was considering the blocking access to the
filesystem as a bottleneck as important as a synchronous network access
could be.

Use it for the network layer so you don't temporarily
loose a thread if a client is unresponsive.

Yes, that's what I actually do.

Java is capable of managing thousands of threads. The JVM can map Java
threads to a pool of native threads on systems needing that. I don't

In the documentation I read about threads, the author were not assuming
anything
about that since it is implementation dependant. Do you know where I can
find such information concerning the JVM provided by Sun ? Is there some API
or some JVM parameters that enable the programmer to change those setting ?

see a problem with well written Java running at full network bandwidth
unless you need serious bitwise number crunching.

me neither ... I am the author of Jnag, a network library for games (still
in early development), and I would like to be sure that I take all the
parameters around my project into account ... for example if there is a need
for me to implement the thread pool in Java or not ... if the JVM provided
by Sun can really handle thousands of threads, then it might be better to
simply not implement in Java my own thread pool.

My final objective is to use jnag for a MMO game.
Any suggestion or information is really welcome.

Thank you,
Vincent

 

[Daniel Dyer]

The person I was speaking to was supposing that of lot of change of the
game
data (for example, inventory changes in a MMORPG) will require an update
of
some data on the filesystem. He was considering the blocking access to
the
filesystem as a bottleneck as important as a synchronous network access
could be.

You are probably going to have to use some kind of database for storing
this data, so assuming you choose a standalone relational database server,
such as MySQL or PostgreSQL, it will be the DB server that will be doing
the file system I/O, not Java.

In the documentation I read about threads, the author were not assuming
anything
about that since it is implementation dependant. Do you know where I can
find such information concerning the JVM provided by Sun ? Is there some
API
or some JVM parameters that enable the programmer to change those
setting ?
....

... for example if there is a need
for me to implement the thread pool in Java or not ... if the JVM
provided
by Sun can really handle thousands of threads, then it might be better to
simply not implement in Java my own thread pool.

The BEA JRockit VM is the best for having huge numbers of threads since it
can map multiple Java threads onto a single native thread with its "thin
threads" implementation. This means it can achieve much better
scalability than Sun's VMs, which on Windows are limited to about 4,000
threads and on Linux are limited by a kernel parameter, which by default
is usually around 2,000 if I remember correctly.

A thread-pool such as the one in the java.util.concurrent package in Java
1.5 is preferable to having that many native threads. Aside from the
performance implications of creating and switching between that many
threads, huge numbers of threads require a huge amount of memory since
each thread has it's own stack. The default thread stack size is 256kb,
which means that 4,000 threads would require 1Gb of memory just for the
stacks, without considering all the other objects you will be using and
the JVM overhead). You can reduce this stack size but the smaller you
make it the more likely you are to run into StackOverflowErrors
(particularly if you are using recursion).

Dan.

 

[iksrazal]

Take a look at Coconut AIO.

http://coconut.codehaus.org/Coconut+AIO

There may also be JSR 203 someday - it was in 1.5 but got pulled out.

HTH,
iksrazal
http://www.braziloutsource.com/

 

[Kevin McMurtrie]

Yes, that's what I actually do.


The person I was speaking to was supposing that of lot of change of the game
data (for example, inventory changes in a MMORPG) will require an update of
some data on the filesystem. He was considering the blocking access to the
filesystem as a bottleneck as important as a synchronous network access
could be.


Yes, that's what I actually do.


In the documentation I read about threads, the author were not assuming
anything
about that since it is implementation dependant. Do you know where I can
find such information concerning the JVM provided by Sun ? Is there some API
or some JVM parameters that enable the programmer to change those setting ?

You're right, it does seem to be implementation dependent.
http://java.sun.com/docs/hotspot/threads/threads.html

 

[Manuel J. Goyenechea]

I did some testing of Java's NIO libraries some time ago on Windows XP and
as far as my testing went any benefits that where gained by doing
asynchronous IO where lost to the overhead of doing it from Java.

 

[Vincent Cantin]

I did some testing of Java's NIO libraries some time ago on Windows XP and
as far as my testing went any benefits that where gained by doing
asynchronous IO where lost to the overhead of doing it from Java.

Thank you for your participation, but you are totally off-topic.