[jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-270) Intermittent failure of undeploy

Ales Justin (JIRA) jira-events at lists.jboss.org
Fri Jul 29 06:08:23 EDT 2011


    [ https://issues.jboss.org/browse/JBDEPLOY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617487#comment-12617487 ] 

Ales Justin commented on JBDEPLOY-270:
--------------------------------------

OK, I see what the real problem is.
It's how AbstractBeanMetaData handles NestedBeanHandler.
It goes and re-creates a new nested bean list on every getBean invocation.
Where MetaDataVisitorNode uses set to order metadata children, hence PropertyMetaData is randomly ordered --> diff counter number.

Caching AbstractBeanMetaData::getBeans would probably fix this problem.


> 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

        


More information about the jboss-jira mailing list