[jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-270) Intermittent failure of undeploy
[
https://issues.jboss.org/browse/JBDEPLOY-270?page=com.atlassian.jira.plug...
]
Dennis Reed commented on JBDEPLOY-270:
--------------------------------------
Hot-deploy the attached descriptor several times in EAP 5.0.1 and you'll see it
happen.
With logging added in org.jboss.beans.metadata.plugins.AbstractBeanMetaData#setName.
When deploying it may register:
dennis$defaultEvictionRegionConfig#1
dennis#2
dennis$evictionConfig#3
Then while undeploying, unregister:
dennis#1
dennis$defaultEvictionRegionConfig#2
dennis$evictionConfig#3
(leaving dennis$defaultEvictionRegionConfig#1 and dennis#2 registered)
So the next time it deploys, if it tries to register one of these, it gets the exception.
Doing some further testing in different versions, while it's simple to reproduce in
EAP 5.0 and 5.0.1,
I'm unable to reproduce the exception in EAP 5.1 or 5.1.1.
(The components are still getting assigned different names during deploy and undeploy, but
the
"Unable to register deployment mbean" exception is not being thrown).
Was there a related change made in EAP 5.1?
Intermittent failure of undeploy
--------------------------------
Key: JBDEPLOY-270
URL: https://issues.jboss.org/browse/JBDEPLOY-270
Project: JBoss Deployers
Issue Type: Bug
Components: deployer
Affects Versions: JBDEPLOY-2.0.10.GA
Reporter: Dennis Reed
Attachments: JBDEPLOY-270-jboss-beans.xml
When components are deployed, they are assigned names with a number appended based on the
order it was processed.
For example
"jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component"
The number is assigned in (line #'s are from EAP 5.0):
at
org.jboss.beans.metadata.plugins.AbstractBeanMetaData.setName(AbstractBeanMetaData.java:360)
at
org.jboss.beans.metadata.plugins.NestedBeanHandler.checkForNestedBeans(NestedBeanHandler.java:77)
at
org.jboss.beans.metadata.plugins.AbstractBeanMetaData.getBeans(AbstractBeanMetaData.java:202)
at
org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.getBeans(AbstractKernelDeployment.java:233)
at
org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:63)
at
org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:54)
at
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:118)
However, the beans are *not* processed in the same order every time.
And they are processed separately during deployment and undeployment.
This means that "myBean#1" may get deployed, but "myBean#2" is
undeployed (leaving "myBean#1" still deployed).
Subsequent deployments will fail with errors:
17:34:30,630 WARN [AbstractDeploymentContext] Unable to register deployment mbean
dennis$defaultEvictionRegionConfig#1
javax.management.InstanceAlreadyExistsException:
jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component
already registered.
The root cause appears to be that the XML descriptor is read with jboss-xb using a Set
(unordered), but then
this code has a dependency on the order being consistent between deploy and undeploy.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira