6 Replies Latest reply on Feb 2, 2010 8:07 AM by alesj

    Possible bug introduced in AbstractController?

    dmlloyd

      Since (I think) the MC upgrade to 2.2, there's a problem occurring with redeployment of jboss-logging.xml files in AS trunk.  If you make a small change (say, add whitespace) to the file to force it to be redeployed, you get this exception:

       

      13:16:47,987 WARN  [AbstractKernelController] Error uninstalling from Create: name=Logging:CONTEXT:system state=Configured mode=On Demand requiredState=Installed: java.lang.Error: INTERNAL ERROR: context not found in previous state Create context=name=JBossLogService state=Create mode=On Demand requiredState=Installed
           at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1416)
           at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1391)
           at org.jboss.dependency.plugins.AbstractController.uninstallUnusedOnDemandContexts(AbstractController.java:1629)
           at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1543)
           at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1391)
           at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1451)
           at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1391)
           at org.jboss.dependency.plugins.AbstractController.uninstallUnusedOnDemandContexts(AbstractController.java:1629)
           at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1543)
           at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1391)
           at org.jboss.dependency.plugins.AbstractController.uninstallUnusedOnDemandContexts(AbstractController.java:1629)
           at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1543)
           at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1391)
           at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:704)
           at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:617)
           at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.undeploy(BeanMetaDataDeployer.java:228)
           at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.undeploy(BeanMetaDataDeployer.java:58)
           at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalUndeploy(AbstractSimpleRealDeployer.java:69)
           at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.undeploy(AbstractRealDeployer.java:117)
           at org.jboss.deployers.plugins.deployers.DeployerWrapper.undeploy(DeployerWrapper.java:204)
           at org.jboss.deployers.plugins.deployers.DeployersImpl.doUndeploy(DeployersImpl.java:1690)
           at org.jboss.deployers.plugins.deployers.DeployersImpl.doUninstallParentLast(DeployersImpl.java:1597)
           at org.jboss.deployers.plugins.deployers.DeployersImpl.doUninstallParentLast(DeployersImpl.java:1590)
           at org.jboss.deployers.plugins.deployers.DeployersImpl.uninstall(DeployersImpl.java:1552)
           at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:384)
           at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1980)
           at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1536)
           at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:892)
           at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:602)
           at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:811)
           at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:654)
           at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
           at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:409)
           at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:294)
           at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
           at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
           at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
           at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
           at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
           at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
           at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
           at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
           at java.lang.Thread.run(Thread.java:619)
      Caused by: java.lang.Exception: STACKTRACE
           ... 43 more
      
      

       

      Seems like an internal error of some sort?  The referenced bean is pretty simple - it's "On Demand", simple dependency, no start/stop/create/destroy methods.  Find the declaration in logmanager-jboss-beans.xml if you're curious.

        • 1. Re: Possible bug introduced in AbstractController?
          alesj
          Is the bean already fully installed when is re-deployed or is it still in "limbo"?
          • 2. Re: Possible bug introduced in AbstractController?
            dmlloyd

            alesj wrote:

             

            Is the bean already fully installed when is re-deployed or is it still in "limbo"?

             

            It's fully installed, as far as I can tell, and everything seems to be up and working.  My evidence is that all beans deployed by jboss-logging.xml (and there are a lot of them) depend on this service, and they're installed, so the dependency must also be installed (right?).

             

            Maybe there's some race condition with OnDemand when all of its dependents disappear and then new ones reappear right away?

            • 3. Re: Possible bug introduced in AbstractController?
              alesj

              It's fully installed, as far as I can tell, and everything seems to be up and working.  My evidence is that all beans deployed by jboss-logging.xml (and there are a lot of them) depend on this service, and they're installed, so the dependency must also be installed (right?).

              Yup. :-)

              Maybe there's some race condition with OnDemand when all of its dependents disappear and then new ones reappear right away?

              I doubt that, as it's still the same single thread that handles this.

               

              We did some updates on how we handle this stuff,

              as we had some other bugz, it looks like we missed something. :-(

              • 4. Re: Possible bug introduced in AbstractController?
                kabirkhan

                I have fixed this https://jira.jboss.org/jira/browse/JBKERNEL-87

                 

                However, I am unsure how to test this. I added this to OnDemandDependencyTestCase

                 

                   public void testNoUglyError() throws Throwable
                   {
                      //FIXME This simply runs what used to cause the ugly error mentioned in JBKERNEL-87.
                      //I am not sure how to actually test that this does not happen since errors on uninstall
                      //are not reported back to the user.
                      TestDelegate delegate1 = getDelegate1();
                      ControllerContext context1 = assertInstall(delegate1, ControllerState.DESCRIBED);
                      TestDelegate delegate2 = getDelegate2();
                      ControllerContext context2 = assertInstall(delegate2);
                      assertContext(context1);
                
                      assertUninstall(context1); //What triggered the error
                
                      assertContext(context2, ControllerState.CONFIGURED);
                      assertNull(context2.getError());
                      assertNull(context1.getError());
                   }
                 
                
                • 5. Re: Possible bug introduced in AbstractController?
                  kabirkhan
                  Following server startup I have tried modifying both deployers/jboss-logging.deployer/META-INF/logmanager-jboss-beans.xml and deploy/jboss-logging.xml and no longer see the error with my local kernel snapshot.
                  • 6. Re: Possible bug introduced in AbstractController?
                    alesj

                    However, I am unsure how to test this.

                    What about if you override the Logger instance in Controller for this test?

                    The field is private, but reflection is your friend. :-)