Server-side threads in Java RMI

[Ehsan Rahman]

Howdy All,

I came across this website:

... this policy is described as follows in the RMI specification:

“A method dispatched by the RMI runtime to a remote object implementation (a server) may or may not execute in a separate thread. Calls originating from different clients Virtual Machines will execute in different threads. From the same client machine it is not guaranteed that each method will run in a separate thread”

Therefore, if you make remote calls from separate clients (executing in different JVMs) each call will run in a separate thread. However, if you make concurrent calls from the same client (this can be acheived by using client-side threading, see later) then it is possible these calls will execute on the same server thread.

http://www.comp.lancs.ac.uk/~weerasin/csc253/tutorials/week7.html

I ran a few tests and the statement seems to hold true that making remote calls from separate clients (JVM instances) does seem to run on different threads on the RMI runtime.

However, I cannot seem to find any sources of the RMI Specification that is mentioned above. The closest I've found is this:

3.2 Thread Usage in Remote Method Invocations

A method dispatched by the RMI runtime to a remote object implementation may or may not execute in a separate thread. The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. Since remote method invocation on the same remote object may execute concurrently, a remote object implementation needs to make sure its implementation is thread-safe.

http://java.sun.com/javase/6/docs/platform/rmi/spec/rmi-arch3.html

The above statement implies that the RMI runtime makes no guarantees to mapping remote object invocations regardless if it is from 2 different JVM clients or from 2 threads from the same JVM client.

Please could someone clarify if the former source can be trusted? I've created an application whereby the RMI implementation is thread safe assuming that the clients only run in a single thread. Otherwise, I'll have to pass tokens from the clients, which is no issue - I'm just curious on how RMI works.

Many thanks,
Ehsan

[Edward Harned]

It works the way it says it works: A new or reused thread may service each request from a client.

The RMI Runtime runs under the JVM which runs under a native operating system. When manufacturers (Sun, IBM, etc.) create the JVM they follow the specification in general. However, they are free to implement the threading structure according to their native O/S.

So, what does this mean for you? All code must be thread safe, always. That's simple, yes?

[Ehsan Rahman]

Edward Harned wrote:
The RMI Runtime runs under the JVM which runs under a native operating system. When manufacturers (Sun, IBM, etc.) create the JVM they follow the specification in general. However, they are free to implement the threading structure according to their native O/S.

Thanks, does this still mean that the following statement is true on all native OSs: "Calls originating from different clients Virtual Machines will execute in different (RMI) threads."

Edward Harned wrote:
So, what does this mean for you? All code must be thread safe, always. That's simple, yes?

For the server side implementation - definitely yes. But as for the clients: if the statement "Calls originating from different clients Virtual Machines will execute in different threads" is true, then I think one can set up an RMI client/server service where the server assumes the client is running on a single thread. E.g. The same citation from Lancaster University being used to answer a question on this particular client/server arrangement: http://stackoverflow.com/questions/1300145/race-condition-in-rmi-java-2-client-1-server