[Design of AOP on JBoss (Aspects/JBoss)] - Thread-Safety problems GeneratedClassAdvisor
by jason.greene@jboss.com
While glancing at the AOP code for possible explanations of JBAOP-480, I noticed 2 major thread safety issues in GeneratedClassAdvisor:
Problem #1 is inadequate locking when using ConcurrentHashMap:
| public MethodJoinPointGenerator getJoinPointGenerator(MethodInfo info)
| {
| MethodJoinPointGenerator generator = (MethodJoinPointGenerator)joinPointGenerators.get(info.getJoinpoint());
| if (generator == null)
| {
| generator = new MethodJoinPointGenerator(GeneratedClassAdvisor.this, info);
| initJoinPointGeneratorsMap();
| joinPointGenerators.put(info.getJoinpoint(), generator);
| }
| return generator;
| }
|
There is a race between reading a value in a CHM and inserting one. So, in this case there is a strong possibility of multiple/different join-point generator instances being available to different threads. For this reason CHM has a putIfAbsent() method that should be used instead. If a race occurs a unneeded generator my be created, but it won't be seen by other threads, and gc'd soon.
Problem#2 - Usage of Double-Checked Locking
| protected void initJoinPointGeneratorsMap()
| {
| if (joinPointGenerators == UnmodifiableEmptyCollections.EMPTY_CONCURRENT_HASHMAP)
| {
| lockWrite();
| try
| {
| if (joinPointGenerators == UnmodifiableEmptyCollections.EMPTY_CONCURRENT_HASHMAP)
| {
| joinPointGenerators = new ConcurrentHashMap();
| }
| }
| finally
| {
| unlockWrite();
| }
| }
| }
|
This is a known flawed approach to thread safety.
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl
This can be fixed by marking the joinPointGenerators map as volatile, or changing it to an AtomicReference.
-Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098971#4098971
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098971
18 years, 5 months
[Design of JBoss/Tomcat Integration] - Programmatic configuration of jvmRoute
by bstansberry@jboss.com
JBoss Messaging has introduced a requirement that all nodes in a cluster be given a unique id (see http://jira.jboss.com/jira/browse/JBMESSAGING-1121). Since we now have the requirement I'd like to brainstorm a bit about how that id could be used across all cases in the AS where we want to uniquely identify nodes.
The obvious one that comes to mind is the Tomcat jvmRoute.
For now, let's assume that the JBM unique id is represented by system property "server.peer.id". (Also assume we'll come up a more generic name for the property.)
A simple thing to do would be to hard code the following into the std server.xml:
<Engine name="jboss.web" defaultHost="localhost" jvmRoute="${server.peer.id:0}>
Downside to that is we now dot append the id (or default 0) to every session id, even if we aren't using JK. That's probably no big deal; anyone see a reason why it would be?
If it is a problem, perhaps we could leave the jvmRoute attribute out of server.xml and programatically call Engine.setJvmRoute() if the TomcatDeployer's useJK property is set to true. That seems pretty clunky though.
Note that JBM requires that the id be a non-negative integer.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098951#4098951
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098951
18 years, 5 months