geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom McQueeney <>
Subject Re: [jira] Commented: (GERONIMO-657) Running configurations not saved on shutdown
Date Sun, 12 Jun 2005 22:45:43 GMT
Matt Hogstrom wrote:
> I like the idea.  I'd add that it would be nice to use a scheme such
> as linux does for startup / shutdown with a letter designator and a
> number in the rc.n directories.  That scheme allows a lot of
> flexibility and control as well.  I also like the runLast / runFirst
> idea but there can only be one first and last :)

Thanks for your feedback. How about a boolean runAtEnd to kinda imply it 
won't be the last, but it will be run toward the end? This would be easy 
to implement.

Maybe Dain can answer this, but perhaps a completely different solution 
is not to use a shutdown hook at all in the FileConfigurationList GBean. 
Maybe the GBean should save the name of running configurations at doStop 
time. At first glance, I can't see a reason why this solution wouldn't 
work, since I don't think other GBeans write to the config.list store, 
but maybe other components read the file and would break if the file 
were changed while the server was running and someone stopped the 
FileConfigurationList GBean.

The above change would solve the problem with the FileConfigList GBean 
but maybe cause problems in the future for other shutdown hooks. 
(Currently, only two GBeans register shutdown hooks with the kernel.) 
The primary problem with the configuration manager's shutdown hook 
running first is it stops all the GBeans. Any kernel references the 
other GBean shutdown hooks have become stale proxies afterword, making 
any work they need to do with the other components a little difficult.


> Matt
> ----- Original Message ----- From: "Tom McQueeney (JIRA)"
> <> To: <> Sent: Sunday,
> June 12, 2005 2:40 PM Subject: [jira] Commented: (GERONIMO-657)
> Running configurations not saved on shutdown
>> [
>> ]
>> Tom McQueeney commented on GERONIMO-657: 
>> ----------------------------------------
>> The shutdown hook for FileConfigurationList doesn't run because it
>> gets unregistered during the kernel shutdown process. That's
>> because the ConfigurationManagerImpl shutdown hook gets run FIRST,
>> knocking the feet out from under any other shutdown hook registered
>> by a GBean. This hook tells all loaded configurations to stop. When
>> the FileConfigurationList  gets the doStop(), it dutifully
>> unregisters it shutdown hook to save the active configurations. The
>> FileConfigurationList hook never runs.
>> One way to solve this problem is to ensure the
>> ConfigurationManagerImpl shutdown hook runs last. To do this, we
>> could define a shutdown hook ordering, such as adding a "priority"
>> parameter to the Kernel's registerShutdownHook method. Something
>> like:
>> /** * Registers a runnable to execute when the kernel is shutdown *
>> @param hook a runnable to execute when the kernel is shutdown */ 
>> void registerShutdownHook(Runnable hook, int priority);
>> Using an int would be a quick way, and we could define two
>> priorities, LOW and HIGH and ensure the ConfigurationManagerImpl
>> uses LOW. Or we could use an enumerated priority object type.
>> Either way isn't terribly clean because the GBean has to have a
>> good idea of what order its shutdown hook should run, and really we
>> only need to assure that stopping all configurations is performed
>> last rather than needing the other shutdown hooks to run first.
>> Perhaps we could add a boolean "runLast" parameter instead of a
>> priority parameter, and those with true would be added to the end
>> of the shutdown hook list, while those with false would be added to
>> the front.
>> I'd be happy to implement a solution like this if folks think it's
>> a good idea.
>>> Running configurations not saved on shutdown 
>>> --------------------------------------------
>>> Key: GERONIMO-657 URL:
>>> Project:
>>> Geronimo Type: Bug Reporter: Dain Sundstrom
>>> When the server shuts down the current running configuration
>>> should be saved to var/config/config.list but it doesn't look
>>> like this code works anymore.  It would be nice if there were a
>>> test case for this functionality.
>> -- This message is automatically generated by JIRA. - If you think
>> it was sent incorrectly contact one of the administrators: 
>> - For more
>> information on JIRA, see:

View raw message