I see what you are saying about breaking the mirror, the removal of deployers should be controlled by the deployer services.
Code already exists in ServerImpl.ShutdownHook.shutdown() to invoke ServiceController.shutdown(), which walks backwards through it's service list to stop, destroy and remove each. From what you say, this could handle undeploying everything. Currently, nothing actually gets undeployed at that point because MainDeployer.shutdown() gets called, and undeploys everything, before ServiceController.shutdown() is called. So, if service shutdown effectively handles undeployment, and preserves the mirror, is there really a need for MainDeployer to undeploy anything at shutdown? Can MainDeployer do all its housekeeping in destroyService()? Then what's left for shutdown() do? Except maybe ask the service controller to stop the deployer services? Rod Burgett Senior Software Engineer webMethods, Inc. 3930 Pender Drive Fairfax, VA 22030 USA Ph: 703.460.5819 (tty only) "It's all just 0s & 1s - the trick is getting them lined up in the proper order" > -----Original Message----- > From: Scott M Stark [mailto:[EMAIL PROTECTED] > Sent: Monday, July 07, 2003 11:35 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] multiple deployment info entries for > invoker.war > > > The bigger problem is that the deployment layer does not run > a clean state > machine. Requests to deploy content should not be allowed > when the MainDeployer > is being shutdown and therefore the deployment list copy is > not needed. > > Adding a removeDeployer loop in the MainDeployer.shutdown > actually breaks the > current start/stop mirror behavior since currently all but > the bootstrap jar and > sar deployers are added/removed in the > SubDeployerSupport.startService/stopService methods. What > makes more sense to me > is to have the MainDeployer.shutdown stop all deployers which > will have the side > affect of undeploying all content and removing the deployers. What is > inconsistent here is that the MainDeployer, JARDeployer and > SARDeployer are > started as bootstrap services by the ServerImpl, but shutdown > does not simply > stop and unregister these services in reverse order. > > -- > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > > Rod Burgett wrote: > > > D-oh! That's embarrassing, I missed the finally block, > thinking that > > 'return' meant return. Thanks for pointing that out. > > > > I stumbled onto this duplication while investigating some > extra warning > > messages during shutdown. I'm working on a patch to clean > those up. I'll > > add something to that patch for this up as well. > > > > The extra warning messages are from .war files nested > inside .sar or .ear > > files; for example invoker.war inside http-invoker.sar. > They both have > > entries in deploymentList, and undeploying the .sar > undeploys the .war, > > which removes the .war from the deploymentList. But after the .sar > > undeployment finishes, shutdown() attempts to undeploy the > .war, again. Why > > does it try again when the .war is no longer in > deploymentList? Because > > shutdown is working from a copy of deploymentList. > > > > You see the same message with welcome.ear and welcome.war. > Also, I think > > the same sequence occurs with nested .jar files, but the > JARDeployer doesn't > > complain, so it's not noticable. > > > > I think the best solution for this is to add a > removeDeployer loop to > > MainDeployer.shutdown(), prior to the 'undeploy everything > in sight' loop. > > That will change the order of undeployment some, but not materially. > > Basically, this eliminates the duplicate undeployment by > splitting it up, so > > a new deploymentList copy is made for each deployer. > > > > Conceptually, this is a cleaner shutdown than the current > one, since the > > current shutdown doesn't go through the removeDeployer > processing. A > > graceful shutdown should mirror startup as much as possible. > > > > This isn't a perfect solution, because this removeDeployer > loop can't remove > > the JAR and SAR deployers. There may still be nesting > scenarios - maybe an > > archive nesting an archive of the same type - where the > list gets out of > > synch with it's copy. I'm open to other suggestions. > > > > > > Rod Burgett > > Senior Software Engineer > > > > webMethods, Inc. > > 3930 Pender Drive > > Fairfax, VA 22030 USA > > Ph: 703.460.5819 (tty only) > > > > "It's all just 0s & 1s - > > the trick is getting them lined up in the proper order" > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_06 > 1203_01/01 > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
