Grails

initialize not called for domain class referenced in new thread

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 1.2-M4
  • Fix Version/s: 1.2-RC1
  • Component/s: Persistence
  • Labels:
    None
  • Environment:
    OSX 10.6

Description

This looks like a similar issue to http://jira.codehaus.org/browse/GRAILS-1643

I receive the following stacktrace when trying to access a domain object from a different thread (which worked properly in 1.2M3):

java.lang.IllegalStateException: initialize must be called for meta class of class SurveyConnection(class groovy.lang.ExpandoMetaClass) to complete initialisation process before any invocation or field/property access can be done
at groovy.lang.MetaClassImpl.checkInitalised(MetaClassImpl.java:1445)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1511)
at groovy.lang.ExpandoMetaClass.getProperty(ExpandoMetaClass.java:951)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3287)
at groovy.lang.ExpandoMetaClass.getProperty(ExpandoMetaClass.java:964)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassGetPropertySite.getProperty(PogoMetaClassGetPropertySite.java:48)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:237)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetPropertySafe(AbstractCallSite.java:343)
at org.codehaus.groovy.grails.orm.hibernate.support.ClosureEventTriggeringInterceptor.shouldTrigger(ClosureEventTriggeringInterceptor.groovy:100)
at org.codehaus.groovy.grails.orm.hibernate.support.ClosureEventTriggeringInterceptor.this$6$shouldTrigger(ClosureEventTriggeringInterceptor.groovy)
at org.codehaus.groovy.grails.orm.hibernate.support.ClosureEventTriggeringInterceptor$this$6$shouldTrigger.callCurrent(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
at org.codehaus.groovy.grails.orm.hibernate.support.ClosureEventTriggeringInterceptor$this$6$shouldTrigger.callCurrent(Unknown Source)
at org.codehaus.groovy.grails.orm.hibernate.support.ClosureEventTriggeringInterceptor.onPreLoad(ClosureEventTriggeringInterceptor.groovy:117)
at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:148)
at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:877)
at org.hibernate.loader.Loader.doQuery(Loader.java:752)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
at org.hibernate.loader.Loader.doList(Loader.java:2228)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2125)
at org.hibernate.loader.Loader.list(Loader.java:2120)
at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:118)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1596)
at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
at org.codehaus.groovy.grails.orm.hibernate.metaclass.FindByPersistentMethod$1.doInHibernate(FindByPersistentMethod.java:95)
at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:406)
at org.springframework.orm.hibernate3.HibernateTemplate.execute(HibernateTemplate.java:339)
at org.codehaus.groovy.grails.orm.hibernate.metaclass.FindByPersistentMethod.doInvokeInternalWithExpressions(FindByPersistentMethod.java:59)
at org.codehaus.groovy.grails.orm.hibernate.metaclass.AbstractClausedStaticPersistentMethod.doInvokeInternal(AbstractClausedStaticPersistentMethod.java:504)
at org.codehaus.groovy.grails.orm.hibernate.metaclass.AbstractStaticPersistentMethod.invoke(AbstractStaticPersistentMethod.java:56)
at sun.reflect.GeneratedMethodAccessor257.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:133)
at org.codehaus.groovy.grails.plugins.orm.hibernate.HibernatePluginSupport$_addDynamicFinderSupport_closure17.doCall(HibernatePluginSupport.groovy:441)
at sun.reflect.GeneratedMethodAccessor256.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1049)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:923)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:880)
at groovy.lang.Closure.call(Closure.java:279)
at org.codehaus.groovy.runtime.metaclass.ClosureStaticMetaMethod.invoke(ClosureStaticMetaMethod.java:59)
at groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1349)
at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1337)
at groovy.lang.ExpandoMetaClass.invokeStaticMethod(ExpandoMetaClass.java:934)
at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:35)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:40)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at FeatureInstance.inferRotation(FeatureInstance.groovy:30)
at FeatureInstance$inferRotation.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:121)
at Script1.evalScrap(Script1.groovy:8)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1049)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:923)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:880)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:708)
at groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:44)
at groovy.lang.Script.invokeMethod(Script.java:78)
at groovy.lang.GroovyObject$invokeMethod.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
at groovy.lang.GroovyObject$invokeMethod.call(Unknown Source)
at Feature.generateScrapString(Feature.groovy:28)
at sun.reflect.GeneratedMethodAccessor414.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.grails.orm.hibernate.proxy.GroovyAwareJavassistLazyInitializer.invoke(GroovyAwareJavassistLazyInitializer.java:218)
at Feature_$$javassist_19.generateScrapString(Feature$$_javassist_19.java)
at Feature_$$_javassist_19$generateScrapString.call(Unknown Source)
at FeatureInstance.generateScrapString(FeatureInstance.groovy:20)
at FeatureInstance$generateScrapString.call(Unknown Source)
at TherionService.createScrap(TherionService.groovy:343)
at TherionService$createScrap.call(Unknown Source)
at TherionService$_createScraps_closure4.doCall(TherionService.groovy:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1049)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:923)
at groovy.lang.MetaClassImpl.invokePropertyOrMissing(MetaClassImpl.java:1088)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1051)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:923)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:880)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:706)
at TherionJob.invokeMethod(TherionJob.groovy)
at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1114)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1011)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:923)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:880)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:151)
at TherionJob$_call_closure1.doCall(TherionJob.groovy:35)
at sun.reflect.GeneratedMethodAccessor421.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1049)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:923)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:880)
at groovy.lang.Closure.call(Closure.java:279)
at groovy.lang.Closure.call(Closure.java:292)
at groovy.lang.Closure$call$0.call(Unknown Source)
at org.codehaus.groovy.grails.plugins.orm.hibernate.HibernatePluginSupport$_addTransactionalMethods_closure22_closure91.doCall(HibernatePluginSupport.groovy:478)
at sun.reflect.GeneratedMethodAccessor420.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1049)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:923)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:880)
at groovy.lang.Closure.call(Closure.java:279)
at org.codehaus.groovy.runtime.ConvertedClosure.invokeCustom(ConvertedClosure.java:48)
at org.codehaus.groovy.runtime.ConversionHandler.invoke(ConversionHandler.java:77)
at $Proxy12.doInTransaction(Unknown Source)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:128)
at sun.reflect.GeneratedMethodAccessor419.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSite.invoke(PojoMetaMethodSite.java:188)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at org.codehaus.groovy.grails.plugins.orm.hibernate.HibernatePluginSupport$_addTransactionalMethods_closure22.doCall(HibernatePluginSupport.groovy:477)
at sun.reflect.GeneratedMethodAccessor418.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1049)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:923)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:880)
at groovy.lang.Closure.call(Closure.java:279)
at org.codehaus.groovy.runtime.metaclass.ClosureStaticMetaMethod.invoke(ClosureStaticMetaMethod.java:59)
at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite$StaticMetaMethodSiteNoUnwrapNoCoerce.invoke(StaticMetaMethodSite.java:148)
at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.call(StaticMetaMethodSite.java:88)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at TherionJob.call(TherionJob.groovy:34)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:637)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Graeme Rocher added a comment -

Can you attach an example that reproduces the issue?

Show
Graeme Rocher added a comment - Can you attach an example that reproduces the issue?
Hide
Permalink
Sebastian Hohns added a comment -

i noticed this too. In my case it occurs, when i call something like

public String getJsondata(String baseID) {
NewDomainClass b = NewDomainClass.get(baseID)
if(b) {
def resultsJSON = b.mychildren.collect

{ [id:it.id,childvalue:it.childvalue] }

return resultsJSON.encodeAsJSON()
}
}

in a service from a gwt module, but only the first time this method is called. After that everything works without error.

Show
Sebastian Hohns added a comment - i noticed this too. In my case it occurs, when i call something like public String getJsondata(String baseID) { NewDomainClass b = NewDomainClass.get(baseID) if(b) { def resultsJSON = b.mychildren.collect { [id:it.id,childvalue:it.childvalue] } return resultsJSON.encodeAsJSON() } } in a service from a gwt module, but only the first time this method is called. After that everything works without error.
Hide
Permalink
Lari Hotari added a comment -

We've been hit by this problem too. I believe this is caused by this change in Groovy 1.6.5 , GROOVY-3557 . We are getting the error message in the log file of an active production site running on 1.2-M4. 172 errors in the last 12 hours.

Show
Lari Hotari added a comment - We've been hit by this problem too. I believe this is caused by this change in Groovy 1.6.5 , GROOVY-3557 . We are getting the error message in the log file of an active production site running on 1.2-M4. 172 errors in the last 12 hours.
Hide
Permalink
Jochen Theodorou added a comment -

Is it possible to test if the problem appears using groovy 1.6.4? This would efficiently exclude GROOVY-3557 as source of the problem, if the problem disappears.

Show
Jochen Theodorou added a comment - Is it possible to test if the problem appears using groovy 1.6.4? This would efficiently exclude GROOVY-3557 as source of the problem, if the problem disappears.
Hide
Permalink
Lari Hotari added a comment -

I've now restarted our production app by just replacing groovy-all-1.6.5.jar with groovy-all-1.6.4.jar in WEB-INF/lib . No errors by now (it's been only running for 10 minutes now and I'll check again later today). Usually I got some errors quite soon after startup. I assume this problem is caused by the change made in GROOVY-3557 .

Show
Lari Hotari added a comment - I've now restarted our production app by just replacing groovy-all-1.6.5.jar with groovy-all-1.6.4.jar in WEB-INF/lib . No errors by now (it's been only running for 10 minutes now and I'll check again later today). Usually I got some errors quite soon after startup. I assume this problem is caused by the change made in GROOVY-3557 .
Hide
Permalink
Lari Hotari added a comment -

I just checked the log files and there are no errors showing up after switching from groovy 1.6.5 -> 1.6.4 . I'm quite sure that it's caused by Groovy 1.6.5 .

Show
Lari Hotari added a comment - I just checked the log files and there are no errors showing up after switching from groovy 1.6.5 -> 1.6.4 . I'm quite sure that it's caused by Groovy 1.6.5 .
Hide
Permalink
Jochen Theodorou added a comment -

let me try to grasp the situation a bit...

we have one thread calling initialize and another one, doing something with the metaclass. It can't be the same, because then we would not have the problem.

Because before isInitialized() was synchronized a concurrent call to initialize() would have let only one of those two calls work at the same time. If by chance initialize is still in progress while you call isInitialized(), then in 1.6.4 isInitilized() would have had to wait till initilize() is done. initialize() is a method that takes a while, so the situation of the problem occurring is probable.

Now in 1.6.5 initialize() is still synchronized, but not isInitilized(). Instead a volatile is used. If a volatile is used the wait time during initialization is not guaranteed anymore.

If we want to keep this change we have to find out why the MetaClass is used before it is ready.

I strongly assume there is somewhere a place a EMC is registered in a global structure before initialize() is called. This must not happen, because it leads to exactly this problem. Now the question is where this is happening. In Groovy I could not identify such a part of code. Graeme, how about Grails? And then there is also the hibernate part, that could do something bad here.

Show
Jochen Theodorou added a comment - let me try to grasp the situation a bit... we have one thread calling initialize and another one, doing something with the metaclass. It can't be the same, because then we would not have the problem. Because before isInitialized() was synchronized a concurrent call to initialize() would have let only one of those two calls work at the same time. If by chance initialize is still in progress while you call isInitialized(), then in 1.6.4 isInitilized() would have had to wait till initilize() is done. initialize() is a method that takes a while, so the situation of the problem occurring is probable. Now in 1.6.5 initialize() is still synchronized, but not isInitilized(). Instead a volatile is used. If a volatile is used the wait time during initialization is not guaranteed anymore. If we want to keep this change we have to find out why the MetaClass is used before it is ready. I strongly assume there is somewhere a place a EMC is registered in a global structure before initialize() is called. This must not happen, because it leads to exactly this problem. Now the question is where this is happening. In Groovy I could not identify such a part of code. Graeme, how about Grails? And then there is also the hibernate part, that could do something bad here.
Hide
Permalink
Graeme Rocher added a comment -

Well from the stacktrace the error is coming because we create dynamic finders at runtime:

http://github.com/grails/grails/blob/master/grails/src/java/org/codehaus/groovy/grails/plugins/orm/hibernate/HibernatePluginSupport.groovy#L436

I'm not sure at this stage why its reaching a point where its there is an uninitialized EMC. So what you're saying Jochen is if I add code like this to Grails startup. Then we shouldn't see the problem:

   Class[] allClasses = application.getAllClasses();
   if(allClasses != null) {
            for (Class c : allClasses) {
                ExpandoMetaClass emc = new ExpandoMetaClass(c, true, true);
                emc.initialize();
            }
   }

In otherwords make sure all loaded classes have an initialized EMC on application load.

Show
Graeme Rocher added a comment - Well from the stacktrace the error is coming because we create dynamic finders at runtime: http://github.com/grails/grails/blob/master/grails/src/java/org/codehaus/groovy/grails/plugins/orm/hibernate/HibernatePluginSupport.groovy#L436 I'm not sure at this stage why its reaching a point where its there is an uninitialized EMC. So what you're saying Jochen is if I add code like this to Grails startup. Then we shouldn't see the problem: Class [] allClasses = application.getAllClasses(); if (allClasses != null ) { for ( Class c : allClasses) { ExpandoMetaClass emc = new ExpandoMetaClass(c, true , true ); emc.initialize(); } } In otherwords make sure all loaded classes have an initialized EMC on application load.
Hide
Permalink
Jochen Theodorou added a comment -

You HibernatePluginSupport reference reminded me I forgot totally that EMC allows modification after intialize() is called. That means the initialized field is changed later too. So another critical part is when for example methods are added, while the meta class is asked for method invocation and other things. performOperationOnMetaClass is synchronized, but since isInitialized() is no longer synchronized there will be no wait for this being done.

The problem is to find the concurrent call that is causing the problem. If it is initialize(), then your code should work. But I now tend to think the problem is more with modifying EMC. And then your code won't help. Maybe someone being able to reproduce the problem can try your suggestion to see if it helps. That at last would help us to exclude initialize as candidate for the problem.

But regardless that I think we have to do something against the problem during modification.....

Maybe we could use another volatile for this. A boolean indicating a modification operation is currently running and if, then we enter an synchronized block. But since performOperationOnMetaClass is setting initialized to false as one of its first operations I doubt this will do. Another idea would be to change the structures to support making a modification in parallel then it would be safe to invoke an method while we are modifying the structures.

But that would mean almost all of the meta class fields would have to be volatile, which could still lead to problems... No... it would probably better to work with some kind of proxy. That will require some work... undoing the change for GROOVY-3770 would of course be more easy, but that means it will be slower too.

What do you think Graeme?

Show
Jochen Theodorou added a comment - You HibernatePluginSupport reference reminded me I forgot totally that EMC allows modification after intialize() is called. That means the initialized field is changed later too. So another critical part is when for example methods are added, while the meta class is asked for method invocation and other things. performOperationOnMetaClass is synchronized, but since isInitialized() is no longer synchronized there will be no wait for this being done. The problem is to find the concurrent call that is causing the problem. If it is initialize(), then your code should work. But I now tend to think the problem is more with modifying EMC. And then your code won't help. Maybe someone being able to reproduce the problem can try your suggestion to see if it helps. That at last would help us to exclude initialize as candidate for the problem. But regardless that I think we have to do something against the problem during modification..... Maybe we could use another volatile for this. A boolean indicating a modification operation is currently running and if, then we enter an synchronized block. But since performOperationOnMetaClass is setting initialized to false as one of its first operations I doubt this will do. Another idea would be to change the structures to support making a modification in parallel then it would be safe to invoke an method while we are modifying the structures. But that would mean almost all of the meta class fields would have to be volatile, which could still lead to problems... No... it would probably better to work with some kind of proxy. That will require some work... undoing the change for GROOVY-3770 would of course be more easy, but that means it will be slower too. What do you think Graeme?
Hide
Permalink
Graeme Rocher added a comment -

I think the changes are too big to consider and will require extensive testing. I think we should rollback GROOVY-3557, re-open it and plan a review of the code for Groovy 1.7

Show
Graeme Rocher added a comment - I think the changes are too big to consider and will require extensive testing. I think we should rollback GROOVY-3557, re-open it and plan a review of the code for Groovy 1.7
Hide
Permalink
J Pimmel added a comment -

We are also seeing this in both development and WAR deployed environments.. I had tried to roll back the 1.6.5 to 1.6.4 in the grails libdir, but grails just won't start (i tried updating startGrails to use the 1.6.4 jar, but got

java.lang.VerifyError: (class: org/codehaus/gant/GantBinding, method: super$2$invokeMethod signature: (Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object Illegal use of nonvirtual function call
at org.codehaus.groovy.grails.cli.GrailsScriptRunner.callPluginOrGrailsScript(GrailsScriptRunner.java:420)
at org.codehaus.groovy.grails.cli.GrailsScriptRunner.executeCommand(GrailsScriptRunner.java:297)
at org.codehaus.groovy.grails.cli.GrailsScriptRunner.main(GrailsScriptRunner.java:115)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.grails.cli.support.GrailsStarter.rootLoader(GrailsStarter.java:187)
at org.codehaus.groovy.grails.cli.support.GrailsStarter.main(GrailsStarter.java:212)

... So for development purposes (usually under load from webtests) we are getting unreliable behaviour.

Anyway... I will adjust our WAR Events handling to swap 1.6.4 for WAR enivronments, since by the sound of it things work ok when its in a WAR.

Show
J Pimmel added a comment - We are also seeing this in both development and WAR deployed environments.. I had tried to roll back the 1.6.5 to 1.6.4 in the grails libdir, but grails just won't start (i tried updating startGrails to use the 1.6.4 jar, but got java.lang.VerifyError: (class: org/codehaus/gant/GantBinding, method: super$2$invokeMethod signature: (Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object Illegal use of nonvirtual function call at org.codehaus.groovy.grails.cli.GrailsScriptRunner.callPluginOrGrailsScript(GrailsScriptRunner.java:420) at org.codehaus.groovy.grails.cli.GrailsScriptRunner.executeCommand(GrailsScriptRunner.java:297) at org.codehaus.groovy.grails.cli.GrailsScriptRunner.main(GrailsScriptRunner.java:115) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.groovy.grails.cli.support.GrailsStarter.rootLoader(GrailsStarter.java:187) at org.codehaus.groovy.grails.cli.support.GrailsStarter.main(GrailsStarter.java:212) ... So for development purposes (usually under load from webtests) we are getting unreliable behaviour. Anyway... I will adjust our WAR Events handling to swap 1.6.4 for WAR enivronments, since by the sound of it things work ok when its in a WAR.
Hide
Permalink
Graeme Rocher added a comment - - edited

Workaround is to do this in BuildConfig.groovy:

grails.project.dependency.resolution = {
   // inherit Grails' default dependencies
   inherits( "global" ) {
       excludes 'groovy-all'
   }

   dependencies {
               compile("org.codehaus.groovy:groovy-all:1.6.4") {
                       excludes 'jline'
               }
   }

}
Show
Graeme Rocher added a comment - - edited Workaround is to do this in BuildConfig.groovy: grails.project.dependency.resolution = { // inherit Grails' default dependencies inherits( "global" ) { excludes 'groovy-all' } dependencies { compile( "org.codehaus.groovy:groovy-all:1.6.4" ) { excludes 'jline' } } }
Hide
Permalink
Luis Arias added a comment -

I'm still getting hit by this in spite of implementing Graeme's workaround which effectively makes use of the 1.6.4 jar.

Show
Luis Arias added a comment - I'm still getting hit by this in spite of implementing Graeme's workaround which effectively makes use of the 1.6.4 jar.
Hide
Permalink
Graeme Rocher added a comment -

note my workaround only applies to WAR deployments, in run-app you will still get the problem

Show
Graeme Rocher added a comment - note my workaround only applies to WAR deployments, in run-app you will still get the problem
Hide
Permalink
John Fletcher added a comment -

OK here are my results:
Graeme's EMC code posted at 12/Nov/09 07:06 AM, when added to BootStrap.groovy, does not solve the problem.
Graeme's workaround posted at 23/Nov/09 05:18 AM does not solve the problem (even in war deployment).

Note the above tests were done using groovy 1.6.6 (I put that in to solve another current bug).

Replacing groovy-all-1.6.5 with groovy-all-1.6.4 does not solve the problem.

Show
John Fletcher added a comment - OK here are my results: Graeme's EMC code posted at 12/Nov/09 07:06 AM, when added to BootStrap.groovy, does not solve the problem. Graeme's workaround posted at 23/Nov/09 05:18 AM does not solve the problem (even in war deployment). Note the above tests were done using groovy 1.6.6 (I put that in to solve another current bug). Replacing groovy-all-1.6.5 with groovy-all-1.6.4 does not solve the problem.
Hide
Permalink
Graeme Rocher added a comment -

Fixed by http://github.com/grails/grails/commit/70ee45e4db2a63fd859614078d90ed987902faba

Groovy 1.6.7 was required which will be released shortly

Show
Graeme Rocher added a comment - Fixed by http://github.com/grails/grails/commit/70ee45e4db2a63fd859614078d90ed987902faba Groovy 1.6.7 was required which will be released shortly

People

  • Assignee:
    Graeme Rocher
    Reporter:
    Carl Magnuson
Vote (7)
Watch (9)

Dates

  • Created:
    Updated:
    Resolved: