Archived
This forum has been archived. Please start a new discussion on GitHub.
Server shutdown with Ctrl-C vs. Process
Hi,
I recently changed my server implementation to perform a network operation (unsubscribe from IceStorm) before shutting down. In my class derived from Ice::Application I re-implement the new interruptCallback() function to do this.
This works well when the application executes from the command line and is stopped with Ctrl-C.
I expected this to work similarly with IceGrid but it doesn't seem to. It looks like the communicator is destroyed right away. Is this to be expected? I couldn't find an explicit reference in the manual to what the ProcessI object does when shutdown() is called.
"When shutdown is invoked, the object implementing this interface is expected to initiate the termination of its server process." (28.18.4)
Thanks a lot, Alex
I recently changed my server implementation to perform a network operation (unsubscribe from IceStorm) before shutting down. In my class derived from Ice::Application I re-implement the new interruptCallback() function to do this.
This works well when the application executes from the command line and is stopped with Ctrl-C.
I expected this to work similarly with IceGrid but it doesn't seem to. It looks like the communicator is destroyed right away. Is this to be expected? I couldn't find an explicit reference in the manual to what the ProcessI object does when shutdown() is called.
"When shutdown is invoked, the object implementing this interface is expected to initiate the termination of its server process." (28.18.4)
Thanks a lot, Alex
0
Comments
-
Hi Alex,
The default process interface (or admin facet if you use Ice 3.3.0) simply calls the communicator shutdown method which unblocks the thread waiting on waitForShutdown (the main thread in general).
Why don't you unsubscribe form IceStorm after the waitForShutdown method returns? You can still perform Ice invocations after waitForShutdown returns (client side invocations can't be performed until the communicator destroy method is called). This way, you can use the default interrupt callback and process interface.
Otherwise, you'll need to override the default process interface as well (or admin facet if you use Ice 3.3.0). Let us know if you need more information on this.
Cheers,
Benoit.0 -
Thanks Benoit,
I understand the issues now. I was missing the fact that ProcessI shuts down the communicator. (and I forgot the difference between the communicator's shutdown and destroyed states).
I prefer, of course, that my application behaves the same when run manually or by IceGrid. So, practically, that means calling shutdownOnInterrupt() and then waitForShutdown() as you suggested.
This is not perfect for what I was trying to achieve, however. I wanted to keep the communicator fully functional until I unsubscribe from IceStorm. At high data rate, chances are high that an incoming message from IceStorm bounces off between the time the communicator is shutdown and the time when my application gets a chance to unsubscribe.
The reason I am looking into this: I'm trying to debug a rare case when some part of the multi-component system gets blocked or runs out of threads and, it seems to have something to do with IceStorms subscriptions or deliveries. The way to induce this condition is by cycling the system up and down (through IceGrid). The problem is that, with component not unsubscribing before shutdown, IceStorm continuously reports "subscriber errored out" so it's hard to separate expected errors from the unexpected. I was hoping to quiet everything down a bit to clarify things.
Anyway, I'll look for other ways to debug this. Reimplementing the Process interface seems like an overkill.
Meanwhile, if you are taking suggestions, it would be nice to have some parity/compatibility in options for shutting down behavior between Ice::Application and IceGrid. I guess the old option of using signals instead of Process interface would be useful in this case.
Thanks for your help,
Alex0 -
Thanks Benoit,
Meanwhile, if you are taking suggestions, it would be nice to have some parity/compatibility in options for shutting down behavior between Ice::Application and IceGrid. I guess the old option of using signals instead of Process interface would be useful in this case.
If you use Ice 3.3.0, you can disable the process registration by setting Ice.Admin.Endpoints to an empty string in the server configuration. This will disable the Ice.Admin plugin and IceGrid will use the SIGTERM signal instead of the process interface to shutdown the server.
Cheers,
Benoit.0 -
Excellent! I tried it and gives me all the options I need.
(I knew how to disable the Admin interface but wan't sure that the Node will resort to sending signals in that case. It is rather obvious in retrospect.
)
alex0
