RMI Concurrent Requests Handled by Different Threads?

[Reza]

Hi:

I was wondering if anyone knows the final word on concurrent requests'
thread assignment behaviour for Sun's implementation of the J2SE 1.4+
spec?

In other words, for the Sun implementation, do cuncurrent RMI method
call requests get handled by different thread instances or the same
one?

Does it matter if there is a thread pool or not?

The RMI spec is very vague in this area, so I want to know what the
predominant implementation does. It does not make sense that the same
thread instance will be running concurently, but I just want to make
sure

Also, is RMI thread pooling enabled by deafult in 1.4+?

Thanks in advance.

Reza

 

[Esmond Pitt]

Hi:

I was wondering if anyone knows the final word on concurrent requests'
thread assignment behaviour for Sun's implementation of the J2SE 1.4+
spec?

In other words, for the Sun implementation, do cuncurrent RMI method
call requests get handled by different thread instances or the same
one?

Does it matter if there is a thread pool or not?

The RMI spec is very vague in this area, so I want to know what the
predominant implementation does. It does not make sense that the same
thread instance will be running concurently, but I just want to make
sure

The RMI Spec is worded in such a way that you *cannot* assume that there
is only one thread in the server, or even that two successive RMI calls
from the same client thread are despatched in the same server thread
(although in fact in Sun's implementation the latter is often the case).
So, don't assume *anything* involving single threads. In any case any
single-threaded implementation of RMI would be entirely useless for
practical purposes, and I have never seen or heard of one.

Also, is RMI thread pooling enabled by deafult in 1.4+?

Not in Sun's implementation. There is some thread pool code in
java.rmi.runtime but nothing uses it. Same in 1.5. I have heard that
other implementations do use thread pooling but have no information. If
Sun Java RMI ever does use thread pooling I would hope that it would use
java.util.concurrent, not the java.rmi.runtime stuff which doesn't even
seem complete.

 

[Reza]

Esmond:

Thank you so much for replying. It's easy to lose faith in usenet, but
it's good to see there are people out there not too consumed to help
out...

Just to recapitulate, concurrent requests (not ones in sequence) are
handled by two separate threads, or they are serialized not to become
concurrent and are handled by the same thread, right? I know this is
common sense given Java threading behaviour, but I am trying to help
someone else out myself and would hate to give out bad information.

Thank you again for replying, I appreciate it.

Reza

 

[Esmond Pitt]

Just to recapitulate, concurrent requests (not ones in sequence) are
handled by two separate threads, or they are serialized not to become
concurrent and are handled by the same thread, right?

Nothing in the RMI Specification entitles you to assume that they are
handled by a single thread; I am not aware of any implementation which
does so; and if one appeared it would be laughed out of existence.

 

[Reza]

Esmond:

I am not sure if we are disagreeing...that is exactly what I am saying
as well...if there is any chance of two concurrent RMI method calls
executing (on a given JVM) at the same time (from the same client or
more than one client), then they have to be running under two seprate
threads...I don't even think it is possible to program something
otherwise...

Just for absolute painful clarity, do you agree?

Thanks,
Reza

 

[Esmond Pitt]

Esmond:

I am not sure if we are disagreeing...that is exactly what I am saying
as well...if there is any chance of two concurrent RMI method calls
executing (on a given JVM) at the same time (from the same client or
more than one client), then they have to be running under two seprate
threads...I don't even think it is possible to program something
otherwise...

Yes, that is how all implementations I am aware of operate. It is
possible to implement RMI single-threaded and the spec does not prohibit
it but if it has ever been done commercially I am an unkey's muncle.

The reason for the convoluted wording in the RMI Spec is to make
implementors of remote objects aware that they must take multithreading
into account and cannot assume a single-thread model.

 

[Reza]

Esmond:

Thanks again for taking the time to reply. I thought as much, but
figured I would bounce off the idea with at least one more person.

Best,
Reza