5 Replies Latest reply on Jan 28, 2008 8:31 AM by Sacha Labourey

    ProfileService shutdown and undeploy order

    Adrian Brock Master

      The problem with the NoInitialContext in the all configuration
      is because it is not undeploying the in the reverse order of deployment.

      17:49:05,946 ERROR [DefaultPartition] partition unbind operation failed
      javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
       at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645)
       at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
       at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:284)
       at javax.naming.InitialContext.unbind(InitialContext.java:375)
       at org.jboss.ha.framework.server.ClusterPartition.stopService(ClusterPartition.java:408)
      


      The issue is that the ProfileServiceBootstrap just does a MainDeployer.shutdown()
      but this just undeploys in "random" order.

       private Map<String, DeploymentContext> topLevelDeployments = new ConcurrentHashMap<String, DeploymentContext>();
      
       public void shutdown()
       {
       lockWrite();
       try
       {
       while (topLevelDeployments.isEmpty() == false)
       {
       // Remove all the contexts
       for (DeploymentContext context : topLevelDeployments.values())
       {
       topLevelDeployments.remove(context.getName());
       removeContext(context, true);
       }
      
       // Do it
       process();
       }
      


      In the example above, conf/jboss-service.xml is undeployed before
      the clustering deployment.

      This can obviously be fixed, but I guess what should really be happening
      is the ProfileService undeploys in reverse order of stages,
      i.e. APPLICATION then DEPLOYER then BOOTSTRAP.

      The MainDeployer.shutdown() should just be there to catch things
      that don't undeploy themselves properly.

      The problem is that the Profile api doesn't guarantee any ordering
       Collection<VFSDeployment> getDeployments(DeploymentPhase phase) throws Exception;
      


      even though it is implemented as ordered in ProfileImpl using LinkedHashMaps
       private LinkedHashMap<String, VFSDeployment> bootstraps = new LinkedHashMap<String, VFSDeployment>();
       private LinkedHashMap<String, VFSDeployment> applications = new LinkedHashMap<String, VFSDeployment>();
       private LinkedHashMap<String, VFSDeployment> deployers = new LinkedHashMap<String, VFSDeployment>();
      


        • 1. Re: ProfileService shutdown and undeploy order
          Scott Stark Master

           

          "adrian@jboss.org" wrote:

          This can obviously be fixed, but I guess what should really be happening
          is the ProfileService undeploys in reverse order of stages,
          i.e. APPLICATION then DEPLOYER then BOOTSTRAP.

          The MainDeployer.shutdown() should just be there to catch things
          that don't undeploy themselves properly.

          The problem is that the Profile api doesn't guarantee any ordering
           Collection<VFSDeployment> getDeployments(DeploymentPhase phase) throws Exception;
          


          Certainly the phases should be undeployed in reverse order. If needed the deployments api could express ordering using a List, but should that be necessary? If it started correctly it should stop correctly unless new dependencies are being accessed during shutdown.


          • 2. Re: ProfileService shutdown and undeploy order
            Brian Stansberry Master

            The HAPartition bean is just doing this in stopService():

            ctx = new InitialContext();
            ctx.unbind(boundName);

            In startService() it's more complicated, but essentially creates a new default InitialContext and does a rebind. So, no accessing a different dependency in stopService().

            The bean has a depends on jboss:service=NamingService.

            Looking at the javax.naming code, it looks like the only way the reported error would happen would be if the conf/jndi.properties file were no longer on the classpath. Would the incorrect ordering problem Adrian's mentioned result in conf/ being taken off the classpath prematurely?

            BTW, IIRC the failure message has changed; used to mention org.jboss.iiop.naming.ORBInitialContextFactory, perhaps as a CNFE. Wouldn't surprise me if solving the current error condition just brings that one back.

            • 3. Re: ProfileService shutdown and undeploy order
              Adrian Brock Master

              Actually there were two issues.

              1) The issue described above where deployments were undeployed in random
              order so the conf/jboss-service.xml classloader which includes the IIOP naming
              context class was removed too early.

              2) The undeploy was using the NoAnnotationURLClassLoader of bootstrap-beans.xml
              as the context classloader which wouldn't be able to see that classloader anyway.

              I've fixed (1)
              http://jira.jboss.com/jira/browse/JBAS-5175

              I've hacked around (2), but the proper fix will have to wait for the update
              to the MC that does the proper context classloader setting
              http://jira.jboss.com/jira/browse/JBAS-5176

              • 4. Re: ProfileService shutdown and undeploy order
                Adrian Brock Master

                 

                "bstansberry@jboss.com" wrote:

                BTW, IIRC the failure message has changed; used to mention org.jboss.iiop.naming.ORBInitialContextFactory, perhaps as a CNFE. Wouldn't surprise me if solving the current error condition just brings that one back.


                Yes, the way it was working, it couldn't see conf/jndi.properties either.

                When the latest MC code gets into trunk,
                your stop() will be invoked with the context classloader of your deploy/cluster
                deployment so all this hacking around with the context classloader in the profile service
                will go away.

                • 5. Re: ProfileService shutdown and undeploy order
                  Sacha Labourey Master

                   

                  "bstansberry@jboss.com" wrote:
                  The HAPartition bean is just doing this in stopService():

                  ctx = new InitialContext();
                  ctx.unbind(boundName);

                  In startService() it's more complicated, but essentially creates a new default InitialContext and does a rebind. So, no accessing a different dependency in stopService().

                  The bean has a depends on jboss:service=NamingService.


                  (
                  BTW, maybe we should have a notion of implicit services applied to multiple inner-services i.e. a wrapping tag applied to multiple inner-service definitions so that it would be possible to assign global "services" (or default services) en masse. Things like the naming service for example, while a singleton today, might not be a a singleton anymore tomorrow (if we want to make JBoss AS 5.x a "multi-tenant" implementation i.e. SaaS hosting infrastructure for example).
                  )