This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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?
Joined: Jul 17, 2006
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.
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).
Write once, run anywhere, because there's nowhere to hide! - /. A.C.
Joined: Jul 17, 2006
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?
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.