[JBoss JIRA] (WFLY-2496) Concurrent access to ModuleSpecification causes race condition
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-2496?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger updated WFLY-2496:
----------------------------------
Priority: Blocker (was: Critical)
> Concurrent access to ModuleSpecification causes race condition
> --------------------------------------------------------------
>
> Key: WFLY-2496
> URL: https://issues.jboss.org/browse/WFLY-2496
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.0.0.Beta1
> Reporter: Jozef Hartinger
> Assignee: Jason Greene
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> [ModuleSpecification|https://github.com/wildfly/wildfly/blob/master/server...] does not use any form of synchronization to protect its mutable state yet may be used from multiple threads in multi-module deployment when a DeploymentUnitProcessor touches ModuleSpecification of a different deployment unit which is processed at that moment.
> Here is an example of such access: https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/jav...
> Here's how I think this problem manifests:
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createDependencies(ModuleSpecProcessor.java:284) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createModuleService(ModuleSpecProcessor.java:220) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deployModuleSpec(ModuleSpecProcessor.java:125) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deploy(ModuleSpecProcessor.java:88) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 5 more
> {noformat}
> and here's my attempt to verify concurrent access by changing the code slightly to deadlock on concurrent access:
> {noformat}
> "MSC service thread 1-6":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000f742ba28> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> at org.jboss.as.server.deployment.module.ModuleSpecification.foo(ModuleSpecification.java:170)
> at org.jboss.as.server.deployment.module.ModuleSpecification.addSystemDependency(ModuleSpecification.java:121)
> at org.jboss.as.jsf.deployment.JSFDependencyProcessor.addJSFAPI(JSFDependencyProcessor.java:115)
> at org.jboss.as.jsf.deployment.JSFDependencyProcessor.deploy(JSFDependencyProcessor.java:93)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
> - locked <0x00000000f69a8e88> (a org.jboss.as.server.deployment.DeploymentUnitPhaseService)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> "MSC service thread 1-3":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000f742ba58> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> at org.jboss.as.server.deployment.module.ModuleSpecification.foo(ModuleSpecification.java:175)
> at org.jboss.as.server.deployment.module.ModuleSpecification.addSystemDependency(ModuleSpecification.java:121)
> at org.jboss.as.jsf.deployment.JSFDependencyProcessor.addJSFAPI(JSFDependencyProcessor.java:115)
> at org.jboss.as.jsf.deployment.JSFDependencyProcessor.deploy(JSFDependencyProcessor.java:93)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
> - locked <0x00000000f6782960> (a org.jboss.as.server.deployment.DeploymentUnitPhaseService)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (JGRP-1762) Util.loadClass(): do we use the correct ClassLoader ?
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1762?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1762.
----------------------------
Resolution: Done
Changed the order: trying the defining classloader first, then the TCCL.
> Util.loadClass(): do we use the correct ClassLoader ?
> -----------------------------------------------------
>
> Key: JGRP-1762
> URL: https://issues.jboss.org/browse/JGRP-1762
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4.2, 3.5
>
>
> Investigate whether the code below uses the right classloader. Perhaps we should try to get the classloader of the instances passed to us *before* attempting to use the calling thread's class loader ?
> The current code is:
> {noformat}
> public static Class loadClass(String classname, Class clazz) throws ClassNotFoundException {
> ClassLoader loader;
> try {
> loader=Thread.currentThread().getContextClassLoader();
> if(loader != null) {
> return loader.loadClass(classname);
> }
> }
> catch(Throwable t) {
> }
> if(clazz != null) {
> try {
> loader=clazz.getClassLoader();
> if(loader != null) {
> return loader.loadClass(classname);
> }
> }
> catch(Throwable t) {
> }
> }
> try {
> loader=ClassLoader.getSystemClassLoader();
> if(loader != null) {
> return loader.loadClass(classname);
> }
> }
> catch(Throwable t) {
> }
> throw new ClassNotFoundException(classname);
> }
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (JGRP-1759) BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1759?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1759:
--------------------------------
Are you sure the rule file is found and the agent loaded correctly for that specific test ? The byteman rule is indeed *supposed to reorder threads* !
> BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks
> ----------------------------------------------------------------
>
> Key: JGRP-1759
> URL: https://issues.jboss.org/browse/JGRP-1759
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Environment: Windows 2008, x86_64
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Running the Byteman tests in the QA lab, this test deadlocks in a repeatable fashion and causes the testsuite to hang.
> The test makes use of the Byteman rendezvous built-in function to suspend (and reorder) thread execution. It appears that with threads re-ordered, certain parts of JGroups block in such a way that no progress is made and the test deadlocks.
> .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (JGRP-1762) Util.loadClass(): do we use the correct ClassLoader ?
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1762?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1762:
---------------------------
Fix Version/s: 3.4.2
> Util.loadClass(): do we use the correct ClassLoader ?
> -----------------------------------------------------
>
> Key: JGRP-1762
> URL: https://issues.jboss.org/browse/JGRP-1762
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4.2, 3.5
>
>
> Investigate whether the code below uses the right classloader. Perhaps we should try to get the classloader of the instances passed to us *before* attempting to use the calling thread's class loader ?
> The current code is:
> {noformat}
> public static Class loadClass(String classname, Class clazz) throws ClassNotFoundException {
> ClassLoader loader;
> try {
> loader=Thread.currentThread().getContextClassLoader();
> if(loader != null) {
> return loader.loadClass(classname);
> }
> }
> catch(Throwable t) {
> }
> if(clazz != null) {
> try {
> loader=clazz.getClassLoader();
> if(loader != null) {
> return loader.loadClass(classname);
> }
> }
> catch(Throwable t) {
> }
> }
> try {
> loader=ClassLoader.getSystemClassLoader();
> if(loader != null) {
> return loader.loadClass(classname);
> }
> }
> catch(Throwable t) {
> }
> throw new ClassNotFoundException(classname);
> }
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (JGRP-1762) Util.loadClass(): do we use the correct ClassLoader ?
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1762?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1762:
--------------------------------
Comments:
Andre Dietlisheim:
{quote}
>From what I have in mind when packaging libraries to bundles (long time ago, sorry) 1.) will cause havoc to most classpath partitioning frameworks (osgi, jboss modules etc). The code snippet in JGRP-1762 is very likely to fail if bundled. The current thread, your util class and the class you're trying to load may reside in different modules/bundles and visibility rules apply. It is thus is very likely that current thread classloader wont be able to load your class. You should start with 2), the classloader that is accessible via the class you try to load (clazz.getClassLoader() in your snippet).
There are most likely further hints that I have forgotten from those times that others here may come up. Jason Green wrote a nice blog that is describing best practices for module-aware classloading: https://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide
{quote}
Jason Greene:
{quote}
What I can say is the TCCL lookups only make sense if
A) you have a separate API module that discovers a pluggable implementation that the user provides and is discovered lazily during a call from the user's application (e.g. JAXP DOM and STAX)
And
B) You have a reliable convention that says the TCCL will point to something reliable (like a Java EE container which sets it to the deployment)
{quote}
James Livingston:
{quote}
The correct answer is usually "it depends on what is loading the class
and why".
Is it some shared framework code (JGroups here) which is loading an EE
application class passed to it by name? Is it loading a class from a
name passed over the network to deserialise an object that's about to
follow? Something else? The problem with things like your
Util.loadClass() is that you don't know how it's being used so anything
you do will be wrong in some situations.
Often the best thing to do is to have the API take the classloader to
use as a parameter, and push the decision upwards to the caller who
either knows the search order or can push the decision upwards to their
caller.
{quote}
> Util.loadClass(): do we use the correct ClassLoader ?
> -----------------------------------------------------
>
> Key: JGRP-1762
> URL: https://issues.jboss.org/browse/JGRP-1762
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Investigate whether the code below uses the right classloader. Perhaps we should try to get the classloader of the instances passed to us *before* attempting to use the calling thread's class loader ?
> The current code is:
> {noformat}
> public static Class loadClass(String classname, Class clazz) throws ClassNotFoundException {
> ClassLoader loader;
> try {
> loader=Thread.currentThread().getContextClassLoader();
> if(loader != null) {
> return loader.loadClass(classname);
> }
> }
> catch(Throwable t) {
> }
> if(clazz != null) {
> try {
> loader=clazz.getClassLoader();
> if(loader != null) {
> return loader.loadClass(classname);
> }
> }
> catch(Throwable t) {
> }
> }
> try {
> loader=ClassLoader.getSystemClassLoader();
> if(loader != null) {
> return loader.loadClass(classname);
> }
> }
> catch(Throwable t) {
> }
> throw new ClassNotFoundException(classname);
> }
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (JGRP-1755) TP: dropping message to wrong destination in a shared transport
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1755?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1755:
---------------------------
Summary: TP: dropping message to wrong destination in a shared transport (was: TP: dropping message to wrong destination)
> TP: dropping message to wrong destination in a shared transport
> ---------------------------------------------------------------
>
> Key: JGRP-1755
> URL: https://issues.jboss.org/browse/JGRP-1755
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.2, 3.5
>
> Attachments: bla3.java, shared.xml
>
>
> TP has a check whether the dest of incoming unicast messages matches its local address (or the local address in the ProtocolAdapter if a shared transport is used). Messages whose dest != local address are dropped.
> However, in the following scenario, we can have spurious warnings for 2 minutes (by default):
> * 2 processes with 2 members on a shared transport each (see attached shared.xml and bla3.java)
> ** Start 2 bla2 instances on the same box
> * On the second instance, a member leaves and immediately rejoins (press [2] on the second member)
> * For some reason, the leaving member didn't receive the {{LEAVE_RSP}} unicast message from the coordinator (first member)
> * The newly joined member now receives the {{LEAVE_RSP}} unicast from the coordinator, but now it is a different member and therefore has a different local address, so we see the warning
> * This will continue for 2 minutes, until the connection to the unknown member is closed by the coordinator (configurable)
> TODOs:
> * Investigate why the {{LEAVE_RSP}} unicast is not received by the leaving member
> * In the warning, add the sender's address and print the headers of the message so it's easier to find the culprit
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years