[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment
by Sibin Karnavar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ]
Sibin Karnavar edited comment on JGRP-2253 at 5/2/18 6:05 PM:
--------------------------------------------------------------
Looks like I am unable to attach my complete logs. I was getting an error like 'token missing' while uploading my log file.
During Startup:
monitoringInterval: 30000 and queueSizeAlertThreshold: 100
2018-05-02 21:52:16.017 TRACE 1108 --- [jgroups-13,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: who-has-sock ip-10-91-133-143-60500
2018-05-02 21:52:16.021 TRACE 1108 --- [jgroups-13,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received SUSPECT message from ip-10-91-135-48-43121: suspects=[ip-10-91-133-143-60500]
2018-05-02 21:52:16.022 TRACE 1108 --- [jgroups-13,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received SUSPECT message from ip-10-91-135-48-43121: suspects=[ip-10-91-137-163-65450]
2018-05-02 21:52:16.024 TRACE 1108 --- [jgroups-3,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received UNSUSPECT message from ip-10-91-135-48-43121: mbrs=[ip-10-91-133-143-60500]
2018-05-02 21:52:16.025 TRACE 1108 --- [jgroups-4,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received UNSUSPECT message from ip-10-91-135-48-43121: mbrs=[ip-10-91-137-163-65450]
2018-05-02 21:52:16.030 TRACE 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received UNSUSPECT message from ip-10-91-137-163-65450: mbrs=[ip-10-91-133-143-60500]
2018-05-02 21:52:16.030 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - Detected change in view membership: [ip-10-91-137-163-65450|2] (3) [ip-10-91-137-163-65450, ip-10-91-135-48-43121, ip-10-91-133-143-60500]
2018-05-02 21:52:16.030 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - I am not the master!
2018-05-02 21:52:16.031 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - ip-10-91-137-163-65450 is the master for service SOM-SKS
2018-05-02 21:52:16.032 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - Successfully connected to clusterName: 'SOM-SKS-stage_SJX_290420181509_XSJ'
2018-05-02 21:52:16.032 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: got cache from ip-10-91-137-163-65450: cache is ip-10-91-133-143-60500: 10.91.133.143:7804 (0 ms old)
ip-10-91-135-48-43121: 10.91.135.48:7804 (0 ms old)
ip-10-91-137-163-65450: 10.91.137.163:7804 (0 ms old)
2018-05-02 21:52:16.032 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: pinger_thread started
2018-05-02 21:52:16.033 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: pingable_mbrs=[ip-10-91-137-163-65450, ip-10-91-135-48-43121, ip-10-91-133-143-60500], ping_dest=ip-10-91-137-163-65450
2018-05-02 21:52:16.035 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: ping_dest=ip-10-91-137-163-65450, ping_sock=Socket[addr=/10.91.137.163,port=7804,localport=7805], cache=ip-10-91-133-143-60500: 10.91.133.143:7804 (2 ms old)
ip-10-91-135-48-43121: 10.91.135.48:7804 (2 ms old)
ip-10-91-137-163-65450: 10.91.137.163:7804 (2 ms old)
{color:red}Below logs are generated after terminating the master node from AWS console. I have terminated the EC2 instance. This logs are printed only post 13 seconds after killing the other node.{color}
2018-05-02 21:54:40.040 TRACE 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - verifying that [ip-10-91-137-163-65450] is dead
2018-05-02 21:54:43.041 TRACE 1108 --- [VERIFY_SUSPECT.TimerThread-19,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - [ip-10-91-137-163-65450] is dead (passing up SUSPECT event)
2018-05-02 21:54:43.202 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: socket to ip-10-91-137-163-65450 was closed gracefully
2018-05-02 21:54:43.203 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: pingable_mbrs=[ip-10-91-135-48-43121, ip-10-91-133-143-60500], ping_dest=ip-10-91-135-48-43121
2018-05-02 21:54:43.203 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: failed connecting to ip-10-91-135-48-43121: Address already in use (Bind failed)
2018-05-02 21:54:43.203 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: broadcasting suspect(ip-10-91-135-48-43121)
2018-05-02 21:54:43.203 TRACE 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received SUSPECT message from ip-10-91-133-143-60500: suspects=[ip-10-91-135-48-43121]
2018-05-02 21:54:43.204 DEBUG 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: suspecting [ip-10-91-135-48-43121]
2018-05-02 21:54:43.204 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: pinger thread terminated
2018-05-02 21:54:43.206 TRACE 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - verifying that [ip-10-91-135-48-43121] is dead
2018-05-02 21:54:43.208 TRACE 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - member ip-10-91-135-48-43121 was unsuspected
2018-05-02 21:54:43.208 DEBUG 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: broadcasting unsuspect(ip-10-91-135-48-43121)
2018-05-02 21:54:43.208 TRACE 1108 --- [jgroups-18,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received UNSUSPECT message from ip-10-91-133-143-60500: mbrs=[ip-10-91-135-48-43121]
2018-05-02 21:54:43.208 INFO 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] c.w.s.c.ServiceClusterCoordinator : - - Detected change in view membership: [ip-10-91-135-48-43121|3] (2) [ip-10-91-135-48-43121, ip-10-91-133-143-60500]
2018-05-02 21:54:43.209 INFO 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] c.w.s.c.ServiceClusterCoordinator : - - I am not the master!
2018-05-02 21:54:43.209 INFO 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] c.w.s.c.ServiceClusterCoordinator : - - ip-10-91-135-48-43121 is the master for service SOM-SKS
was (Author: sibin.karnavar):
Looks like I am unable to attach my complete logs. I was getting an error like 'token missing' while uploading my log file.
During Startup:
monitoringInterval: 30000 and queueSizeAlertThreshold: 100
2018-05-02 21:52:16.017 TRACE 1108 --- [jgroups-13,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: who-has-sock ip-10-91-133-143-60500
2018-05-02 21:52:16.021 TRACE 1108 --- [jgroups-13,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received SUSPECT message from ip-10-91-135-48-43121: suspects=[ip-10-91-133-143-60500]
2018-05-02 21:52:16.022 TRACE 1108 --- [jgroups-13,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received SUSPECT message from ip-10-91-135-48-43121: suspects=[ip-10-91-137-163-65450]
2018-05-02 21:52:16.024 TRACE 1108 --- [jgroups-3,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received UNSUSPECT message from ip-10-91-135-48-43121: mbrs=[ip-10-91-133-143-60500]
2018-05-02 21:52:16.025 TRACE 1108 --- [jgroups-4,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received UNSUSPECT message from ip-10-91-135-48-43121: mbrs=[ip-10-91-137-163-65450]
2018-05-02 21:52:16.030 TRACE 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received UNSUSPECT message from ip-10-91-137-163-65450: mbrs=[ip-10-91-133-143-60500]
2018-05-02 21:52:16.030 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - Detected change in view membership: [ip-10-91-137-163-65450|2] (3) [ip-10-91-137-163-65450, ip-10-91-135-48-43121, ip-10-91-133-143-60500]
2018-05-02 21:52:16.030 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - I am not the master!
2018-05-02 21:52:16.031 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - ip-10-91-137-163-65450 is the master for service SOM-SKS
2018-05-02 21:52:16.032 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - Successfully connected to clusterName: 'SOM-SKS-stage_SJX_290420181509_XSJ'
2018-05-02 21:52:16.032 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: got cache from ip-10-91-137-163-65450: cache is ip-10-91-133-143-60500: 10.91.133.143:7804 (0 ms old)
ip-10-91-135-48-43121: 10.91.135.48:7804 (0 ms old)
ip-10-91-137-163-65450: 10.91.137.163:7804 (0 ms old)
2018-05-02 21:52:16.032 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: pinger_thread started
2018-05-02 21:52:16.033 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: pingable_mbrs=[ip-10-91-137-163-65450, ip-10-91-135-48-43121, ip-10-91-133-143-60500], ping_dest=ip-10-91-137-163-65450
2018-05-02 21:52:16.035 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: ping_dest=ip-10-91-137-163-65450, ping_sock=Socket[addr=/10.91.137.163,port=7804,localport=7805], cache=ip-10-91-133-143-60500: 10.91.133.143:7804 (2 ms old)
ip-10-91-135-48-43121: 10.91.135.48:7804 (2 ms old)
ip-10-91-137-163-65450: 10.91.137.163:7804 (2 ms old)
{color:red}Below logs is after terminating the master node from AWS console. I have terminated the EC2 instance. This logs are printed only post 13 seconds after killing the other node.{color}
2018-05-02 21:54:40.040 TRACE 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - verifying that [ip-10-91-137-163-65450] is dead
2018-05-02 21:54:43.041 TRACE 1108 --- [VERIFY_SUSPECT.TimerThread-19,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - [ip-10-91-137-163-65450] is dead (passing up SUSPECT event)
2018-05-02 21:54:43.202 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: socket to ip-10-91-137-163-65450 was closed gracefully
2018-05-02 21:54:43.203 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: pingable_mbrs=[ip-10-91-135-48-43121, ip-10-91-133-143-60500], ping_dest=ip-10-91-135-48-43121
2018-05-02 21:54:43.203 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: failed connecting to ip-10-91-135-48-43121: Address already in use (Bind failed)
2018-05-02 21:54:43.203 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: broadcasting suspect(ip-10-91-135-48-43121)
2018-05-02 21:54:43.203 TRACE 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received SUSPECT message from ip-10-91-133-143-60500: suspects=[ip-10-91-135-48-43121]
2018-05-02 21:54:43.204 DEBUG 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: suspecting [ip-10-91-135-48-43121]
2018-05-02 21:54:43.204 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: pinger thread terminated
2018-05-02 21:54:43.206 TRACE 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - verifying that [ip-10-91-135-48-43121] is dead
2018-05-02 21:54:43.208 TRACE 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - member ip-10-91-135-48-43121 was unsuspected
2018-05-02 21:54:43.208 DEBUG 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: broadcasting unsuspect(ip-10-91-135-48-43121)
2018-05-02 21:54:43.208 TRACE 1108 --- [jgroups-18,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received UNSUSPECT message from ip-10-91-133-143-60500: mbrs=[ip-10-91-135-48-43121]
2018-05-02 21:54:43.208 INFO 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] c.w.s.c.ServiceClusterCoordinator : - - Detected change in view membership: [ip-10-91-135-48-43121|3] (2) [ip-10-91-135-48-43121, ip-10-91-133-143-60500]
2018-05-02 21:54:43.209 INFO 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] c.w.s.c.ServiceClusterCoordinator : - - I am not the master!
2018-05-02 21:54:43.209 INFO 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] c.w.s.c.ServiceClusterCoordinator : - - ip-10-91-135-48-43121 is the master for service SOM-SKS
> FD_SOCK is not working in AWS environment
> -----------------------------------------
>
> Key: JGRP-2253
> URL: https://issues.jboss.org/browse/JGRP-2253
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Environment: AWS - EC2
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
> Fix For: 4.0.12
>
>
> We have our failure detection defined like below.
> <FD_SOCK external_port="7804" />
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="3000" />
> Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
> In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK.
> We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
> Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
> Thanks,
> Sibin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (SECURITY-989) org.jboss.security.xacml.core.JBossRequestContext.setRequest needs privileged block
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/SECURITY-989?page=com.atlassian.jira.plug... ]
Stefan Guilhen closed SECURITY-989.
-----------------------------------
Fix Version/s: PicketBox_5_0_3.Final
Resolution: Done
> org.jboss.security.xacml.core.JBossRequestContext.setRequest needs privileged block
> -----------------------------------------------------------------------------------
>
> Key: SECURITY-989
> URL: https://issues.jboss.org/browse/SECURITY-989
> Project: PicketBox
> Issue Type: Bug
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Fix For: PicketBox_5_0_3.Final
>
>
> Need to add privileged block:
> {code}
> 2018-04-09 21:56:27,737 ERROR [org.jboss.as.test.integration.security.xacml.CustomXACMLAuthorizationModule] (pool-8-thread-1) Exception in processing:: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/test-custom-xacml.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.test-custom-xacml.jar" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.Thread.getContextClassLoader(Thread.java:1440)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:416)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:633)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:580)
> at javax.xml.bind.JAXB$Cache.<init>(JAXB.java:87)
> at javax.xml.bind.JAXB.getContext(JAXB.java:114)
> at javax.xml.bind.JAXB._marshal(JAXB.java:534)
> at javax.xml.bind.JAXB.marshal(JAXB.java:407)
> at org.jboss.security.xacml.core.JBossRequestContext.setRequest(JBossRequestContext.java:92)
> at org.jboss.security.authorization.modules.ejb.EJBXACMLUtil.getRequestContext(EJBXACMLUtil.java:154)
> at org.jboss.security.authorization.modules.ejb.EJBXACMLUtil.createXACMLRequest(EJBXACMLUtil.java:122)
> at org.jboss.security.authorization.modules.ejb.EJBXACMLUtil.createXACMLRequest(EJBXACMLUtil.java:66)
> at org.jboss.as.test.integration.security.xacml.CustomXACMLAuthorizationModule.authorizeEJBResource(CustomXACMLAuthorizationModule.java:163)
> at org.jboss.as.test.integration.security.xacml.CustomXACMLAuthorizationModule.authorize(CustomXACMLAuthorizationModule.java:94)
> at org.jboss.security.plugins.authorization.JBossAuthorizationContext.invokeAuthorize(JBossAuthorizationContext.java:227)
> at org.jboss.security.plugins.authorization.JBossAuthorizationContext.access$000(JBossAuthorizationContext.java:71)
> at org.jboss.security.plugins.authorization.JBossAuthorizationContext$1.run(JBossAuthorizationContext.java:147)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.security.plugins.authorization.JBossAuthorizationContext.authorize(JBossAuthorizationContext.java:143)
> at org.jboss.security.plugins.JBossAuthorizationManager.internalAuthorization(JBossAuthorizationManager.java:438)
> at org.jboss.security.plugins.JBossAuthorizationManager.authorize(JBossAuthorizationManager.java:115)
> at org.jboss.security.plugins.javaee.EJBAuthorizationHelper.authorize(EJBAuthorizationHelper.java:318)
> at org.jboss.as.security.service.SimpleSecurityManager.authorize(SimpleSecurityManager.java:268)
> at org.jboss.as.ejb3.security.AuthorizationInterceptor$1.run(AuthorizationInterceptor.java:121)
> at org.jboss.as.ejb3.security.AuthorizationInterceptor$1.run(AuthorizationInterceptor.java:117)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:117)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (DROOLS-2514) Concurrent modification when initialising packages in KnowledgeBuilderImpl
by Max Zerzouri (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2514?page=com.atlassian.jira.plugi... ]
Max Zerzouri edited comment on DROOLS-2514 at 5/2/18 5:02 PM:
--------------------------------------------------------------
It's related in that Java 9 adds an extra sanity check, though the check in Drools' case is triggered due to concurrent modification of the {{HashMap}} across multiple threads, rather than simply within the function passed to {{HashMap.computeIfAbsentIfAbsent}}. The article is a bit misleading in saying that the behaviour changed, since it was always incorrect to rely on any usage that might trigger the {{ConcurrentModificationException}}.
was (Author: max.zerzouri):
It's related in that Java 9 adds an extra sanity check, though the check in Drools' case is triggered due to concurrent modification of the {{HashMap}} across multiple threads, rather than simply within the function passed to {{HashMap.computeIfAbsentIfAbsent}}.
> Concurrent modification when initialising packages in KnowledgeBuilderImpl
> --------------------------------------------------------------------------
>
> Key: DROOLS-2514
> URL: https://issues.jboss.org/browse/DROOLS-2514
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.2.0.Final, 7.3.0.Final, 7.7.0.Final
> Reporter: Max Zerzouri
> Assignee: Mario Fusco
> Attachments: Main.java, main.drl
>
>
> When parallel compilation is enabled, common structures are modified concurrently by {{KnowledgeBuilderImpl.initPackage}}, resulting in the following stack trace in Java 9/10.
> {code:java}
> Exception in thread "main" java.util.ConcurrentModificationException: java.util.ConcurrentModificationException
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:488)
> at java.base/java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:600)
> at java.base/java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:678)
> at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:737)
> at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173)
> at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
> at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRulesLevel(KnowledgeBuilderImpl.java:1238)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:1218)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileKnowledgePackages(KnowledgeBuilderImpl.java:1056)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackage(KnowledgeBuilderImpl.java:1047)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:553)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addKnowledgeResource(KnowledgeBuilderImpl.java:773)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:2360)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:2349)
> at Main.attempt(Main.java:48)
> at Main.main(Main.java:29)
> Caused by: java.util.ConcurrentModificationException
> at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1139)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.initPackage(KnowledgeBuilderImpl.java:1146)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.createPackageRegistry(KnowledgeBuilderImpl.java:1109)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$getOrCreatePackageRegistry$0(KnowledgeBuilderImpl.java:1105)
> at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1751)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.getOrCreatePackageRegistry(KnowledgeBuilderImpl.java:1105)
> at org.drools.compiler.builder.impl.TypeDeclarationCache.createTypeDeclarationForBean(TypeDeclarationCache.java:262)
> at org.drools.compiler.builder.impl.TypeDeclarationCache.getAndRegisterTypeDeclaration(TypeDeclarationCache.java:90)
> at org.drools.compiler.builder.impl.TypeDeclarationBuilder.getAndRegisterTypeDeclaration(TypeDeclarationBuilder.java:69)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.getAndRegisterTypeDeclaration(KnowledgeBuilderImpl.java:1860)
> at org.drools.compiler.rule.builder.PatternBuilder.processClassObjectType(PatternBuilder.java:305)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:181)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:151)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:133)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:105)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1281)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$compileRulesLevel$3(KnowledgeBuilderImpl.java:1242)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1492)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
> at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)
> at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1603)
> at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)
> {code}
> Looking at the code, it looks like additional concurrency-unsafe modifications are performed, since it accesses the mentioned {{HashMap}} to get a shared {{LinkedList}} which it then modifies.
> Note that the stack trace above is obtained on Java 9/10, as JDK9 added the extra check to {{HashMap.computeIfAbsent}}, but the code relies on race conditions in any JDK version.
> Attached a sample Java class source that can trigger the stack trace reliably on my machine (using OpenJDK 10)—should hopefully be reproducible using JDK9/JDK10 as long as the common ForkJoinPool has more than 1 thread.
> Also attached a "drl" file with the rules generated by the sample class (not needed when testing, as the contents are generated by the sample class).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (DROOLS-2514) Concurrent modification when initialising packages in KnowledgeBuilderImpl
by Max Zerzouri (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2514?page=com.atlassian.jira.plugi... ]
Max Zerzouri commented on DROOLS-2514:
--------------------------------------
It's related in that Java 9 adds an extra sanity check, though the check in Drools' case is triggered due to concurrent modification of the {{HashMap}} across multiple threads, rather than simply within the function passed to {{HashMap.computeIfAbsentIfAbsent}}.
> Concurrent modification when initialising packages in KnowledgeBuilderImpl
> --------------------------------------------------------------------------
>
> Key: DROOLS-2514
> URL: https://issues.jboss.org/browse/DROOLS-2514
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.2.0.Final, 7.3.0.Final, 7.7.0.Final
> Reporter: Max Zerzouri
> Assignee: Mario Fusco
> Attachments: Main.java, main.drl
>
>
> When parallel compilation is enabled, common structures are modified concurrently by {{KnowledgeBuilderImpl.initPackage}}, resulting in the following stack trace in Java 9/10.
> {code:java}
> Exception in thread "main" java.util.ConcurrentModificationException: java.util.ConcurrentModificationException
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:488)
> at java.base/java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:600)
> at java.base/java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:678)
> at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:737)
> at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173)
> at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
> at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRulesLevel(KnowledgeBuilderImpl.java:1238)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:1218)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileKnowledgePackages(KnowledgeBuilderImpl.java:1056)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackage(KnowledgeBuilderImpl.java:1047)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:553)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addKnowledgeResource(KnowledgeBuilderImpl.java:773)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:2360)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:2349)
> at Main.attempt(Main.java:48)
> at Main.main(Main.java:29)
> Caused by: java.util.ConcurrentModificationException
> at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1139)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.initPackage(KnowledgeBuilderImpl.java:1146)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.createPackageRegistry(KnowledgeBuilderImpl.java:1109)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$getOrCreatePackageRegistry$0(KnowledgeBuilderImpl.java:1105)
> at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1751)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.getOrCreatePackageRegistry(KnowledgeBuilderImpl.java:1105)
> at org.drools.compiler.builder.impl.TypeDeclarationCache.createTypeDeclarationForBean(TypeDeclarationCache.java:262)
> at org.drools.compiler.builder.impl.TypeDeclarationCache.getAndRegisterTypeDeclaration(TypeDeclarationCache.java:90)
> at org.drools.compiler.builder.impl.TypeDeclarationBuilder.getAndRegisterTypeDeclaration(TypeDeclarationBuilder.java:69)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.getAndRegisterTypeDeclaration(KnowledgeBuilderImpl.java:1860)
> at org.drools.compiler.rule.builder.PatternBuilder.processClassObjectType(PatternBuilder.java:305)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:181)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:151)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:133)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:105)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1281)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$compileRulesLevel$3(KnowledgeBuilderImpl.java:1242)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1492)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
> at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)
> at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1603)
> at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)
> {code}
> Looking at the code, it looks like additional concurrency-unsafe modifications are performed, since it accesses the mentioned {{HashMap}} to get a shared {{LinkedList}} which it then modifies.
> Note that the stack trace above is obtained on Java 9/10, as JDK9 added the extra check to {{HashMap.computeIfAbsent}}, but the code relies on race conditions in any JDK version.
> Attached a sample Java class source that can trigger the stack trace reliably on my machine (using OpenJDK 10)—should hopefully be reproducible using JDK9/JDK10 as long as the common ForkJoinPool has more than 1 thread.
> Also attached a "drl" file with the rules generated by the sample class (not needed when testing, as the contents are generated by the sample class).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-10253) ConcurrentModificationException on startup
by Martin Herschke (JIRA)
[ https://issues.jboss.org/browse/WFLY-10253?page=com.atlassian.jira.plugin... ]
Martin Herschke edited comment on WFLY-10253 at 5/2/18 1:39 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 relevant 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 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.
> 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)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-10253) ConcurrentModificationException on startup
by Martin Herschke (JIRA)
[ https://issues.jboss.org/browse/WFLY-10253?page=com.atlassian.jira.plugin... ]
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)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-10253) ConcurrentModificationException on startup
by Martin Herschke (JIRA)
[ https://issues.jboss.org/browse/WFLY-10253?page=com.atlassian.jira.plugin... ]
Martin Herschke edited comment on WFLY-10253 at 5/2/18 1:32 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. 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 multiple 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}} to 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)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-10253) ConcurrentModificationException on startup
by Martin Herschke (JIRA)
[ https://issues.jboss.org/browse/WFLY-10253?page=com.atlassian.jira.plugin... ]
Martin Herschke edited comment on WFLY-10253 at 5/2/18 1:24 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. 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 multiple 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}} to 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 {{src\main\resources\META-INF\persistence.xml}} file {color:#707070}(in the stated folder){color}. The first one defines multiple 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}} to 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)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-10253) ConcurrentModificationException on startup
by Martin Herschke (JIRA)
[ https://issues.jboss.org/browse/WFLY-10253?page=com.atlassian.jira.plugin... ]
Martin Herschke commented on WFLY-10253:
----------------------------------------
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 {{src\main\resources\META-INF\persistence.xml}} file {color:#707070}(in the stated folder){color}. The first one defines multiple 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}} to 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)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (JBEE-192) Synch with JAX-WS 2.3 api
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JBEE-192?page=com.atlassian.jira.plugin.s... ]
Scott Marlow closed JBEE-192.
-----------------------------
Resolution: Done
Synced on https://github.com/jboss/jboss-jaxws-api_spec/releases/tag/jboss-jaxws-ap..., [~asoldano] gets the credit as he did the work!
> Synch with JAX-WS 2.3 api
> -------------------------
>
> Key: JBEE-192
> URL: https://issues.jboss.org/browse/JBEE-192
> Project: JBoss JavaEE Spec APIs
> Issue Type: Task
> Components: jboss-jaxws-api
> Reporter: Alessio Soldano
> Assignee: Scott Marlow
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
- 1
- 0