 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / June 2005RMI Concurrent Requests Handled by Different Threads?
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 > Hi: > [quoted text clipped - 12 lines] > 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. 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 > > Hi: > > [quoted text clipped - 29 lines] > java.util.concurrent, not the java.rmi.runtime stuff which doesn't even > seem complete. > 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. 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: > [quoted text clipped - 4 lines] > 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. 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 > > Esmond: > > [quoted text clipped - 12 lines] > implementors of remote objects aware that they must take multithreading > into account and cannot assume a single-thread model. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.