You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Tom McQueeney (JIRA)" <de...@geronimo.apache.org> on 2005/06/12 20:40:46 UTC
[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
Re: [jira] Commented: (GERONIMO-657) Running configurations not saved
on shutdown
Posted by Jeremy Boynes <jb...@apache.org>.
Tom McQueeney wrote:
> Jeremy Boynes wrote:
>>
>> Probably better is to not do this automatically on shutdown at all as
>> at that time you are not certain that the configurations are actually
>> good.
>>
>> Instead, how about sending a notification out when the set of
>> Configurations that are /meant/ to be running changes (e.g. at the end
>> of a JSR88 start operation) and have the FCL GBean listen for those
>> notifications and update its state then.
>
>
> Jeremy: Thank you for the advice. I can see updating the config.list
> when a configuration is started or stopped is a better solution. It
> would allow cleaner server restart after an unexpected shutdown.
>
> Unfortunately, this better solution involves areas of Geronimo I'm
> unfamiliar with. I'm still interested in fixing this bug more elegantly,
> so any advice you can give on where the jsr-88 start (and stop?)
> operations take place would be appreciated.
The code is in the deploy-tool module in o.a.g.deployment.plugin.local
> Also, regarding the FCL
> listening for stop/start events, would this be via a LifecycleListener?
> The FCL would register for events coming from the
> PersistentConfigurationList objectname?
>
Easier perhaps would be to modify the deploy-tool commands to talk to
the PCL GBean and call started/stopped methods on its interface (or to
get the List from it, update it and then write it back). These will be
new ones :-)
The Daemon class allows for multiple PCLs to be present but nothing maps
configs to lists - seems odd and perhaps could be tidied up.
--
Jeremy
Re: [jira] Commented: (GERONIMO-657) Running configurations not saved
on shutdown
Posted by Tom McQueeney <to...@mcqueeney.com>.
Jeremy Boynes wrote:
> Tom McQueeney wrote:
>
>> 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.
>>
>
> Probably better is to not do this automatically on shutdown at all as at
> that time you are not certain that the configurations are actually good.
>
> Instead, how about sending a notification out when the set of
> Configurations that are /meant/ to be running changes (e.g. at the end
> of a JSR88 start operation) and have the FCL GBean listen for those
> notifications and update its state then.
Jeremy: Thank you for the advice. I can see updating the config.list
when a configuration is started or stopped is a better solution. It
would allow cleaner server restart after an unexpected shutdown.
Unfortunately, this better solution involves areas of Geronimo I'm
unfamiliar with. I'm still interested in fixing this bug more elegantly,
so any advice you can give on where the jsr-88 start (and stop?)
operations take place would be appreciated. Also, regarding the FCL
listening for stop/start events, would this be via a LifecycleListener?
The FCL would register for events coming from the
PersistentConfigurationList objectname?
-Tom
>
> --
> Jeremy
>
Re: [jira] Commented: (GERONIMO-657) Running configurations not saved
on shutdown
Posted by Jeremy Boynes <jb...@apache.org>.
Tom McQueeney wrote:
> 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.
>
Probably better is to not do this automatically on shutdown at all as at
that time you are not certain that the configurations are actually good.
Instead, how about sending a notification out when the set of
Configurations that are /meant/ to be running changes (e.g. at the end
of a JSR88 start operation) and have the FCL GBean listen for those
notifications and update its state then.
--
Jeremy
Re: [jira] Commented: (GERONIMO-657) Running configurations not saved
on shutdown
Posted by Tom McQueeney <to...@mcqueeney.com>.
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)"
> <de...@geronimo.apache.org> To: <de...@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
>>
>>
>>
>
>
Re: [jira] Commented: (GERONIMO-657) Running configurations not saved on shutdown
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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 :)
Matt
----- Original Message -----
From: "Tom McQueeney (JIRA)" <de...@geronimo.apache.org>
To: <de...@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
>
>
>