File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Distributed Java and the fly likes Slightly More Advanced RMI Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Distributed Java
Bookmark "Slightly More Advanced RMI" Watch "Slightly More Advanced RMI" New topic
Author

Slightly More Advanced RMI

Adam Nace
Ranch Hand

Joined: Jul 17, 2006
Posts: 117
I am interested in learning more about RMI. So far, my background is the RMI tutorial that is part of Sun's Java Tutorial. I have also read through most of the RMI Specification.

I wonder if anybody knows of any good reference material for learning more of the advanced topics of RMI?

- Adam
Adam Nace
Ranch Hand

Joined: Jul 17, 2006
Posts: 117
I'm also interested in what anybody can tell me about the Thread Model used in RMI.

The specification indicates that two consecutive calls from the same client may or may not be executed on the same thread on the server. BUT, this doesn't define the behavior of two calls from different clients, or different threads on the same client.

For example, if two different clients make calls to a remote object, and they are both scheduled for the same thread, if the first one through ends up having to wait(), then the second one gets delayed behind it.

Is this a ligitamate concern in RMI, or does this typically not occur? Are there ways to prevent this without expicitly calling new threads for any remote method called on a remote object?

Has anybody ever had difficulty using RMI because the Thread Model is unspecified?

I'm trying to figure out if RMI suits the application I'm working on, and it would be handy to understand how RMI uses threads to allow concurrent remote method calls.

- Adam
Edward Harned
Ranch Hand

Joined: Sep 19, 2005
Posts: 291

You can check out Esmond Pitt's book, "The Remote Method Invocation Guide."

Your assumtion about how rmi threads work is totally erroneous.

When a rmi connection thread finishes work, instead of dying, it wait a while for another request.


Ed's latest article: A Java Parallel Calamity http://coopsoft.com/ar/Calamity2Article.html
Nathan Pruett
Bartender

Joined: Oct 18, 2000
Posts: 4121

RMI basically uses a thread pool. The thread making the RMI call on the client is blocked. A thread in the server's thread pool wakes up and handles the work. When the work is finished the thread goes back into the pool - maybe to get some new work right away, maybe to wait for work for awhile. The thread on the client wakes up and does whatever it needs to with the results of the RMI call. If two clients, or two threads from the same client, call an RMI method - both of those client threads wait for a response. Two threads are pulled out of the thread pool on the server, and execute server code at the same time. As they finish, the server threads go back into the thread pool, and the client threads wake up when they get the results back. As a result of this - it is important that RMI servers are thread safe, as they almost always are multithreaded (unless you just have one client, with one thread calling the server).


-Nate
Write once, run anywhere, because there's nowhere to hide! - /. A.C.
Adam Nace
Ranch Hand

Joined: Jul 17, 2006
Posts: 117
Could anybody tell me what size the thread pool is? Is the size fixed? Does it come from a property file somewhere? Can the pool expand if needed?

Furthermore, is it safe to assume that the server will effectively manage the clients requests, regardless of the number of clients, of should the developer (i.e. myself) do some tweaking to make it perform well. What form might that tweaking take?

- Adam
Nathan Pruett
Bartender

Joined: Oct 18, 2000
Posts: 4121

Actually, I looked further into it - and - I was wrong (darn it!). Sun's implementation of RMI doesn't use a thread pool at all - it creates a new thread for each 'client connection' - but will re-use threads (per each client) when the opportunity presents itself. A 'client connection' isn't the same as each client call - more like a 'session', but if multiple client threads make concurrent calls, more threads per client are used. Some other implementations of RMI - such as Weblogic's that ships with their application server - do use thread pools.

Since the RMI specification basically says "never assume server requests are handled in the same thread" - this is basically all you - as an RMI application programmer - need to be concerned with. Program to the RMI spec, not a specific implementation. Once you deploy your app into a specific implementation - there are probably implementation specific settings you can tweak if you need to.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Slightly More Advanced RMI