Shutdown Server Properly?

[Peter Yunguang Qiu]

2. Ctrl-C is OK for closing the server. Some of us created Server GUIs, but that is not a requirement for closing the server. However, you still need to have code to lock all the records if "-1" is passed to the lock method.

I am thinking of shutting down the server properly, but haven't got a good idea yet.
Locking all the records seems to be a good idea, but it seems too completed and I don't know how to do it properly. Are there any other symple way to shutdown server?
Mark or others, could you give me some help?

[Jacques Bosch]

Shutting down the server properly is probably a good thing to do.
I never did though. I just closed my DB file in the finalize() method of my Data class which doesn't even guarantee that it will be closed properly. I was very worried about this after submitting, but either they didn't notice, or didn't care, as I wasn't penalized for it.
But perhaps you can do something like wait for all current transactions to complete and don't accept any new transactions.
Enjoy.
J

[Anonymous]

Hi,
I've given the "proper shutdown" problem quite some thought - I believe;-)
What I do is the following:
[*]unbind the RMI object (or close the socket.accept thread) so that no new requests will get through.
[*]ask the db to shut itself down. It makes sure all pending request are completed (internally keeping track of them) and then closes the data file.
[*]call UnicastRemoteObject.unexportObject for the registry which was started by the server.start method.
This procedure allows me to start/stop the server in the server's admin GUI without terminating the program.
Regards,
Marcel
P.S. if someone has found a better solution to shutdown the RMI registry, please let me know...

[Jacques Bosch]

That sounds good to me.

[Mark Spritzler]

Well in the Fly By Night assignment there was a requirement to write lock to accept -1 which locks the entire database. So in my Server GUI, I had a button. the user clicks the button and lock(-1) is called, this will go and lock all the records. When that is done. I then know for sure that there are no clients with locks, so then it is ok to shutdown and unbind the server, and such. If you unbind the server first and stop RMI, then any clients that are in the middle of work will blow up.
Mark

[Peter Yunguang Qiu]

Thanks Jacques, Marcel and Mark. All of your comments are helpful to me.
[ April 20, 2004: Message edited by: Peter Yunguang Qiu ]

[Anonymous]

Mark,
If I unbind the RMI service, this means the no further requests will be served i.e. lookups will fail. All pending requests that have already obtained a reference to the stub are unaffected.
This is my understanding of RMI. Please correct me if I'm wrong.
Regards,
Marcel

[Mark Spritzler]

That is a good point, but I think you are missing my point on the design of the system and users.
1. Handling Exceptions on the client side is an extremely important part of any application. And handling the Server shutting Down, while the client is still up, would be completely handled, and have no issues with it. So if the client tries to call a method on the server after it has closed, then a nice Popup will say something like "Server is unavailable". This can happen to the client if the client starts up before the server is even started.
2. That is why calling lock(-1) and locking the entire database is so important to do before closing down the registry. If you did not do this, there would be a lot more mess, like a client thinking that they booked, when they actually didn't.
Does that make sense?
Mark

[Anonymous]

Mark,
I do understand your design and I think I got your point.
I believe I forgot to mention something... My db has an internal attribute called closing. The db methods read/write/etc. check this attribute before they try to operate on the data. The db's shutdown method sets closing = true. This basically blocks the db for all further requests (sort of lock(-1)). It then waits until all pending operations are finished (60 seconds timeout) and terminates (closing file, etc.). So, basically db.shutdown can be issued anytime without separatly locking anything.
Once a client has obtained a reference to a stub, is the naming scheme and the registry still needed? Or, does every call on the stub involve lookup operations? IMO, the registry is only necessary when the client tries to get a reference to a stub i.e. before first operation??? If this were true, Naming.unbind would not prohibit current clients from sending requests.
A much easier approach would be to use UnicastRemoteObject.unexport(). From the API doc:

Removes the remote object, obj, from the RMI runtime. If successful, the object can no longer accept incoming RMI calls. If the force parameter is true, the object is forcibly unexported even if there are pending calls to the remote object or the remote object still has calls in progress. If the force parameter is false, the object is only unexported if there are no pending or in progress calls to the object.

That sounds promising. You call unexport(myObject, )false) and the RMI runtime will take care of the rest. Is it as easy as that?
Regards,
Marcel

[Andrew Monkhouse]

Hi Marcel,

A much easier approach would be to use UnicastRemoteObject.unexport().
[...]

That sounds promising. You call unexport(myObject, )false) and the RMI runtime will take care of the rest. Is it as easy as that?

I am not sure if you are suggesting this as an alternative to your current concept of the "closing" attribute, or whether you are proposing it in addition to your current "closing" attribute.
If you are proposing it in addition to your current processing, then you should be quite safe, and it will stop clients from starting new calls to methods. The following should work quite well:

Client A connects

Client A reads a record

Server starts shut down procedures, unexporting existing clients

Client A tries to lock a record - gets an exception.

However any methods that are running when you disconnect the client will continue to run, so you still need your "closing" attribute to ensure your database is in a clean state when you shut down. That is, the following still has a potential for error without your flag:

Client A calls "book" method on server

Server starts shut down procedures, unexporting existing clients

book method checks lock exists

book method validates fields

book method starts writing fields

In this case, the book method will continue to run, even though the client connection has been unexported. So without your flag to ensure that the write does not occur, you risk data corruption.
Regards, Andrew

[Anonymous]

Hi Andrew,
Sorry for the confusion...
I now use it in addition to the closing attribute. So, the order is as follows: unbind, shutdown, unexport db, unexport registry. I believe I'm well off with this strategy.
[Something for a new posting actually...]
Nonetheless, there seems to be NO way to kill the registry completely. Once the registry has been started through

LocateRegistry.createRegistry(port)

it is controlled by a separate system thread which I don't get access to. This thread remains unaffected by the "unexport registry" operation. I can create a new registry on the same port afterwards without a bind/socket/etc. exception being thrown though, but the actual socket is only closed once the enclosing app is terminated.
Regards,
Marcel

[Mark Spritzler]

Naming.unbind would not prohibit current clients from sending requests.

Marcel, re-read my previous post. It is fine that a client can try to call a method on the server side at this point. That is what Exception catching is all about. It is the same as a client calling a method on this class when the server hasn't even been started. It isn't an issue or a problem, as long as you do exception handling correctly.
Mark

[Ling Chung]

Originally posted by Marcel St�r:
Hi,
I've given the "proper shutdown" problem quite some thought - I believe;-)
What I do is the following:

unbind the RMI object (or close the socket.accept thread) so that no new requests will get through.

ask the db to shut itself down. It makes sure all pending request are completed (internally keeping track of them) and then closes the data file.

call UnicastRemoteObject.unexportObject for the registry which was started by the server.start method.
This procedure allows me to start/stop the server in the server's admin GUI without terminating the program.
Regards,

Marcel
P.S. if someone has found a better solution to shutdown the RMI registry, please let me know...

Is it necessary to call the UnicastRemoteObject.unexportObject or is it sufficient to
1. lockdatabase
2. close database
3. unbind registry
Thanks for the help!!

[Mark Spritzler]

No, you do not need to call UnicastRemoteObject.unexportObject. The steps you have will be fine as long as you have correct Exception handling on your client side.
Mark

[Ling Chung]

Hello all,
last question on this subject :
when caling registry.unbind this method throws a lot of exceptions :
AccessException
RemoteException
NotBoundException
What to do in the catch block, i guess they all mean server is already closed... Can is state in the catch block // Do nothing or is there another way to handel this. printStackTrace for example?
Thanks!!

[Gytis Jakutonis]

1. lockdatabase
2. close database
3. unbind registry

How about this case - client A locks record 1 and dies(or leaves lock due to malicious code). Then if server administrator wants to shutdown the database, shutdown either block for a long time(till all dead clients are garbage collected) or wait forewer(till malicious client releases lock). I know that wait timeout can be used here, but how long should we wait?

[Anonymous]

Gytis,
I have my server wait for 60 seconds. Should perhaps be configurable through the properties file and GUI...
Regards,
Marcel

[Mark Spritzler]

Originally posted by Marcel St�r:
Gytis,
I have my server wait for 60 seconds. Should perhaps be configurable through the properties file and GUI...
Regards,
Marcel

Have your server wait for what?
Mark

[Ling Chung]

Interesting question, wait for x seconds then
1. just shutdown server;
2. give message there are still clients ask for shutdown OK CANCEL;
3. don't shutdown server.
I think option 2 is most elegant, but i'm still not sure for how long to wait?
Could someone also have a look at my other reaction? When i unbind the registry a lot of exceptions can be thrown. What to do with these, do they mean the registry is already "down" ?
[ April 27, 2004: Message edited by: Ling Chung ]

[Mark Spritzler]

Guys, I think you are all still missing the point. Shutting Down the server while there are still clients is absolutely fine. THere is no problems with this at all. The Clients know how to handle Exceptions thrown when there is no Server. That is how the client should react.
You are all thinking about this scenario, and not realizing that the client can do this also when the server isn't even started yet. Meaning a User can click on their client icon and start the application when there is no server running. So how does the client handle this. Through Exception handling, and displaying a nice message to the client. It is this exact approach to handle the server shutting down.
You guys are making a mountain out of a mohill.
There shouldn't be any waiting for an amount of time. Just call lock(-1) and lock the entire database, then shutdown the server. You do not need to worry about there being clients with stubs. This is ridicules to worry about.
Mark

[Anonymous]

Mark,
On one hand, I totally agree with you. Keep it simple... I assume that all of us thinking about proper server shutdown also have proper exception handling in place. The scenario you mentioned where the server hasn't even been started when the first client request arrives is good test for the most basic level.
On the other hand, I think that it is a fine feature to have the server wait until all pending transactions are finished. As a DBA I really appreciate it that Oracle allows me to choose whether I want to shutdown the instance immediatly or whether I want to allow transactions to terminate first. Ok, URLyBird et al. are not Oracle, but still...
The timeout ranchers worry about concerns - in my understanding - situations where a client transaction hangs (deadlock, etc.) and thus blocks the shutdown process.
Regards,
Marcel

[Mark Spritzler]

"I think that it is a fine feature to have the server wait until all pending transactions are finished."
Calling lock(-1) will wait for all clients to release their locks, and therefore all pending transactions are already finished.
Mark

[Gytis Jakutonis]

Mark,

Calling lock(-1) will wait for all clients to release their locks, and therefore all pending transactions are already finished.

But lock(-1) may block for e.g. 30 minutes if client holding lock has died or even block forever if malicious client holds lock without releasing it.

[Ling Chung]

Originally posted by Gytis Jakutonis:
Mark,

But lock(-1) may block for e.g. 30 minutes if client holding lock has died or even block forever if malicious client holds lock without releasing it.

That is exactly the point, if you lock the entire database and there is still a client holding a lock but client is dead, you can become blocked forever...
How to deal with this issue?

[Gytis Jakutonis]

Hi Ling,
I consider following options:
1. close file without locking the db(besides, where has that db lock(-1) idea came from? I know that some assignments include requirement to implement db lock, but my assignment has no word on this issue).
2. try to lock db - wait for 30s o smth like that and display error msg. adminisrator then can either wait once again or force db closing.
3. other?
2 seems to be quite reasonable, but even with this scheme we can come with corrupted records:
lock()
update() <- record update
... <- client blocks or dies or network is down etc.
update() <- one more update
unlock()
if we force db closing, then locked record becomes invalid. I know that it is not possible with this assignment, since we have single update between lock-unlock, but IMO we should think about all possible situations. So how to solve this problem? The best solution is to provide some kind of transactions(caching), so that record data is written into db file only on unlock() or smth like that. But it seems to be quite complex and out of assignment scope. So I think we should not bother with all these db blockings, just close db file.

[Mark Spritzler]

Originally posted by Gytis Jakutonis:
Mark,

But lock(-1) may block for e.g. 30 minutes if client holding lock has died or even block forever if malicious client holds lock without releasing it.

VERY SIMPLE. That is what the Unreferenced interface is all about, and also the WeakHashMap that Max suggests. This will make it so that there won't be any client's holding on to locks forever. Just won't happen.
You guys are going way overboard. I have been here at JavaRanch in this forum for over three years now, most of them as the bartender, and this has got to be the most stubborn group of programmers I have seen so far. Get over it, and realize that if Sun wanted you to go this far, they would be charging a lot more than $250. They want a simple straight-forward solution that still tests skills. Going overboard like this is not going to gain extra points, but can cause you to lose points. I have seen this over and over again. After you get your score, you will come back and say, I guess I went to far.
Either way, I will always let you guys choose your own solutions, it is your assignment.
Have fun. Bye.
Mark