geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Difference in start/stop and restart behavior
Date Thu, 13 Aug 2009 17:38:03 GMT
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.

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 <> 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 <>
> 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  
> <> 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

View raw message