6 Replies Latest reply: Feb 2, 2010 8:07 AM by Ales Justin RSS

Possible bug introduced in AbstractController?

David Lloyd Master

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?
    Ales Justin Master
    Is the bean already fully installed when is re-deployed or is it still in "limbo"?
  • 2. Re: Possible bug introduced in AbstractController?
    David Lloyd Master

    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?
    Ales Justin Master

    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?
    Kabir Khan Master

    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?
    Kabir Khan Master
    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?
    Ales Justin Master

    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. :-)