Re: Deadlock issue
Jacopo Cappellato <[email protected]>
| Newsgroups | gmane.comp.web.freemarker.user |
|---|---|
| Message-ID | <[email protected]> |
Hi Daniel,
On Apr 20, 2012, at 2:21 PM, Daniel Dekany wrote:
> Friday, April 20, 2012, 10:37:52 AM, Jacopo Cappellato wrote:
>
>> Daniel D., Daniel L.,
>>
>> thanks to both of you for the valuable help.
>>
>> I was able to find and fix the OFBiz code that was causing the
>> multiple reload of Groovy related classes: in OFBiz there was cache
>> object containing the parsed Groovy scripts that was not managed in
>> a thread safe way.
>
> So then can it still occur that a Groovy-script-class is reloaded even
> if the script wasn't modified, only not so often?
It should no more happen now: the OFBiz cache object is now properly synchronized and even if multiple threads will try to compile the same script only the first Groovy-script-class will be added to the cache and then used to renderthe freemarker template.
After this change all "reload" messages from freemarker disappeared.
>
>> This is now fixed and now Freemarker doesn't reload them. This is a
>> good step ahead but I suspect there is something else to fix (the
>> logs in the production server were different) but for now we will
>> deploy these fixes and we will continue the research. Can I keep you
>> updated with what is going on? Or I am bothering you?
>
> Of course keep us informed.
>
> Regarding those log messages... Same ClassLoader and same class name,
> but not the same class objects, most certainly. That would be visible
> with System.identityHashCode(clazz) BTW.
Thanks!
Jacopo
>
>> Thanks,
>>
>> Jacopo
>>
>> On Apr 20, 2012, at 8:55 AM, Daniel López wrote:
>>
>>> Hi,
>>>
>>> Could it be that for some reason the ScriptEngine object you are using
>>> to load the Groovy Scripts is being re-created? That would imply
>>> re-compiling the scripts and creating new versions of the equivalent
>>> classes, even though the resulting .class would be the same each time.
>>>
>>> That would be odd, as you would have probably noticed by the huge drop
>>> in performance, but that would explain why the classes are being
>>> considered "new", so you might want to check it out to discard a bug in
>>> there.
>>>
>>> S!
>>> D.
>>>
>>>
>>> El 20/04/2012 8:32, Jacopo Cappellato escribió:
>>>>
>>>> On Apr 19, 2012, at 11:28 PM, Daniel Dekany wrote:
>>>>
>>>>>> Yes they are the data preparation scripts for the templates and are
>>>>>> all Groovy scripts; an example of an OFBiz screen declaration is the following:
>>>>>>
>>>>>> <screen name="MicroCart">
>>>>>> <section>
>>>>>> <actions>
>>>>>> <script
>>>>>> location="component://somecomponent/webapp/somecomponent/WEB-INF/actions/ShoppingCartReadHelper.groovy"/>
>>>>>> </actions>
>>>>>> <widgets>
>>>>>> <platform-specific><html><html-template
>>>>>> location="component://somecomponent/webapp/somecomponent/cart/MicroCart.ftl"/></html></platform-specific>
>>>>>> </widgets>
>>>>>> </section>
>>>>>> </screen>
>>>>>>
>>>>>> And the same groovy scripts or ftl templates are reused by
>>>>>> different screen definitions in different webapplications.
>>>>>
>>>>> Are these loaded from a common jar file (and I don't mean the copies
>>>>> of the same jar, but a single file)? If they are, FreeMarker should
>>>>> not face multiple versions of the same class, and you shouldn't have
>>>>> this problem. (Unless there's something special in how Groovy scripts
>>>>> are loaded...)
>>>>>
>>>>
>>>> The screen definition, the Groovy script and the Freemarker template are unique in the classpath: we do not wrap them into a jar file but they are loaded by the OFbiz framework from the filesystem and cached in memory.
>>>> I have added the following debug line to BeansWrapper.introspectClassInternal:
>>>>
>>>> if(logger.isInfoEnabled())
>>>> {
>>>> logger.info("Detected a reloaded class [" + className +
>>>> "]. Clearing BeansWrapper caches.");
>>>> logger.info(" Class [" + clazz + "], Class name [" + clazz.getName() + "], Classloader [" + clazz.getClassLoader() + "]."); // NEW DEBUG STATEMENT
>>>> }
>>>>
>>>> and I got the following output:
>>>>
>>>> 2012-04-20 08:21:12,504 (http-0.0.0.0-8080-97) [ Log4JLoggerFactory.java:101:INFO ] Detected a reloaded class [ShoppingCartReadHelper$_run_closure2]. Clearing BeansWrapper caches.
>>>> 2012-04-20 08:21:12,504 (http-0.0.0.0-8080-97) [ Log4JLoggerFactory.java:101:INFO ] Class [class ShoppingCartReadHelper$_run_closure2], Class name [ShoppingCartReadHelper$_run_closure2], Classloader [groovy.lang.GroovyClassLoader$InnerLoader@43d4db73].
>>>> 2012-04-20 08:21:12,561 (http-0.0.0.0-8080-97) [ Log4JLoggerFactory.java:101:INFO ] Detected a reloaded class [ShoppingCartReadHelper$_run_closure1]. Clearing BeansWrapper caches.
>>>> 2012-04-20 08:21:12,562 (http-0.0.0.0-8080-97) [ Log4JLoggerFactory.java:101:INFO ] Class [class ShoppingCartReadHelper$_run_closure1], Class name [ShoppingCartReadHelper$_run_closure1], Classloader [groovy.lang.GroovyClassLoader$InnerLoader@43d4db73].
>>>> 2012-04-20 08:21:26,407 (http-0.0.0.0-8080-97) [ Log4JLoggerFactory.java:101:INFO ] Detected a reloaded class [ShoppingCartReadHelper$_run_closure3]. Clearing BeansWrapper caches.
>>>> 2012-04-20 08:21:26,408 (http-0.0.0.0-8080-97) [ Log4JLoggerFactory.java:101:INFO ] Class [class ShoppingCartReadHelper$_run_closure3], Class name [ShoppingCartReadHelper$_run_closure3], Classloader [groovy.lang.GroovyClassLoader$InnerLoader@43d4db73].
>>>> 2012-04-20 08:21:28,906 (http-0.0.0.0-8080-97) [ Log4JLoggerFactory.java:101:INFO ] Detected a reloaded class [ShoppingCartReadHelper$_run_closure1]. Clearing BeansWrapper caches.
>>>> 2012-04-20 08:21:28,906 (http-0.0.0.0-8080-97) [ Log4JLoggerFactory.java:101:INFO ] Class [class ShoppingCartReadHelper$_run_closure1], Class name [ShoppingCartReadHelper$_run_closure1], Classloader [groovy.lang.GroovyClassLoader$InnerLoader@43d4db73].
>>>>
>>>> Kind regards,
>>>>
>>>> Jacopo
>>>>
>>>>> --
>>>>> Best regards,
>>>>> Daniel Dekany
>>>
>>> ------------------------------------------------------------------------------
>>> For Developers, A Lot Can Happen In A Second.
>>> Boundary is the first to Know...and Tell You.
>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>> _______________________________________________
>>> FreeMarker-user mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>>
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> FreeMarker-user mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>>
>
> --
> Best regards,
> Daniel Dekany
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> FreeMarker-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2