Hi all Is there any thread control facility in RMI? I've dug the RMI specification but the only thing I've found is: "A method dispatched by the RMI runtime to a remote object implementation may or may not execute in a separate thread. The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. Since remote method invocation on the same remote object may execute concurrently, a remote object implementation needs to make sure its implementation is thread-safe." But this simply means I can't control the thread in RMI. Does that mean the RMI will be broken (the system resource is exhausted) when there are 10,000 or 100,000 clients connect to the Data Server (or it depends on the implementation)? But if I can't control the thread, what the heck does the Data Server do? (It simply acts as an RMI adaptor and do some client track?) Thank you for your suggestion. [ October 08, 2002: Message edited by: Hai Wei ]
It simply means that RMI handles all threads for you, and they only thing you need to know, is that because of this you can't guarantee that a client will always use the same thread. This means for the SCJD, is that you cnnot use ThreadID as your unique client identifier. That is all. You don't need to control these threads anyway, that is one of the major advantages of RMI, is that you don't have to worry about it. Data Server is to server data. Mark
Thanks Mark. But what will happen when there are 10,000 or 100,000 clients connect to a RMI server? If the RMI don't provide some facilities to control the number of threads, the system resource will be exhausted. And to my surprise, I find the Sun's implementation of RMI Activation provide a Implementation-dependent system property sun.rmi.rmid.maxstartgroup which controls "Maximum number of groups currently in the process of being spawned. Group activations are queued while this limit is reached.", but it don't provide a system property to control the number of threads. Any suggestion or advice, thank you for your help. [ October 09, 2002: Message edited by: Hai Wei ]
Hai, Don't worry about the threads. That's the RMI implementor's job. Your job is to write a simple RMI application. You don't need to know whether the RMI subsystem is using a Thread pool or not (likely that it is). Just register your remote object and be done with it. I don't know about Sun's implementation in any given JRE, but it is likely that there is a Thread pool which can use a small number of threads to serve a large number of clients.
posted 16 years ago
Thanks Pete I just wonder why RMI don't provide such system property. Maybe the server built upon RMI protocol and want to has that control at the same time has to rewrite the whole thread pooling code.
If you have 10,000 or 100,000 concurrent users, I don't think you will be using RMI, there is much more robust solutions for larger scale systems. It is always a matter of using what best suits the situation. If you have 10,000 to 100,000 users you are going to have to use a three tier archictecture with maybe and App Server with EJBs and JSP and Servlets handling requests routed through HTTP and a web browser, so that you can robustly serve all your users. You will not use RMI. Now if you have about 100 users then yes RMI is a solution. Mark
10,000 or 100,000 concurrent users?? isn't there a limit on the number of requests that can be sent on a single port? From the discussion, can it be concluded that an RMI server object is equivalent to a singleton object used by multiple threads? - a single shared resource?
posted 16 years ago
EJB (J2EE) is using RMI as a fundamental building block, perhaps it has some magic carpets.