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.
-Tom
Matt
----- Original Message ----- From: "Tom McQueeney (JIRA)"
<dev@geronimo.apache.org> To: <dev@geronimo.apache.org> Sent: Sunday,
June 12, 2005 2:40 PM Subject: [jira] Commented: (GERONIMO-657)
Running configurations not saved on shutdown
[
http://issues.apache.org/jira/browse/GERONIMO-657?page=comments#action_12313393
]
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:
http://issues.apache.org/jira/browse/GERONIMO-657 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:
http://issues.apache.org/jira/secure/Administrators.jspa - For more
information on JIRA, see: http://www.atlassian.com/software/jira
