[
https://issues.apache.org/jira/browse/GROOVY-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16012546#comment-16012546
]
Jochen Kemnade commented on GROOVY-7535:
----------------------------------------
It's the other case that makes the difference and that leads to the error, the
one where the other thread sets the value to 0 even though the current thread
is still using a category.
I think John's explanation shows the problem pretty well, so I'll rather show
you another possible way to fix the issue:
{code}
diff --git a/src/main/org/codehaus/groovy/runtime/GroovyCategorySupport.java
b/src/main/org/codehaus/groovy/runtime/GroovyCategorySupport.java
index 4c36935df..42533a5f7 100644
--- a/src/main/org/codehaus/groovy/runtime/GroovyCategorySupport.java
+++ b/src/main/org/codehaus/groovy/runtime/GroovyCategorySupport.java
@@ -72,7 +72,9 @@ public class GroovyCategorySupport {
private Map<String, String> propertySetterMap;
private void newScope () {
+ synchronized(atomicCategoryUsageCounter){
categoriesInUse = atomicCategoryUsageCounter.incrementAndGet();
+ }
DefaultMetaClassInfo.setCategoryUsed(true);
VMPluginFactory.getPlugin().invalidateCallSites();
level++;
@@ -95,7 +97,9 @@ public class GroovyCategorySupport {
}
}
level--;
+ synchronized(atomicCategoryUsageCounter){
categoriesInUse = atomicCategoryUsageCounter.decrementAndGet();
+ }
VMPluginFactory.getPlugin().invalidateCallSites();
if (categoriesInUse==0)
DefaultMetaClassInfo.setCategoryUsed(false);
if (level == 0) {
{code}
This would also fix the problem that the modification of the {{AtomicInteger}}
and the assignment of its current value to the {{int}} field are two separate
steps.
The problem is not that the other thread will not have changed the
{{AtomicInteger}} incorrectly but that it will have assigned an outdated value
to the {{int}} field.
bq. As for The ThreadLocal... well.. try it out. The speed was horrible last
time I tried
yes, I guessed so. Well, if we remove the {{AtomicInteger}} from the PR
version, the will effectively have the same semantics as if we were using a
{{ThreadLocal}}.
> Groovy category throwing MissingMethodException and MissingPropertyException
> when using multiple threads
> --------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-7535
> URL: https://issues.apache.org/jira/browse/GROOVY-7535
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 2.3.11, 2.4.4
> Environment: I have been able to reproduce this issue on a Cent O/S
> version 6.4 with Java 64 Bit JDK 1.8 and groovy 2.4.4.
> Reporter: James Oswald
> Assignee: Pascal Schumacher
> Fix For: 2.4.6
>
> Attachments:
> 0001-GROOVY-7535-fix-race-condition-between-the-modificat.patch,
> CategoryTest.groovy, exceptionForCategoryTest.txt,
> exceptionForTimeCategoryTest.txt, Test.groovy, TimeCategoryTest.groovy
>
>
> When using groovy use block, we randomly get
> groovy.lang.MissingPropertyException when trying to access a property off a
> category. (Attached is an example)
> {quote}
> index 76
> Exception in thread "Thread-77" groovy.lang.MissingPropertyException: No such
> property: millisecond for class: java.lang.Integer
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:51)
> at
> org.codehaus.groovy.runtime.callsite.PojoMetaClassGetPropertySite.callGetProperty(PojoMetaClassGetPropertySite.java:43)
> at
> TimeCategoryTest$__spock_initializeFields_closure1$_closure4$_closure5.doCall(TimeCategoryTest.groovy:23)
> at
> TimeCategoryTest$__spock_initializeFields_closure1$_closure4$_closure5.doCall(TimeCategoryTest.groovy)
> at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:324)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:292)
> at
> groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1016)
> at groovy.lang.Closure.call(Closure.java:423)
> at groovy.lang.Closure.call(Closure.java:417)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:109)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.access$400(GroovyCategorySupport.java:65)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:249)
> at
> org.codehaus.groovy.runtime.DefaultGroovyMethods.use(DefaultGroovyMethods.java:403)
> {quote}
> or groovy.lang.MissingMethodException when trying to access a method from a
> category.
> {quote}
> index 82
> Exception in thread "Thread-207" groovy.lang.MissingMethodException: No
> signature of method: java.lang.String.test() is applicable for argument
> types: (java.lang.String) values: [ bar]
> Possible solutions: next(), toSet(), getAt(java.lang.String), wait(). trim(),
> toList()
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:56)
> at
> org.codehaus.groovy.runtime.callsite.PojoMetaClassSite.call(PojoMetaClassSite.java:46)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:122)
> at
> CategoryTest$__spock_initializeFields_closure1$_closure5.doCall(CategoryTest.groovy:24)
> at
> CategoryTest$__spock_initializeFields_closure1$_closure5.doCall(CategoryTest.groovy)
> at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:324)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:292)
> at
> groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1016)
> at groovy.lang.Closure.call(Closure.java:423)
> at groovy.lang.Closure.call(Closure.java:417)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:109)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.access$400(GroovyCategorySupport.java:65)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:249)
> at
> org.codehaus.groovy.runtime.DefaultGroovyMethods.use(DefaultGroovyMethods.java:403)
> {quote}
> On the server, either one of these exceptions to appear every few days or
> weeks.
> I found a similar issue GROOVY-2105 which contains a test that reproduces
> this problem on Linux. Looking back the fix that was implemented for this
> ticket was to add synchronized to 3 methods. These changes were late removed
> in a refactor of GroovyCategorySupport.
> I have attached 3 test cases that reproduce the threading issue.
> NOTE: problem does not happen 100% of the time as it is a threading and
> timing issue, so you may have to play with the number of threads to generate
> the exception. What I have attached generates the exception on my linux box
> most of the time.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
