Java RMI specification on thread usage: "..may or may not execute in a separate thread"

I might have a problem with my application. There is a client running multiple threads which might execute rather time consuming calls to the server over Java RMI. Of course a time consuming call from one client should not block everyone else.

I tested it, and it works on my machine. So I created two Threads on the client and a dummy call on the server. On startup the clients both call the dummy method which just does a huge number of sysout. It can be seen that these calls are handled in parallel, without blocking.

I was very satisfied until a collegue indicated that the RMI spec does not necessarily guarantee that behavior.

And really a text on the hp of the university of Lancaster states that

“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” [1]

What can 开发者_运维知识库I do about that? Is it possible that it just won't work in practice?

in theory, yes, you may have to worry about this. in reality, all mainstream rmi impls multi-thread all incoming calls, so unless you are running against some obscure jvm, you don't have anything to worry about.

What that wording means is that you can't assume it will all execute in the same thread. So you are responsible for any required synchronization.

Based on my testing on a Mac laptop, every single client request received in parallel seems to be executed on a separate thread (I tried upto a thousand threads without any issues. I don't know if there is an upper bound though. My guess is that the max no. of threads will be limited only by memory).

These threads then hang around for some time (a minute or two), in case they can service more clients. If they are unused for some time, they get GC'ed.

Note that I used Thread.sleep() on the server to hold up every request, hence none of the threads could finish the task and move on to another request.

The point is that, if required, the JVM can even allocate a separate thread for each client request. If work is done and threads are free, it could reuse existing threads without creating new ones.

I don't see a situation where any client request would be stuck waiting due to RMI constraints. No matter how many threads on the server are "busy" processing existing requests, new client requests will be received.