[
https://issues.apache.org/jira/browse/GROOVY-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006630#comment-16006630
]
Paul King commented on GROOVY-7535:
-----------------------------------
I haven't had time to explore this issue, but just a meta-comment. Do we
believe the applied PR fixed something or nothing? If nothing, I'd re-open and
remove the fix version; otherwise, I'd leave this one as is so that the fix
version for whatever was fixed is tracked and I'd clone the issue and describe
what remains to be fixed (if not exactly as per the current description).
> 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: 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)
