My question is when you implement a RMI server, how could the server guarantee the response can be sent back to client? If the network is broken after the call has been sent out by client , the client will get an exception. However the server remote method implementation code dose not know that the network is broken. So it will continue to execute and return. Then the execution point would be somewhere in the skeleton code. The server try to send back response and find the network is broken. So it seems that when we develop the RMI program , we have no chance to handle the network exception. RMI just want to make the network transparent. But sometimes the server has to do something when the network is broken. Yes , the server can try to wait for an acknowledgement from the client. However it is not the mechanism of RMI. It seems that for the server , the RMI sounds like IP. But there is no "TCP for RMI" available. You have to develop your own. Am I right? If the RMI server cannot handle everything correctly, who would like to use it. It seems that there are something I do not know. Could you please give me a hint? Thanks
Your question seens somewhat messy. When you invoke method on remote object you either get response or some exception if smth is wrong. Why should you care about low level TCP ? You would get java.rmi.ConnectException if network is down. If your app is made correctly it should be able to handle this. I've written quite a bit of RMI servers and this never is a problem.
Joined: Dec 11, 2002
Raimondas, Thank you for your reply. It seems that I did not explain my questions clearly. What I care is the server side other than the client side. For the client side you can catch an exception when there is network problem. However for the server side, your code will not be in the running stack at that time, how could you catch an exception?