[JBoss JIRA] (WFCORE-2768) There is ConcurrentModificationException when we write new aliases to one credential store resource through multiple threads (management clients)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2768?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2768:
------------------------------------------
This means the OperationStepHandlers for this are not taking the necessary steps to prevent concurrent execution.
Most likely the OSH is doing this
context.getServiceRegistry(false)
when it should be
context.getServiceRegistry(true)
The 'modify' param must be 'true' if the thread will make any sort of modification to any object accessed via that call -- the ServiceRegistry, any ServiceController or other MSC object obtained from it, as well as the Service and the value object read from the ServiceController. In this case the value object being the CredentialStore. The meaning of that 'modify' param *is not limited to modifications to the service registry itself*.
> There is ConcurrentModificationException when we write new aliases to one credential store resource through multiple threads (management clients)
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2768
> URL: https://issues.jboss.org/browse/WFCORE-2768
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Critical
>
> There is ConcurrentModificationException when
> we write new aliases to one credential store resource through multiple threads (management clients)
> *Use case:*
> More users are connected through CLI to same application server and work parallel with same credential store resource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8695) WeldPortableExtensionProcessor does not clear registered Extensions on undeploy()
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8695?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-8695:
---------------------------------
Summary: WeldPortableExtensionProcessor does not clear registered Extensions on undeploy() (was: DUP leaks on undeploy causing WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default)
> WeldPortableExtensionProcessor does not clear registered Extensions on undeploy()
> ----------------------------------------------------------------------------------
>
> Key: WFLY-8695
> URL: https://issues.jboss.org/browse/WFLY-8695
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
>
> {noformat}
> 20:11:08,590 INFO [org.wildfly.clustering.server] (DistributedSingletonService - 1) WFLYCLSV0003: node1 elected as the singleton provider of the jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".installer service
> 20:11:08,594 INFO [org.wildfly.clustering.server] (DistributedSingletonService - 1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".installer service
> 20:11:08,603 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2) ISPN000094: Received new cluster view for channel server: [node1|4] (1) [node1]
> ...
> 20:11:08,794 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 26) WFLYCLINF0002: Started clusterbench-ee7-singleton-jbossall.ear/clusterbench-ee7-ejb.jar cache from ejb container
> 20:11:08,837 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> 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: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default
> at injection point [UnbackedAnnotatedField] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator
> at org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator(ValidationInterceptor.java:0)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:362)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:284)
> at org.jboss.weld.bootstrap.Validator.validateInterceptor(Validator.java:539)
> at org.jboss.weld.bootstrap.ConcurrentValidator$2.doWork(ConcurrentValidator.java:78)
> at org.jboss.weld.bootstrap.ConcurrentValidator$2.doWork(ConcurrentValidator.java:76)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8706) Singleton deployments does not work in domain mode
by Ariel Carrera (JIRA)
[ https://issues.jboss.org/browse/WFLY-8706?page=com.atlassian.jira.plugin.... ]
Ariel Carrera updated WFLY-8706:
--------------------------------
Steps to Reproduce:
1-config a wildfly domain environment
2-config a group with the "ha profile"
3-start server group
4-add a singleton deploment and assign it to the server group
5-enable deployment and check server logs
was:
1-config a wildfly domain environment
2-config a group with the "ha profile"
3-start servers
4-add a singleton deploment and assign to the server group
5-enable deployment and check server logs
> Singleton deployments does not work in domain mode
> --------------------------------------------------
>
> Key: WFLY-8706
> URL: https://issues.jboss.org/browse/WFLY-8706
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Environment: Centos
> Wildfly 10.1.0.Final (two instances and one domain controller)
> Java 8
> Reporter: Ariel Carrera
> Assignee: Paul Ferraro
>
> In a domain mode, when a deployment is a "singleton deployment" (with a singleton- deployment.xml descriptor), it is working fine if the server nodes are started sequently but fails if it is started from domain console.
> When a deployments needs to be updated, a race condition happens and two instances of the deployment are started.
> From logs:
> node1:
> 12:39:48,434 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 133) WFLYCLINF0002: Started default cache from server container
> 12:39:48,436 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0003: node1:one *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
> 12:39:48,440 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
> node2:
> 12:39:48,370 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 122) WFLYCLINF0002: Started default cache from server container
> 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0003: node2:two *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
> 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8706) Singleton deployments does not work in domain mode
by Ariel Carrera (JIRA)
[ https://issues.jboss.org/browse/WFLY-8706?page=com.atlassian.jira.plugin.... ]
Ariel Carrera updated WFLY-8706:
--------------------------------
Description:
In a domain mode, when a deployment is a "singleton deployment" (with a singleton- deployment.xml descriptor), it is working fine if the server nodes are started sequently but fails if it is started from domain console.
When a deployments needs to be updated, a race condition happens and two instances of the deployment are started.
>From logs:
node1:
12:39:48,434 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 133) WFLYCLINF0002: Started default cache from server container
12:39:48,436 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0003: node1:one *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
12:39:48,440 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
node2:
12:39:48,370 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 122) WFLYCLINF0002: Started default cache from server container
12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0003: node2:two *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
was:
In a domain mode, when a deployment is a "singleton deployment" (with a singleton- deployment.xml descriptor), it is working fine if the sever nodes are started sequently but fails if it is started from domain console.
When a deployments needs to be updated, a race condition happens and two instances of the deployment are deployed.
>From logs:
node1:
12:39:48,434 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 133) WFLYCLINF0002: Started default cache from server container
12:39:48,436 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0003: node1:one *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
12:39:48,440 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
node2:
12:39:48,370 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 122) WFLYCLINF0002: Started default cache from server container
12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0003: node2:two *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
> Singleton deployments does not work in domain mode
> --------------------------------------------------
>
> Key: WFLY-8706
> URL: https://issues.jboss.org/browse/WFLY-8706
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Environment: Centos
> Wildfly 10.1.0.Final (two instances and one domain controller)
> Java 8
> Reporter: Ariel Carrera
> Assignee: Paul Ferraro
>
> In a domain mode, when a deployment is a "singleton deployment" (with a singleton- deployment.xml descriptor), it is working fine if the server nodes are started sequently but fails if it is started from domain console.
> When a deployments needs to be updated, a race condition happens and two instances of the deployment are started.
> From logs:
> node1:
> 12:39:48,434 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 133) WFLYCLINF0002: Started default cache from server container
> 12:39:48,436 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0003: node1:one *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
> 12:39:48,440 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
> node2:
> 12:39:48,370 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 122) WFLYCLINF0002: Started default cache from server container
> 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0003: node2:two *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
> 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8706) Singleton deployments does not work in domain mode
by Ariel Carrera (JIRA)
Ariel Carrera created WFLY-8706:
-----------------------------------
Summary: Singleton deployments does not work in domain mode
Key: WFLY-8706
URL: https://issues.jboss.org/browse/WFLY-8706
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.1.0.Final
Environment: Centos
Wildfly 10.1.0.Final (two instances and one domain controller)
Java 8
Reporter: Ariel Carrera
Assignee: Paul Ferraro
In a domain mode, when a deployment is a "singleton deployment" (with a singleton- deployment.xml descriptor), it is working fine if the sever nodes are started sequently but fails if it is started from domain console.
When a deployments needs to be updated, a race condition happens and two instances of the deployment are deployed.
>From logs:
node1:
12:39:48,434 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 133) WFLYCLINF0002: Started default cache from server container
12:39:48,436 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0003: node1:one *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
12:39:48,440 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
node2:
12:39:48,370 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 122) WFLYCLINF0002: Started default cache from server container
12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0003: node2:two *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1136) Simplify SSLCallback to just reference SSLSession
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-1136:
-------------------------------------
Summary: Simplify SSLCallback to just reference SSLSession
Key: ELY-1136
URL: https://issues.jboss.org/browse/ELY-1136
Project: WildFly Elytron
Issue Type: Enhancement
Components: SASL, SSL
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Critical
Fix For: 1.1.0.Beta41
In all places we use this Callback we only access the session anyway.
In the only place we would currently register the factory we only have access to the SSLSession.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years