B&S: How do you handle the Exit in network mode?

[Darya Akbari]

Hi,

as I wrote my last sentence in my userguide.txt I recognized that I didn't implement my File -> Exit submenu

Now, how shall I react on Exit. In standalone mode I would shut down the complete application but in network mode I think other users will come after me and eat me for this

How do you handle the Exit in network mode

Regards,
Darya

[Reza Rahman]

Darya:

There really isn't a graceful way of handling shutting down an RMI server. One convoluted way would be to create a "shutdown" request on your server and wait for the unreferenced method to be invoked. At this point, you will have to "unbind" and "unexport" your remote objects so that new requests cannot be made and any client connection attempts will fail thereafter.

For my own implementaion, I simply warn the user about possible data corruption on shutdown request and ask him/her to confirm that no clients are currently connected. Due to my three-tier, thin client architecture, there is a very minimal possibilty of data corruption anyway.

Besides, I think this is well beyond the assigment requirtements.

Reza

[Darya Akbari]

Salam Reza ,

I think one should not allow a user to shutdown the whole application if the user is simply one of many users of the application. At least not for the network mode. In a standalone mode I have no problem to let the user shutdown the application.

Now for the network mode, how about to interpret the Exit as Exit of the application client i.e. same as Close?

Wouldn't it be possible to handle Exit differently according to the mode of use like for:

Standalone mode: to real exit
Networked mode: to close client (server remain intact)

What do you think?

Regards,
Darya
[ June 17, 2005: Message edited by: Darya Akbari ]

[Reza Rahman]

Salam Darya!

I absolutely agree with you, an "exit" request on the client simply means close the client connection to the server and leave the server running. In this case, you can simply set the remote object stub to null. This will eventaully release the client connection and then simply shut down the GUI. In my case, I simply resort to a System.exit call.

I was describing the case of an "exit" command on the server, which is a bit more tricky because you can't really ask the clients to stop connecting at an arbitrary period of time...

So yes, I would completely agree with you...

Reza

[Darya Akbari]

... to complete the networked mode Exit:

Would it upset the assessor when I write in my userguide.txt to type Ctrl+C in the server command line window to shut down the server

Regards,
Darya

[Reza Rahman]

Darya:

I see no reason why this would not be an acceptable solution. In my case, I have a server GUI (just a choice, mind you, my requirement did not state this) and hence an "shutdown" button.

If you wanted to follow my model of server shutdown confirmation, you could always trap the CTRL-C, get a command-line driven confirmation (like so many other UNIX servers) and shut the server down.

I would definitely have some kind of shutdown function though, to do possible resource cleanup (i.e. release file handles, release ports, etc.).

Reza

[Reza Rahman]

Darya:

There is a minor problem that I did not notice before...I would not specifically mention CTRL-C as this is not platform independent (you could use this as an example of "O/S terminate signal", though)...

Take a look at Runtime.addShutDownHook added after Java 2 1.3...see if this gives you some ideas.

Reza

[Darya Akbari]

You are right. Under Unix it's Ctrl+D isn't it? I have to check out how to cope with server shutdown.

If you have more thoughts let me know.

Regards,
Darya

[Darya Akbari]

I have no clue what to do with the Runtime.addShutDownHook .

After doing some search here at the SCJD forum, it seems that Ctrl+C should be sufficient to shut down the server.

Hence I let the assessor hit the Ctrl+C or whatever kills my server .

Regards,
Darya

[Andrew Monkhouse]

Hi Darya,

You are right. Under Unix it's Ctrl+D isn't it?

Nope, under Unix it is SIG-INT which can be triggered in many ways, Ctrl-C being one of them. More importantly (from a server application perspective), SIG-INT can be triggered by UPS monitoring software or by server shutdown, or by another application (e.g. a command center application controlling all server processes). Which, in my personal opinion is a very good thing - we could have a clean B&S server shutdown if the power goes out, rather than having someone try and shut down via a server gui (that wont even be viewable because the screens wont have power :roll: )

However this is definately beyond what I think the instructions are asking for - my reading of them seems to imply that a GUI is required for server startup, in which case you can use the same GUI for shutdown - many candidates have, with near perfect scores.

Regards, Andrew

[Andrew Monkhouse]

Hi Darya

I have no clue what to do with the Runtime.addShutDownHook .

There is some discussion and sample code here.

Regards, Andrew

[Darya Akbari]

Hi Andrew,

I can't share your reading of the instructions:

... - my reading of them seems to imply that a GUI is required for server startup, in which case you can use the same GUI for shutdown - ...

And my server gui for the configuration setting to my mind is not a right place to put my Stop Server button in it.

On thte other hand I very much like your Runtime.addShutDownHook example as it really looks simple. In your mentioned thread however you scare me with your last quote:

Also big note: this is getting a bit beyond the requirements of the assignments you have been given. Shutting down cleanly is something you really should do, and I offered this as a suggestion if you did have your users hitting Ctrl-C to exit the server. However if you have a GUI with an exit button, then you can save yourself a lot of work

Especially the last sentence confuse me. At the moment I try to find all resource entities that fell under the topic cleanup. And honestly that make me some headache .

Is it that what you mean?

Regards,
Darya
[ June 18, 2005: Message edited by: Darya Akbari ]

[Darya Akbari]

Hi,

Ok, that's what I come up with and where I think these are entities that use system reources and which I use to read/write my database file and my suncertify.properties file.

Here it goes:

DataInputStream

DataOutputStream

FileInputStream

FileOutputStream

Their close() method releases any system resources associated with the stream. So these seem to be potential resource wasting entities one sould handle in a cleanup procedure.

I checked my code and find that only my DataInputStream and DataOutputStream could make trouble when the server suddenly shuts down and when there are still clients who are in the middle of their write action to the data file.

But honestly I can't find a way how to handle these Steams in a seperate Thread to obtain the actual stream object references in use.

John Smith alias Eugene Kononov write in this old thread close the file on the server the following:

I would say don't bother with graceful server shutdown, or server GUI, or calling lock(-1), or dead users. Those are the bells and whistles that are beyond your requirements and they add nothing to the clarity/reusability of the design. I did none of them, and got a maximum score for my server design. ...

That sound somewhat hopeful because I am near being brain dead on this issue .

Regards,
Darya
[ June 18, 2005: Message edited by: Darya Akbari ]

[Andrew Monkhouse]

Hi Darya,

I believe it is good to be able to shut down the server cleanly. However I don't believe it is a requirement of the Sun assignment to handle every possibility. As John suggests, you can get a perfect score without handling everything possible.

If you wanted to handle most cases, you can have a server GUI with a shutdown button (or menu item) on it. When the user chooses shutdown, the system calls System.exit - note that this on it's own is not a clean shutdown. If you also have a runtimeHook, the runtimeHook will be called when System.exit is called (or Ctrl-C is pressed or SIG-INT is sent to the application), so you will have one thread that does all the clean shutdown routines. And all you need in the clean shutdown routine is to set a flag to say that no more file operations are allowed, and then close the files. Those two operations would have to be in a synchronized block, the same as your read(), update() ... and other methods need to be. The read(), update() ... methods would also need to honour the flag (otherwise they will get a NullPointerException when they try to read the closed file). There are even ways for you to give the shutdown thread greater priority than the standard threads (but that is something for you to think about ). Once the shutdown hook thread has completed, your files will be in a clean state (closed) and your server will exit cleanly.

Regards, Andrew

[Darya Akbari]

Hi Andrew,

thanks for the detailed description. But I'll have to leave it for this exam.

I have to go for the essay exam next friday and must do my last check ups and really have no brain to go for this solution.

However I keep it in mind for my real life applications.

Thanks,
Darya