[jboss-jira] [JBoss JIRA] (WFLY-10253) ConcurrentModificationException on startup

Wed May 2 13:36:00 EDT 2018

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

Martin Herschke edited comment on WFLY-10253 at 5/2/18 1:35 PM:
----------------------------------------------------------------

Hi [~smarlow]

{quote}Could you show us the contents of the EAR that you are deploying (output of "jar tf yourapp.ear" and also the contents of contained archives)? Mostly I am curious if there are any persistence provider jars contained in the EAR and if yes, the location in the EAR. I'm also interested in the location of the persistence.xml files in the EAR as well.{quote}
I'm afraid I can't give you the exact output. It would give away customer-related informations. But if it's really necessary, I can request a shortened // anonymised version. 

What I can tell you though is that we have a fat ear consisting of 1x web archive, ~20x jar modules {color:#707070}(two of them containing a persistence.xml){color}, some rar modules and a lib folder including several other jars {color:#707070}(mostly emf, etc.){color}. 

*customer-ear*
*    _customer.war_
*    base-commons.jar 
*    base-i18n.jar
*    base-model.jar 
*    base-domain.jar 
*    base-business.jar
*    base-communications.jar
*    customer-commons.jar
*    customer-i18n.jar
*    customer-model.jar
*    customer-domain.jar => containing persistence.xml
*    customer-business.jar
*    customer-communications.jar
*    ... _some other jars / rars_
*    user-preferences.jar => additional persistence.xml
* lib/ ... _all the other dependencies_

Both jars contain a single {{META-INF\persistence.xml}} file {color:#707070}(in the stated folder){color}. The first one defines several datasources responsible for our normal workflow. The second one defines a single, separate datasource that helps us store 'user-preferences' like filter settings, etc. Both reside directly inside the ear {color:#707070}(as shown above){color}. 

And in response to this statement:
{quote}I think this is probably a symptom of a different problem, deployers should not be iterating over lists that are in the process of being concurrently changed, as that may give inconsistent deployment results.{quote}
The iteration over the persistence providers is done by the {{PersistenceUnitServiceHandler#lookupProvider}} itself... and the very same method also seems to call {{PersistenceProviderDeploymentHolder#savePersistenceProviderInDeploymentUnit}} that might add elements to the list of providers. 

was (Author: mhk):
Hi [~smarlow]

{quote}Could you show us the contents of the EAR that you are deploying (output of "jar tf yourapp.ear" and also the contents of contained archives)? Mostly I am curious if there are any persistence provider jars contained in the EAR and if yes, the location in the EAR. I'm also interested in the location of the persistence.xml files in the EAR as well.{quote}
I'm afraid I can't. It would give away customer-related informations. But if it's really necessary, I can request a shortened // anonymised version. 

What I can tell you though is that we have a fat ear consisting of 1x web archive, ~20x jar modules {color:#707070}(two of them containing a persistence.xml){color}, some rar modules and a lib folder including several other jars {color:#707070}(mostly emf, etc.){color}. 

*customer-ear*
*    _customer.war_
*    base-commons.jar 
*    base-i18n.jar
*    base-model.jar 
*    base-domain.jar 
*    base-business.jar
*    base-communications.jar
*    customer-commons.jar
*    customer-i18n.jar
*    customer-model.jar
*    customer-domain.jar => containing persistence.xml
*    customer-business.jar
*    customer-communications.jar
*    ... _some other jars / rars_
*    user-preferences.jar => additional persistence.xml
* lib/ ... _all the other dependencies_

Both jars contain a single {{META-INF\persistence.xml}} file {color:#707070}(in the stated folder){color}. The first one defines several datasources responsible for our normal workflow. The second one defines a single, separate datasource that helps us store 'user-preferences' like filter settings, etc. Both reside directly inside the ear {color:#707070}(as shown above){color}. 

And in response to this statement:
{quote}I think this is probably a symptom of a different problem, deployers should not be iterating over lists that are in the process of being concurrently changed, as that may give inconsistent deployment results.{quote}
The iteration over the persistence providers is done by the {{PersistenceUnitServiceHandler#lookupProvider}} itself... and the very same method also seems to call {{PersistenceProviderDeploymentHolder#savePersistenceProviderInDeploymentUnit}} that might add elements to the list of providers. 

> ConcurrentModificationException on startup
> ------------------------------------------
>
>                 Key: WFLY-10253
>                 URL: https://issues.jboss.org/browse/WFLY-10253
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 10.1.0.Final
>            Reporter: Martin Herschke
>            Assignee: Dmitrii Tikhomirov
>
> standalone wildfly startup: This exception appears sporadically and is caused by different modules and projects.
> Multiple threads are used to deploy modules ({{MSC service thread 1-7}}), but a static method {{lookupProvider}} is called. The provider list is a normal ArrayList that causes the exception.
> {code}
> 16:36:23,604 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."<our_ear>"."<our_module>".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."<our_ear>"."<our_module>".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of subdeployment "<our_module>" of deployment "<our_ear>"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 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.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:940)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.nextPhaseDependsOnPersistenceUnit(PersistenceUnitServiceHandler.java:1052)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:136)
> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> {code}

--
This message was sent by Atlassian JIRA
(v7.5.0#75005)