[JBoss JIRA] (WFLY-13162) ConcurrentModificationException in WildFlyJobXmlResolver
by Ralf Battenfeld (Jira)
[ https://issues.redhat.com/browse/WFLY-13162?page=com.atlassian.jira.plugi... ]
Ralf Battenfeld commented on WFLY-13162:
----------------------------------------
Good morning, I can conform this issue. We are using wildfly 17, and run on RHEL7 with open jdk. We execute a cli script that updates the configuration on runtime. This causes redeployments.
> ConcurrentModificationException in WildFlyJobXmlResolver
> --------------------------------------------------------
>
> Key: WFLY-13162
> URL: https://issues.redhat.com/browse/WFLY-13162
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 18.0.1.Final, 19.0.0.Beta3, 20.0.0.Beta1
> Reporter: Hielke Hoeve
> Assignee: Cheng Fang
> Priority: Major
>
> Because of a thread unsafe construction in WildFlyJobXmlResolver I am experiencing ConcurrentModificationExceptions while starting my EAR every so often. This is because every EJB of the EAR is processed by WildFlyJobXmlResolver in paralel threads. Even if it has no jbatch dependency or dependency to a EJB which does.
> This is not reproducable for every startup as it depends on the performance of the host machine, number of ejbs in ear, number of threads and thread timing.
> I have created an example project representing our project setup with which I am able to reproduce the issue using a default wildfly build. This test project contains 1 EJB with jbatch, a number of plain EJBs, a WAR which uses the jbatch EJB and an EAR.
> See below for the exception stacktrace.
> I have made a small fix for this issue @ https://github.com/hielkehoeve/wildfly/commit/82047233621c3e5bdbd45333ca4.... The example test project can also be found there.
> {code:java}
> 08:32:30,164 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."project.ear"."project-d.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project.ear"."project-d.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "project-d.jar" of deployment "project.ear"
> at org.jboss.as.server@10.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.util.ConcurrentModificationException
> at java.base/java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:719)
> at java.base/java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:741)
> at java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.merge(WildFlyJobXmlResolver.java:261)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:127)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentProcessor.deploy(BatchEnvironmentProcessor.java:78)
> at org.jboss.as.server@10.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> ... 8 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-9641) Cluster EJB can not work with "-b 0.0.0.0"
by Aliaksei Makarevich (Jira)
[ https://issues.redhat.com/browse/WFLY-9641?page=com.atlassian.jira.plugin... ]
Aliaksei Makarevich commented on WFLY-9641:
-------------------------------------------
[~gregoryhall994]
Some information about configuration found here https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... - the same solving is in forum thread (client-mapping)
We have keycloak7.0.0-docker-cluster. We changed some cli files and mount them into containers.
As for this case we change tools\cli\proxy.cli -- add line:
/socket-binding-group=standard-sockets/socket-binding=http:write-attribute(name=client-mappings, value=[{destination-address=${jboss.host.name}}])
> Cluster EJB can not work with "-b 0.0.0.0"
> ------------------------------------------
>
> Key: WFLY-9641
> URL: https://issues.redhat.com/browse/WFLY-9641
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Final
> Reporter: Fred Ling
> Priority: Major
> Labels: cluster, ejb, wildfly
>
> The ejb cluster does not work when bind to 0.0.0.0, using --server-config=standalone-full-ha.xml -b 0.0.0.0.
> The ejb client fails to connect to the cluster nodes because it tries to connect to 0.0.0.0.
> For more information please refer to the forum thread.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13162) ConcurrentModificationException in WildFlyJobXmlResolver
by Hielke Hoeve (Jira)
[ https://issues.redhat.com/browse/WFLY-13162?page=com.atlassian.jira.plugi... ]
Hielke Hoeve commented on WFLY-13162:
-------------------------------------
Also tried with Java "1.8.0_181" but still getting the error after a 2 redeploys.
> ConcurrentModificationException in WildFlyJobXmlResolver
> --------------------------------------------------------
>
> Key: WFLY-13162
> URL: https://issues.redhat.com/browse/WFLY-13162
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 18.0.1.Final, 19.0.0.Beta3, 20.0.0.Beta1
> Reporter: Hielke Hoeve
> Assignee: Cheng Fang
> Priority: Major
>
> Because of a thread unsafe construction in WildFlyJobXmlResolver I am experiencing ConcurrentModificationExceptions while starting my EAR every so often. This is because every EJB of the EAR is processed by WildFlyJobXmlResolver in paralel threads. Even if it has no jbatch dependency or dependency to a EJB which does.
> This is not reproducable for every startup as it depends on the performance of the host machine, number of ejbs in ear, number of threads and thread timing.
> I have created an example project representing our project setup with which I am able to reproduce the issue using a default wildfly build. This test project contains 1 EJB with jbatch, a number of plain EJBs, a WAR which uses the jbatch EJB and an EAR.
> See below for the exception stacktrace.
> I have made a small fix for this issue @ https://github.com/hielkehoeve/wildfly/commit/82047233621c3e5bdbd45333ca4.... The example test project can also be found there.
> {code:java}
> 08:32:30,164 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."project.ear"."project-d.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project.ear"."project-d.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "project-d.jar" of deployment "project.ear"
> at org.jboss.as.server@10.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.util.ConcurrentModificationException
> at java.base/java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:719)
> at java.base/java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:741)
> at java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.merge(WildFlyJobXmlResolver.java:261)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:127)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentProcessor.deploy(BatchEnvironmentProcessor.java:78)
> at org.jboss.as.server@10.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> ... 8 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13162) ConcurrentModificationException in WildFlyJobXmlResolver
by Hielke Hoeve (Jira)
[ https://issues.redhat.com/browse/WFLY-13162?page=com.atlassian.jira.plugi... ]
Hielke Hoeve edited comment on WFLY-13162 at 2/28/20 12:59 AM:
---------------------------------------------------------------
Apoligies for not providing that immediately. Note that it takes a around a redeploy or 3 before the error occurs.
I'm running everything on Mac Catalina 10.15.3
Wildfly startup opts:
{code:java}
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED
{code}
mvn --version
{code:java}
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
Java version: 13.0.2, vendor: N/A, runtime: /usr/local/Cellar/openjdk/13.0.2+8_2/libexec/openjdk.jdk/Contents/Home
Default locale: en_NL, platform encoding: UTF-8
OS name: "mac os x", version: "10.15.3", arch: "x86_64", family: "mac"
{code}
java -version
{code:java}
openjdk version "11.0.2" 2019-01-15 LTS
OpenJDK Runtime Environment Zulu11.29+11-CA (build 11.0.2+9-LTS)
OpenJDK 64-Bit Server VM Zulu11.29+11-CA (build 11.0.2+9-LTS, mixed mode)
{code}
was (Author: hielkehoeve):
Apoligies for not providing that immediately.
Wildfly startup opts:
{code:java}
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED
{code}
mvn --version
{code:java}
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
Java version: 13.0.2, vendor: N/A, runtime: /usr/local/Cellar/openjdk/13.0.2+8_2/libexec/openjdk.jdk/Contents/Home
Default locale: en_NL, platform encoding: UTF-8
OS name: "mac os x", version: "10.15.3", arch: "x86_64", family: "mac"
{code}
java -version
{code:java}
openjdk version "11.0.2" 2019-01-15 LTS
OpenJDK Runtime Environment Zulu11.29+11-CA (build 11.0.2+9-LTS)
OpenJDK 64-Bit Server VM Zulu11.29+11-CA (build 11.0.2+9-LTS, mixed mode)
{code}
> ConcurrentModificationException in WildFlyJobXmlResolver
> --------------------------------------------------------
>
> Key: WFLY-13162
> URL: https://issues.redhat.com/browse/WFLY-13162
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 18.0.1.Final, 19.0.0.Beta3, 20.0.0.Beta1
> Reporter: Hielke Hoeve
> Assignee: Cheng Fang
> Priority: Major
>
> Because of a thread unsafe construction in WildFlyJobXmlResolver I am experiencing ConcurrentModificationExceptions while starting my EAR every so often. This is because every EJB of the EAR is processed by WildFlyJobXmlResolver in paralel threads. Even if it has no jbatch dependency or dependency to a EJB which does.
> This is not reproducable for every startup as it depends on the performance of the host machine, number of ejbs in ear, number of threads and thread timing.
> I have created an example project representing our project setup with which I am able to reproduce the issue using a default wildfly build. This test project contains 1 EJB with jbatch, a number of plain EJBs, a WAR which uses the jbatch EJB and an EAR.
> See below for the exception stacktrace.
> I have made a small fix for this issue @ https://github.com/hielkehoeve/wildfly/commit/82047233621c3e5bdbd45333ca4.... The example test project can also be found there.
> {code:java}
> 08:32:30,164 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."project.ear"."project-d.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project.ear"."project-d.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "project-d.jar" of deployment "project.ear"
> at org.jboss.as.server@10.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.util.ConcurrentModificationException
> at java.base/java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:719)
> at java.base/java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:741)
> at java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.merge(WildFlyJobXmlResolver.java:261)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:127)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentProcessor.deploy(BatchEnvironmentProcessor.java:78)
> at org.jboss.as.server@10.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> ... 8 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13162) ConcurrentModificationException in WildFlyJobXmlResolver
by Hielke Hoeve (Jira)
[ https://issues.redhat.com/browse/WFLY-13162?page=com.atlassian.jira.plugi... ]
Hielke Hoeve commented on WFLY-13162:
-------------------------------------
Apoligies for not providing that immediately.
Wildfly startup opts:
{code:java}
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED
{code}
mvn --version
{code:java}
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
Java version: 13.0.2, vendor: N/A, runtime: /usr/local/Cellar/openjdk/13.0.2+8_2/libexec/openjdk.jdk/Contents/Home
Default locale: en_NL, platform encoding: UTF-8
OS name: "mac os x", version: "10.15.3", arch: "x86_64", family: "mac"
{code}
java -version
{code:java}
openjdk version "11.0.2" 2019-01-15 LTS
OpenJDK Runtime Environment Zulu11.29+11-CA (build 11.0.2+9-LTS)
OpenJDK 64-Bit Server VM Zulu11.29+11-CA (build 11.0.2+9-LTS, mixed mode)
{code}
> ConcurrentModificationException in WildFlyJobXmlResolver
> --------------------------------------------------------
>
> Key: WFLY-13162
> URL: https://issues.redhat.com/browse/WFLY-13162
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 18.0.1.Final, 19.0.0.Beta3, 20.0.0.Beta1
> Reporter: Hielke Hoeve
> Assignee: Cheng Fang
> Priority: Major
>
> Because of a thread unsafe construction in WildFlyJobXmlResolver I am experiencing ConcurrentModificationExceptions while starting my EAR every so often. This is because every EJB of the EAR is processed by WildFlyJobXmlResolver in paralel threads. Even if it has no jbatch dependency or dependency to a EJB which does.
> This is not reproducable for every startup as it depends on the performance of the host machine, number of ejbs in ear, number of threads and thread timing.
> I have created an example project representing our project setup with which I am able to reproduce the issue using a default wildfly build. This test project contains 1 EJB with jbatch, a number of plain EJBs, a WAR which uses the jbatch EJB and an EAR.
> See below for the exception stacktrace.
> I have made a small fix for this issue @ https://github.com/hielkehoeve/wildfly/commit/82047233621c3e5bdbd45333ca4.... The example test project can also be found there.
> {code:java}
> 08:32:30,164 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."project.ear"."project-d.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project.ear"."project-d.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "project-d.jar" of deployment "project.ear"
> at org.jboss.as.server@10.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.util.ConcurrentModificationException
> at java.base/java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:719)
> at java.base/java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:741)
> at java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.merge(WildFlyJobXmlResolver.java:261)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:127)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentProcessor.deploy(BatchEnvironmentProcessor.java:78)
> at org.jboss.as.server@10.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> ... 8 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13162) ConcurrentModificationException in WildFlyJobXmlResolver
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13162?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13162:
-----------------------------------
[~hielkehoeve] thanks for reporting. I tried your reproducer test (repeating deploy operation many times), but couldn't reproduce the error. I was running with java version "1.8.0_181" on Mac. Can you share your detailed environment?
> ConcurrentModificationException in WildFlyJobXmlResolver
> --------------------------------------------------------
>
> Key: WFLY-13162
> URL: https://issues.redhat.com/browse/WFLY-13162
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 18.0.1.Final, 19.0.0.Beta3, 20.0.0.Beta1
> Reporter: Hielke Hoeve
> Assignee: Cheng Fang
> Priority: Major
>
> Because of a thread unsafe construction in WildFlyJobXmlResolver I am experiencing ConcurrentModificationExceptions while starting my EAR every so often. This is because every EJB of the EAR is processed by WildFlyJobXmlResolver in paralel threads. Even if it has no jbatch dependency or dependency to a EJB which does.
> This is not reproducable for every startup as it depends on the performance of the host machine, number of ejbs in ear, number of threads and thread timing.
> I have created an example project representing our project setup with which I am able to reproduce the issue using a default wildfly build. This test project contains 1 EJB with jbatch, a number of plain EJBs, a WAR which uses the jbatch EJB and an EAR.
> See below for the exception stacktrace.
> I have made a small fix for this issue @ https://github.com/hielkehoeve/wildfly/commit/82047233621c3e5bdbd45333ca4.... The example test project can also be found there.
> {code:java}
> 08:32:30,164 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."project.ear"."project-d.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project.ear"."project-d.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "project-d.jar" of deployment "project.ear"
> at org.jboss.as.server@10.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.util.ConcurrentModificationException
> at java.base/java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:719)
> at java.base/java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:741)
> at java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.merge(WildFlyJobXmlResolver.java:261)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:127)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentProcessor.deploy(BatchEnvironmentProcessor.java:78)
> at org.jboss.as.server@10.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> ... 8 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-5051) Mvel type coercion and rounding behavior compatibility between mvel 2.2.8 and 2.4.3
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5051?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi commented on DROOLS-5051:
-------------------------------------------
Note: After consuming the new version of mvel, let Jenkins run the 3 tests https://github.com/kiegroup/drools/pull/2766 . After confirming those tests pass, we can close this JIRA.
> Mvel type coercion and rounding behavior compatibility between mvel 2.2.8 and 2.4.3
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-5051
> URL: https://issues.redhat.com/browse/DROOLS-5051
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.33.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
> Labels: support
>
> I have rule like as:
> =========
> rule "My Rule"
> no-loop true
> dialect "mvel"
> when
> $info : MyInfo()
> then
> modify ($info) {
> setResult(15 * Math.round( new BigDecimal("49.4") ) / 100 )
> }
> end
> =========
> If I execute this rule in BRMS 6.4.x release (mvel 2.2.8), I will get 7.35 in the response . But if I execute same rule in RHDM 7.4.+ release (mvel 2.4.3) I will 7 in the response.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months