RMI with high load

[Raymond DeCampo]

Hello,

I am in the early stages of fleshing out an interface between two
existing products. One possible solution involves RMI. However, part
of the team has some concerns with RMI, specifically when under a high load.

First, there seems to be a concern that if every client is connected to
the same RMI server, that the clients will be processed in sequence. I
would expect them to be processed in parallel up to a point. E.g.,
using a thread pool or some such device. In other words, I would expect
that an RMI server would act much like a web server and that this
behavior would be essentially free, i.e., provided by the RMI subsystem.

Second, a proposed solution to this issue is to create an RMI server for
each client. This seems like a radical and wasteful solution to me.

I would appreciate if someone could guide me to some good sources on the
above issues, or provide some "war stories" of your own experiences. I
have no professional experience with RMI (if you discount EJBs), only
academic experience.

Thanks,
Ray

 

[Thomas Weidenfeller]

I am in the early stages of fleshing out an interface between two
existing products. One possible solution involves RMI. However, part
of the team has some concerns with RMI, specifically when under a high
load.

Measure it. Build a simple prototype which generates load. Measure the
responses in your environment.

First, there seems to be a concern that if every client is connected to
the same RMI server, that the clients will be processed in sequence. I
would expect them to be processed in parallel up to a point.

Don't expect anything. Read the documentation of the software you want
to use, and run your own tests. Get facts. Discussions about what might
happen are good for wasting a few minutes at the water cooler, but don't
allow you to make an informed decision.

I would appreciate if someone could guide me to some good sources on the
above issues, or provide some "war stories" of your own experiences.

I haven't done much RMI, but CORBA. There are typical problems when you
start to use distributed objects. You might want to check:

Douglas Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann:
"Pattern-Oriented Software Architecture, Volume 2, Patterns for
Concurrent and Networked Objects".

Also check out Doug Schmidt's home page. He has written some 200 or so
publications about distributed objects.

/Thomas

 

[Raymond DeCampo]

Measure it. Build a simple prototype which generates load. Measure the
responses in your environment.

See below.

Don't expect anything. Read the documentation of the software you want
to use, and run your own tests. Get facts. Discussions about what might
happen are good for wasting a few minutes at the water cooler, but don't
allow you to make an informed decision.

We haven't identified which software we will use. Even if we did at
this point, it will likely change. I do not want to base the
fundamental design of the interface on the behavior of one RMI
implementation.

I would prefer to know and understand what is guaranteed by the RMI
subsystem. Then I can design my system based on these guarantees. Then
I can choose an RMI provider based on their adherence to these
specifications and the target platform.

Thanks,
Ray

 

[Thomas Weidenfeller]

I would prefer to know and understand what is guaranteed by the RMI
subsystem.

Then you have to do the most obvious thing: Read the specs. Available at

http://java.sun.com/j2se/1.4.2/docs/guide/rmi/

Good luck,

/Thomas

 

[Esmond Pitt]

Raymond

This is nothing but FUD. A single-threaded RMI implementation would be
completely useless. I have never encountered one in seven years. Sun's
is multi-threaded with a new thread per new connection, IBM's is
multi-threaded with a thread pool. The specification says that no
assumptions can be made about particular client requests being
despatched in particular server threads. This trivially means that you
can't assume there is only one thread! and in fact you have to allow for
possible remote calls executing in parallel when writing your server,
i.e. take care of any synchronization required yourself.

Esmond Pitt
author 'java.rmi' http://www.rmiproxy.com/javarmi