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 Fri, 14 Aug 2009 09:42:16 GMT
I thought SimpleConfigurationManager.stopConfiguration() is called when user
click "stop" in the console. So I compared this method's code with
"restartConfiguration()" and gave the previous comment. Now I realize "stop"
click actually calls "unloadConfiguration()". So things are more complex...

-Jack

On Fri, Aug 14, 2009 at 1:38 AM, David Jencks <david_jencks@yahoo.com>wrote:

> I talked with Aaron Mulder and Dain a bit on IRC -- they originally
> implemented most of this IIRC.  We can't remember any reason for restart not
> to create new classloaders.
> Ivan is definitely correct that restart of a plugin will result in the same
> plugins being started as before the restart command, whereas stop/start will
> not.  I think this is desirable.
>
> I don't understand what Jack is proposing.  I'd like to see if we can
> change the restart command to create new classloaders.  I don't want to
> change the current behavior of stop and start.
>
> Here's an example of why we should not try to make stop/start remember
> child modules:
>
> A and B are independent modules and C depends on both A and B.
>
> Stop A >> C stops
> Stop B
>
> Start A >> C can't start
> Start B >> no way to know for sure if we want C to start.
>
> thanks
> david jencks
>
> On Aug 12, 2009, at 10:48 PM, Jack Cai wrote:
>
> 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