xiaoxiao
asked on
RMI Implementation Problem
Basically, my question is about how the server (remote object) serves the request?
Let's say one server is running all time waiting for requests coming in. When a client invokes one remote method through the remote object reference obtained by Naming lookup, what actually happen on server side? The method is running in the server's VM (correct me if i am wrong)'s memory space? What if many requests come in at the same time, the server spawn new threads for those requests? (Even the server is not implemented explicitly as multi-thread one?) Or RMI provides some queuing mechanism for the requests?
In the RMI specification, one possible place about this (maybe i misunderstand it) is in 3.2 as :
"A method dispatched by the RMI ru ntime 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."
what actually does this mean?
i am puzzled by thinking this problem, wish someone can get me off the hook!
Let's say one server is running all time waiting for requests coming in. When a client invokes one remote method through the remote object reference obtained by Naming lookup, what actually happen on server side? The method is running in the server's VM (correct me if i am wrong)'s memory space? What if many requests come in at the same time, the server spawn new threads for those requests? (Even the server is not implemented explicitly as multi-thread one?) Or RMI provides some queuing mechanism for the requests?
In the RMI specification, one possible place about this (maybe i misunderstand it) is in 3.2 as :
"A method dispatched by the RMI ru ntime 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."
what actually does this mean?
i am puzzled by thinking this problem, wish someone can get me off the hook!
You have to provide thread safe synchronization to Your methods and data of the
Remote Server.
The data is not thead safe..
Remote Server.
The data is not thead safe..
Server handles the request with a thread per the request. And concurrency is taken care by server if the method is synchronized otherwise it is the responsibility of the author.......
An implementation is thread safe if not more thatn one thread is there in the critical section(code in which racing conditions can appear).
An implementation is thread safe if not more thatn one thread is there in the critical section(code in which racing conditions can appear).
It happens the same as on your own JVM. If two objects running in different parts of your JVM call the same method in the same object, two threads will be executing the same method code. The method may not finish when one thread is thrown out of the execution (CPU) to allow the other thread to execute. If this section of code is a "critical section" (see ravindra's comment), then you have to make your method synchronized (or make the section of code inside the method synchronized).
Laminamia :)
Laminamia :)
Client Server programming with Java and CORBA -- Read this book if available
RMI - Pass by value mechanism - Method execute at client
Corba - Pass by value mechanism - Method execute at server
RMI is multi thread.
Each method call is thread. SO U have to provide thread safeness to ur Server Class data
and mthods
RMI - Pass by value mechanism - Method execute at client
Corba - Pass by value mechanism - Method execute at server
RMI is multi thread.
Each method call is thread. SO U have to provide thread safeness to ur Server Class data
and mthods
Ravindra:
"What do you mean by RMI Pass by value mechanism - method execute at client"?
Laminamia :)
"What do you mean by RMI Pass by value mechanism - method execute at client"?
Laminamia :)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Laminamia :
If the local object implement serializable interface, then the object can be passed between client and server by the copy or clon of the object. Any methods invoked in those object happens in local machine. This is differrent to CORBA.
Is that correct?
If the local object implement serializable interface, then the object can be passed between client and server by the copy or clon of the object. Any methods invoked in those object happens in local machine. This is differrent to CORBA.
Is that correct?
xiaoxiao == yanchou ?
:)
:)
Amit:
1. (xiaoxiao.getBirthday().eq
2. yanchou.getPoints() < 300
3. yanchou.getLastVisitAccoun
1. (xiaoxiao.getBirthday().eq
2. yanchou.getPoints() < 300
3. yanchou.getLastVisitAccoun
Hi : Laminamia ,
My comment's explanation has given by
yanchou
:)
My comment's explanation has given by
yanchou
:)
sorry yanchou,
was in a tearing hurry so i thought that u and xiaoxiao were the same.
please forgive me, but what is yanchou.getLastVisitAccoun
i understood the first 2 though
was in a tearing hurry so i thought that u and xiaoxiao were the same.
please forgive me, but what is yanchou.getLastVisitAccoun
i understood the first 2 though
mbormann
Never mind, I know you are kidding!
yanchou.getLastVisitAccoun
XioXio! Are you happy with our comment? If yes, We will try to claim the points.
Thanks
Never mind, I know you are kidding!
yanchou.getLastVisitAccoun
XioXio! Are you happy with our comment? If yes, We will try to claim the points.
Thanks
ASKER
Well, it seems i have kept silence for days. Frankly speaking, i am still waiting for more comments on this topic. i will close this question and give out the points by this week? OK?
Just share with all of you about what i understand about this question (of course, got this point of view from various sources), maybe you guys can correct me:
There are three parts in RMI systems -- client, RMI engine, and server. RMI engine has one thread listening the port and dispatches the incoming request to the destination -- this action will cost one connection to the server. RMI engine tries to use the same connection to direct the service request if he can finish sending previous one, but otherwise, a new thread (and connection will be created). This part leads to the multi-threaded problem.
By the way, the RMI-Users page gives lots of discussions on this topic, and some of the comments are from RMI team, they are very very good and useful.
Just share with all of you about what i understand about this question (of course, got this point of view from various sources), maybe you guys can correct me:
There are three parts in RMI systems -- client, RMI engine, and server. RMI engine has one thread listening the port and dispatches the incoming request to the destination -- this action will cost one connection to the server. RMI engine tries to use the same connection to direct the service request if he can finish sending previous one, but otherwise, a new thread (and connection will be created). This part leads to the multi-threaded problem.
By the way, the RMI-Users page gives lots of discussions on this topic, and some of the comments are from RMI team, they are very very good and useful.
Connection is identified by client (IP, port) and server (IP, port) pair.
In the client side, There is a sigleton class (or client side RMI engine)maintain the connection to the server. The connection in client side might be reused by different thread. This connection will keep alive for a period of time.
The server RMI engine will keep as many connections as clients claim. Thread will be spawn per connection.
In the client side, There is a sigleton class (or client side RMI engine)maintain the connection to the server. The connection in client side might be reused by different thread. This connection will keep alive for a period of time.
The server RMI engine will keep as many connections as clients claim. Thread will be spawn per connection.
ASKER
Opps? A bit of confused!
Does client need to know server's address? Well, from my understanding, client talks to RMI engine, RMI engine directs request to server. i don't think (well, again, correct me if i am wrong), client talks to server directly.
How do they communicate? Anyone can confirm this?
Does client need to know server's address? Well, from my understanding, client talks to RMI engine, RMI engine directs request to server. i don't think (well, again, correct me if i am wrong), client talks to server directly.
How do they communicate? Anyone can confirm this?
The client does not need to know the address of the RMI Server, however, it need to know the address of broker (or rmiregistry). It is the borker tell the client where RMI engine and the services are. After locating the RMI engine, the client will talk to it directly.
ASKER
Comment accepted as answer
ASKER
It's been one month since i posted this question. Thanks for the answers provided! It's time to end this question.
Well, since this question is not so specific -- it can be answered with a few words, and it can also be analysed with one whole article. I would say this answer seems rather good.
Well, for those who still has doubts on this problem, maybe you can check one message in the RMI users mailing list: Reference #201 for September 1998, answered by one of the member in RMI team. It is really good!
Thanks!
Well, since this question is not so specific -- it can be answered with a few words, and it can also be analysed with one whole article. I would say this answer seems rather good.
Well, for those who still has doubts on this problem, maybe you can check one message in the RMI users mailing list: Reference #201 for September 1998, answered by one of the member in RMI team. It is really good!
Thanks!
An implementation is thread safe if not more thatn one thread is there in the critical section(code in which racing conditions can appear).