Summary: | some operations on a world do not allow multithreading through the same instance | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Andrew Clement <aclement> |
Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | eric.sirianni, gasttor |
Version: | 1.6.11 | ||
Target Milestone: | 1.6.11 | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Whiteboard: |
Description
Andrew Clement
2011-02-22 11:06:59 EST
I fixed the stack trace here by synchronizing one of the methods involved. However, that got me thinking about type resolution and multiple threads. It could well happen that multiple threads attempt resolution for the same type at the same time - without some care they will both create new ResolvedType objects (different ones for the same thing) and put them into the world. Whichever is last will become the current one but it seems better to avoid building duplicates if we can. To police this I added a synchronized block in resolution around the code that builds new instances. This block won't be hit for resolution cases that find what they are looking for in the typemap cache, it will only be hit if there is a cache miss - so shouldn't cause too much of a problem. I tested this issue with aspectj-DEVELOPMENT-20110221172044.jar and it looks good for me. Currently I could only test it with the sample porgram I posted in the mailing list. Testing this within our spring project would be some effort. thanks for trying it out. let me know if there are issues with your spring setup. This change just made it into 1.6.11.m2 that I built this morning. FYI - I am hitting a similar issue with aspectjweaver-1.6.8. However, I am getting a NullPointerException instead of an IndexOutOfBoundsException. https://jira.springsource.org/browse/SPR-8070 I tried to write a simple multithreaded test to reproduce the issue like Thorsten did but was unsuccessful. Andy - if you have a minute, maybe you can take a peek at SPR-8070 and decide based on eyeballing it if you think it is the same issue. In the meantime, I will try 1.6.11.m2 to see if it fixes our issue. Thanks. I still get the NullPointerException with aspectjweaver-1.6.11 Here are the new line numbers for the stacktrace if that helps. Should I open up a new bug for this or is it OK to piggyback on this one? Caused by: java.lang.NullPointerException: null at org.aspectj.weaver.World.resolve(World.java:278) ~[aspectjweaver.jar:1.6.11] at org.aspectj.weaver.World.resolve(World.java:218) ~[aspectjweaver.jar:1.6.11] at org.aspectj.weaver.World.resolve(World.java:253) ~[aspectjweaver.jar:1.6.11] at org.aspectj.weaver.TypeFactory.createParameterizedType(TypeFactory.java:42) ~[aspectjweaver.jar:1.6.11] at org.aspectj.weaver.reflect.JavaLangTypeToResolvedTypeConverter.fromType(JavaLangTypeToResolvedTypeConverter.java:88) ~[aspectjweaver.jar:1.6.11] at org.aspectj.weaver.reflect.Java15ReflectionBasedReferenceTypeDelegate.getSuperclass(Java15ReflectionBasedReferenceTypeDelegate.java:148) ~[aspectjweaver.jar:1.6.11] at org.aspectj.weaver.ReferenceType.getSuperclass(ReferenceType.java:906) ~[aspectjweaver.jar:1.6.11] at org.aspectj.weaver.patterns.KindedPointcut.fastMatch(KindedPointcut.java:144) ~[aspectjweaver.jar:1.6.11] at org.aspectj.weaver.internal.tools.PointcutExpressionImpl.couldMatchJoinPointsInType(PointcutExpressionImpl.java:82) ~[aspectjweaver.jar:1.6.11] at org.springframework.aop.aspectj.AspectJExpressionPointcut.matches(AspectJExpressionPointcut.java:233) ~[org.springframework.aop.jar:3.0.3.RELEASE] lets open a new bug |