I did a basic test connecting a remote FBN client to the server. I did a couple of searches then terminated the server at which time the client becomes unresponsive. Is there a way for the client to be notified that the server is no longer there and display an unconnected dialog message then, in my case, re-initialize the GUI to reconnect? I'm not quite sure how the client knows when a server is no longer available. - John
Well if the server is shutdown, then any call to the Remote Objects method, will result in an Exception being returned because there is no Server to talk to. So you can catch that exception and display a pretty message. Mark
Well if the server is shutdown, then any call to the Remote Objects method, will result in an Exception being returned because there is no Server to talk to.
I have a question about the server shutdown. For my server GUI, I have a stop button and a Quit menu. All stop button does is to unbind the database and Quit menu exits the whole application. I noticed that if I just stop the data server, the client seems to be still connected to the server somehow, meaning that it can still search and book the flights If the whole application is exited, I will get connection exceptions. Am I doing the right thing in Stop? Or should I do something more than just Naming.unbind(...)? Thank you! Christy
Christy, how are you starting the RMI Registry? Are you using the Connection object solution so that the object the client receives remains on the Server side? If registry is started at command like, look to starting it in your code. If the object the client receives is not a remote object, then the object has been serialized and sent to the client and therefore still exists on the client. Those are my two guesses so far. Mark
Joined: Oct 15, 2001
Hi, Mark, Thank you for the reply. In an attempt to make things clear, I will have number of different items (1) Yes, I am using the Connection object. (2) RMIRegistry is started as part of the server start up code (LocateRegistry.createRegistry). (3) Basically, when the server starts, it starts the RMIRegistry, and binds the ConnectionFactory with the RMIRegistry. The ConnectionFactory has information about the remote database to be associated. (4) In the client GUI, if the user chooses to use the remote database, it does a lookup for the ConnectionFactory, then calls getConnection() to obtain a RemoteDataInterface object. ************************************ A special note here: In my implementation, RemoteDataInterface implements DataInterface and RemoteDataAdapter implements RemoteDataInterface. So, in getConnection() the code is the following:
mDB (type Data) and mLockManager (type DataLockManager) is created in the ConnectionFactory's constructor. Therefore, there is only one Data instance and one DataLockManager. End of special note *********************************************** (5) Once the client gets the RemoteDataInterface, it can perform the operations such as lock(), unlock(), criteriaFind()... (6) Since I have STOP in my server GUI, which is only supposed to stop the current server session, not quitting the whole application, all I am doing in the action handler for STOP is to unbind the ConnectionFactory object.
Question #1: even though I unbind the connectionFactory object, it only prevents any additional clients from connecting the server. For the existing clients, they still have access to the already obtained RemotedataInterface; hence, for the existing client, even though server is stopped, it can still perform book(), search() operations. Anything I could do in the STOP method to prevent this from happening? Question #2: I believe you distinguishes the STOP and EXIT in your server GUI as well, did you run into such a problem> Finally, just to clarify something: since STOP does not exit the application, the RMIRegistry still hangs around. Therefore, I have a flag, rmistarted, to check whehter the RMIRegistry is started. When the user clicks START, the program first checks the flag, if it is not set, the RMIRegistry is started; otherwise, no action is taken. I have all these make sense to you. Comments are welcome! Christy what a stressful day for me today
Hi, am not sure about this .. since we bind the object which extend a UnicastRemoteObject to the rmi registry .. it has static method to "unexportObject" try that out .. as soon as your unbind the rmi object call the unexport object and observe the results .. sorry am in the middle of building my client .. and i didnt try this one .. if it works plz give us a shout it will helps us heaps .. am in the same track as you are too for more info on that method chk out the api docs if it does what its says am sure it shuld solve this one ==================== ok i just tried it out ===== here is the result and what i think is culd be the solution the first time it automaticaly exports the object .. so when u start the server it starts fine .. goin by the way i sugested ... when you hit the start button this is the error you will get .. " java.lang.InternalError: UnicastServerRef.writeExternal: server reference written to MarshalOutputStream" the trick is when the start button is clicked again have a flag to identify if this object is unexported .. if it is do an export and rebind the object it works .. now here is the sad part .. i didnt test it from the client side .. they might get some odd errors if somethin i did is not right .. hope u chk this out and tell us how did it go
hope this helps, cheers, parthi. [ October 10, 2002: Message edited by: parthiban subramaniam ]
Even crazy and silly looking problems are sometimes real.
Joined: Oct 15, 2001
Hi, Parthi, I went to the API and tried on my code. It does not seem to serve the purpose, and here is why: From the server side, I only have reference to the ConnectionFactory. But the object I am really trying to unexport is RemoteDataInterface created by the client from the ConnectionFactory.getConnection(). And I don't have reference to this RemoteDataInterface from the server at all. The following seemed to work for me: In my ConnectionFactory, I keep a vector that stores all the RemoteDataInterface instances any client has requested. When the server shuts down, I iterate through this vector and unexport all these remoteDataInterface. It seems to work on the surface, any one see a potential problem with this?? Thank you!. Christy