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

Possible bug introduced in AbstractController?

dmlloyd Feb 1, 2010 2:21 PM

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 Feb 1, 2010 3:58 PM (in response to dmlloyd)

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

dmlloyd Feb 1, 2010 4:05 PM (in response to alesj)

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?
Actions
3. Re: Possible bug introduced in AbstractController?

alesj Feb 1, 2010 4:09 PM (in response to dmlloyd)

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. :-(
Actions

4. Re: Possible bug introduced in AbstractController?

kabirkhan Feb 2, 2010 7:27 AM (in response to alesj)

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 Feb 2, 2010 8:00 AM (in response to 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.
Actions
6. Re: Possible bug introduced in AbstractController?

alesj Feb 2, 2010 8:07 AM (in response to kabirkhan)

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

Go to original post