RMI Server
Mark Smyth
Ranch Hand
Posts: 288
posted 13 years ago
While I was originally going to use sockets to implement my Server but I am considering moving to RMI as I think it will make the code alot simpler and quicker. My question concerns threads and RMI.
For a sockets application you just wait in an infinate loop for a connection then spin off a new thread to communicate with the client and perform the Task depending on the OPCode recieved.
I have never used RMI before I know you obtain a reference to the the remote object and call methods on it. I am unclear on the threading implications of this. Does a new thread start automatically, when you call a remote method or does each method need to be able to start a new thread to communicate with the database? I doesnt seem as clear to me as the sockets approach,
Thx in advance.
For a sockets application you just wait in an infinate loop for a connection then spin off a new thread to communicate with the client and perform the Task depending on the OPCode recieved.
I have never used RMI before I know you obtain a reference to the the remote object and call methods on it. I am unclear on the threading implications of this. Does a new thread start automatically, when you call a remote method or does each method need to be able to start a new thread to communicate with the database? I doesnt seem as clear to me as the sockets approach,
Thx in advance.
SCJP<br />SCJD
George Marinkovich
Ranch Hand
Posts: 619
posted 13 years ago
Hi Mark,
One of the advantages of RMI over sockets is that the threading issues in RMI are largely transparent to the developer. There is no need to explicitly start new threads when you are using RMI. I believe it is as simple as you stated: "you obtain a reference to the remote object and call methods on it." Of course, because the methods of your remote object can now be called by multiple threads, you have to be concerned with synchronization and locking issues but you do not have to worry about managing the threads themselves.
I hesitate to say anymore about threading in RMI as I'm far from being an expert. Maybe someone else more knowledgeable will add further comments (or subtract anything I may have stated incorrectly).
Hope this helps,
George
[ February 09, 2004: Message edited by: George Marinkovich ]
Originally posted by Mark Smyth:
I have never used RMI before I know you obtain a reference to the the remote object and call methods on it. I am unclear on the threading implications of this. Does a new thread start automatically, when you call a remote method or does each method need to be able to start a new thread to communicate with the database? I doesnt seem as clear to me as the sockets approach,
One of the advantages of RMI over sockets is that the threading issues in RMI are largely transparent to the developer. There is no need to explicitly start new threads when you are using RMI. I believe it is as simple as you stated: "you obtain a reference to the remote object and call methods on it." Of course, because the methods of your remote object can now be called by multiple threads, you have to be concerned with synchronization and locking issues but you do not have to worry about managing the threads themselves.
I hesitate to say anymore about threading in RMI as I'm far from being an expert. Maybe someone else more knowledgeable will add further comments (or subtract anything I may have stated incorrectly).
Hope this helps,
George
[ February 09, 2004: Message edited by: George Marinkovich ]
Regards, George
SCJP, SCJD, SCWCD, SCBCD
posted 13 years ago
Hi Mark & George,
George is quite correct - the RMI Server will generally create new threads for you, and since these threads will be running on a single instance of your code by default, you have to concern yourself with thread safety.
One thing to be aware of is that you have no way of knowing which thread will be used when you call your methods. This is explicitly stated in the RMI specifications. It is completely up to the RMI Server to decide what threads it is going to create and how it is going to use them. To give you one example of what is possible (there are many other possibilities as well):
Client A calls method1 and completes (it happens to use thread 1) Client A calls method1 and completes (it happens to use thread 1) Client A calls method1 and completes (it happens to use thread 2) Client B calls method1 and completes (it happens to use thread 1) Client A calls method1 (it happens to use thread 1) Client B calls method1 (it happens to use thread 2)
As you can see in my example: client A used different threads even for subsequent calls to the same method.
And client B could use a thread that had previously been used by client A.
And (in the last two lines) client A and B were both calling the same method simultaneously - just using different threads.
The code may be simpler - but if you write your socket layer correctly then it is not that much simpler. And your junior programmer has to learn about RMI - so either way there would be a learning curve for the person taking over your code.
RMI is slower than the equivelent well written Sockets based solution - the difference is negligble, but there is always overhead when you abstract a communications layer. I did once do some testing, and measured the size of messages going via RMI versus the equivalent Sockets code, however I don't remember where I posted the results - if anyone remembers that post, perhaps they could point us to it (Phil?). From memory there were a lot of RMI messages just at startup that were not necessary for Sockets, and each individual RMI message was about 10% larger than the equivalent Socket message.
Regards, Andrew
George is quite correct - the RMI Server will generally create new threads for you, and since these threads will be running on a single instance of your code by default, you have to concern yourself with thread safety.
One thing to be aware of is that you have no way of knowing which thread will be used when you call your methods. This is explicitly stated in the RMI specifications. It is completely up to the RMI Server to decide what threads it is going to create and how it is going to use them. To give you one example of what is possible (there are many other possibilities as well):
As you can see in my example: client A used different threads even for subsequent calls to the same method.
And client B could use a thread that had previously been used by client A.
And (in the last two lines) client A and B were both calling the same method simultaneously - just using different threads.
I am considering moving to RMI as I think it will make the code alot simpler and quicker.
The code may be simpler - but if you write your socket layer correctly then it is not that much simpler. And your junior programmer has to learn about RMI - so either way there would be a learning curve for the person taking over your code.
RMI is slower than the equivelent well written Sockets based solution - the difference is negligble, but there is always overhead when you abstract a communications layer. I did once do some testing, and measured the size of messages going via RMI versus the equivalent Sockets code, however I don't remember where I posted the results - if anyone remembers that post, perhaps they could point us to it (Phil?). From memory there were a lot of RMI messages just at startup that were not necessary for Sockets, and each individual RMI message was about 10% larger than the equivalent Socket message.
Regards, Andrew
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Javini Javono
Ranch Hand
Posts: 286
posted 13 years ago
Hi,
Here is a toy server.
http://www.coderanch.com/t/185000/java-developer-SCJD/certification/RMI
It is one of two implementation ideas:
1. The clients all use the same remote object, call it Data. Thus,
one instance of Data is multi-threaded.
2. The clients each get their own reference to a new, unique
server-side Data; in this case, each Data is single-threaded,
and probably easier to design and code.
Thanks,
Javini Javono
Here is a toy server.
http://www.coderanch.com/t/185000/java-developer-SCJD/certification/RMI
It is one of two implementation ideas:
1. The clients all use the same remote object, call it Data. Thus,
one instance of Data is multi-threaded.
2. The clients each get their own reference to a new, unique
server-side Data; in this case, each Data is single-threaded,
and probably easier to design and code.
Thanks,
Javini Javono
