geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jack Cai <greensi...@gmail.com>
Subject Re: Difference in start/stop and restart behavior
Date Thu, 13 Aug 2009 05:48:10 GMT
So we can't do a simple “stop(); start();" call to achieve "restart()" in
the implementation. We need to implement it in a non-trivial way.

1. Stop all configs that would otherwise be stopped in a "stop()" operation;
2. Reverse this list of configs and do a start.

There is some complexity to handle in the
o.a.g.kernel.config.ConfigurationStatus class.

-Jack

On Thu, Aug 13, 2009 at 1:32 PM, Ivan <xhhsld@gmail.com> wrote:

> Sometimes, restart is not equal to stop+start. Let's take an example,
> component A is depending on component B.
> While you restart B, Geronimo will do the actions like
> 1. stop A
> 2. stop B
> 3. start B
> 4. start A
> But while you stop B, we have to stop A too, but we have no way to record
> that A should be started while you start B in the future, so A will not be
> started while you start B again.
> Wish it helps !
>
>
>
> 2009/8/13 Jack Cai <greensight@gmail.com>
>
> Agreed. Restart should have the same effect as "Stop + Start".
>>
>> In the "o.a.g.kernel.config.ConfigurationStatus, "gc" is enabled for stop
>> by default, but there is no gc option (stop parent) for restart. Maybe
>> that's the place to modify?
>>
>> -Jack
>>
>>
>> On Thu, Aug 13, 2009 at 8:19 AM, Kevan Miller <kevan.miller@gmail.com>wrote:
>>
>>>
>>> On Aug 12, 2009, at 6:08 AM, Ashish Jain wrote:
>>>
>>>  Hi,
>>>>
>>>> Recently I have seen difference in the functionality of stop/start and
>>>> restart options available against each module. In case of stop/start I see
>>>> old classloaders
>>>> being discarded and new ones being created. In case of restart same old
>>>> classloaders are used.
>>>>
>>>> I am attaching a sample DummyProject here and an explanation of how it
>>>> works
>>>>
>>>> It has three classes: TestServlet , TestService and TestBean
>>>>
>>>> 1. Request comes to the TestServlet => Console prints “In TestServlet”
>>>> 2. TestServlet makes a call to the TestService class. TestService class
>>>> has a static variable called testBean of type TestBean. This variable is
an
>>>> initialized during class loading.
>>>> 4. When the call comes to TestService, if the static variable is created
>>>> then the Console prints “In TestBean constructor”. In case the static
>>>> variables isn't created then this statement doesn’t get printed to the
>>>> console.
>>>> 5. After which console prints “In TestService class”
>>>>
>>>> Steps to run the application:
>>>> 1.    Deploy this application to WAS community edition
>>>> 2.    Start the application
>>>> 3.    Hit the <WAS url>/<context>/TestServlet
>>>> 4.    Check the console
>>>>
>>>> If static variables are created then all the three statements must
>>>> appear as below in the console:
>>>> => In TestServlet
>>>> => In TestBean constructor
>>>> => In TestService class
>>>>
>>>> Restart the application and follow steps 2, 3 and 4. Notice only first
>>>> and last statements ('In TestServlet' & ' In TestService class') appear
>>>> indicating that static variables aren't created. But when stop and the start
>>>> this application, all the 3 statements appear.
>>>>
>>>> I would  like to know if this difference is intended or does it require
>>>> some fix so that restart behaves in a similar manner as stop/start?
>>>>
>>>
>>> I'm not sure. My guess is that the differences are unintended, but I'd
>>> have to spend some time to be sure... There may be some consequences to
>>> changing this behavior. David J may have thoughts on this...
>>>
>>> A Stop is going to stop a configuration, then unload the configuration
>>> (which will destroy the ClassLoader).
>>>
>>> A restart is going to stop a configuration, then start the same
>>> configuration (reusing the same ClassLoader). Thus any static initialization
>>> would have already occurred.
>>>
>>> Personally, I think a Restart should be functionally equivalent to
>>> Stop/Start.
>>>
>>> --kevan
>>
>>
>>
>
>
> --
> Ivan
>

Mime
View raw message