-
Bug
-
Resolution: Done
-
Critical
-
7.1.0.DR17
-
None
-
-
-
-
-
-
Workaround Exists
-
Seen in our clustering tests for singleton deployments.
Timeline:
Node1 elected as the singleton provider
Some other node gets elected after topology change
Node1 gets elected after another topology change and logs:
13:08:42,248 INFO [org.wildfly.clustering.server] (DistributedSingletonService - 1) WFLYCLSV0003: node1 elected as the singleton provider of the jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".installer service 13:08:42,474 INFO [org.wildfly.clustering.server] (DistributedSingletonService - 1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".installer service 13:08:42,476 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".STRUCTURE: WFLYSRV0153: Failed to process phase STRUCTURE of deployment "clusterbench-ee7-singleton-jbossall.ear" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.IllegalArgumentException: Root element supplier for {http://www.jboss.com/xml/ns/javaee}jboss-app already registered at org.jboss.staxmapper.XMLMapperImpl.registerRootElement(XMLMapperImpl.java:51) at org.jboss.staxmapper.XMLMapperImpl.registerRootElement(XMLMapperImpl.java:46) at org.jboss.as.server.deployment.jbossallxml.JBossAllXMLParsingProcessor.deploy(JBossAllXMLParsingProcessor.java:90) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) ... 5 more
- is caused by
-
WFCORE-2738 SubDeploymentProcessor leaks Attachments.SUB_DEPLOYMENTS on undeploy()
- Resolved
-
WFCORE-2750 ModuleSpecProcessor does not recreate module spec after undeploy()
- Resolved
-
WFCORE-2733 JBossAllXmlParserRegisteringProcessor leaks deployment unit attachments on undeploy
- Resolved
-
WFCORE-2791 Auto-remove lingering deployment unit attachments following singleton deployment primary->backup transition
- Resolved
-
WFLY-8695 WeldPortableExtensionProcessor does not clear registered Extensions on undeploy()
- Closed
-
JBEAP-10787 Address DeploymentUnitProcessor leaks in the codebase
- Closed
-
WFLY-8697 Address DeploymentUnitProcessor leaks in the codebase
- Closed