This content has been marked as final. Show 8 replies
There is a rmi server and an rmi client.
If the rmi server stops then what use is the rmi client? It can't start the server again (at least it can't normally.)
If it isn't a client then it has nothing to do with RMI. In that case you do one of the following.
1. The app (rmi server or anything else) has a socket. You send a message to the socket that says shut down. Obviously you can't start it this way.
2. You use another application (like telnet) to start and stop the server.
I have a similar question...
I am using an observer pattern approach to my RMI client. The client calls a remote method on the server and one of the parameters send is a remote "callback" object.
when the client makes the call, which returns immediately, it kicks off processing in the server to gather some information. As it gets information it sends it back to the client using the "callback" object and when the job is complete the server calls the "callback" object to tell it that the job is done.
ok, so because the client's "callback" object is used by the server, it is in effect a server itself. now, I want to close out the "callback" object without exiting the program. I have tried unexport but it doesn't seem to do anything. I did have code to catch a "NoSuchObjectException" but that didnt seem to occur.
Any suggestions would be appreciated!
ok, so because the client's "callback" object isWhy do you think that?
used by the server, it is in effect a server itself.
Well I think a callback object is a server too, but this is a crosspost that's already been answered in the Networking forum.
Didn't show up in the RMI forum for some reason ...
Well I think a callback object is a server too, butPresumably this one....
this is a crosspost that's already been answered in
the Networking forum.
Are you suggesting that a call back creates a separate server connection thread? That would be the 'server'?
An RMI callback is a remote object is a server.
An RMI callback is a remote object is a server.Ok, but what is the context in which it would be necessary to explicitly close it?
DGC does a pretty good job if you let it. I suppose if the client logged out from the server and wanted to be sure for security reasons that the server wasn't going to bother it any more, it should unexport its callbacks. There all sorts of state-orientation scenarios you could come up with.