Grails › Grails - user

Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Classic

List

Threaded

24 messages Options

Dhanush Gopinath

Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

We are load testing our Grails application hosted on Glassfish 3.1.1 App Server. While testing we are constantly getting thread blocked at ExpandoMetaClass' performOperationOnMetaClass method. The stack trace is given. Is this is a known issue with Grails?

"http-thread-pool-11180(427)" daemon prio=6 tid=0x000000002e1ec800 nid=0x1e90 waiting for monitor entry [0x000000006944c000]

java.lang.Thread.State: BLOCKED (on object monitor)
at groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)
- waiting to lock <0x00000007d1ce8e88> (a groovy.lang.ExpandoMetaClass)
at groovy.lang.ExpandoMetaClass.registerInstanceMethod(ExpandoMetaClass.java:873)
at groovy.lang.ExpandoMetaClass.setProperty(ExpandoMetaClass.java:788)
at org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:179)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:480)
at org.codehaus.groovy.grails.plugins.web.filters.FilterConfig.methodMissing(FilterConfig.groovy:86)
at sun.reflect.GeneratedMethodAccessor336.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:90)
at groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:828)

The stack trace is loneger and eventually starts from org.codehaus.groovy.grails.plugins.web.taglib.SitemeshTagLib.captureTagContent(SitemeshTagLib.groovy). Anybody has come across these errors?

Graeme Rocher-4

Re: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Administrator

What version of Grails?

Cheers

On Fri, Apr 20, 2012 at 8:32 AM, Dhanush Gopinath
<[hidden email]> wrote:

> We are load testing our Grails application hosted on Glassfish 3.1.1 App
> Server. While testing we are constantly getting thread blocked at
> ExpandoMetaClass' performOperationOnMetaClass method. The stack trace is
> given. Is this is a known issue with Grails?
>
> "http-thread-pool-11180(427)" daemon prio=6 tid=0x000000002e1ec800
> nid=0x1e90 waiting for monitor entry [0x000000006944c000]
>
> java.lang.Thread.State: BLOCKED (on object monitor)
> at
> groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)
> - waiting to lock <0x00000007d1ce8e88> (a groovy.lang.ExpandoMetaClass)
> at
> groovy.lang.ExpandoMetaClass.registerInstanceMethod(ExpandoMetaClass.java:873)
> at groovy.lang.ExpandoMetaClass.setProperty(ExpandoMetaClass.java:788)
> at
> org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:179)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:480)
> at
> org.codehaus.groovy.grails.plugins.web.filters.FilterConfig.methodMissing(FilterConfig.groovy:86)
> at sun.reflect.GeneratedMethodAccessor336.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:90)
> at groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:828)
>
> The stack trace is loneger and eventually starts from
> org.codehaus.groovy.grails.plugins.web.taglib.SitemeshTagLib.captureTagContent(SitemeshTagLib.groovy).
> Anybody has come across these errors?
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Thread-Blocking-at-Groovy-ExpandoMetaclass-method-in-a-Grails-App-tp4572990p4572990.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Dhanush Gopinath

Re: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Grails 2.0

Graeme Rocher-4

Re: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Administrator

Can you try 2.0.3?

The problem may be a bug in Grails, but it is hard to tell without the
line numbers matching up.

It seems to be repeatedly attempting to modify the meta class of a
filter, an operation which blocks. A JIRA which reproduces the problem
would help.

Cheers

On Fri, Apr 20, 2012 at 9:35 AM, Dhanush Gopinath
<[hidden email]> wrote:

> Grails 2.0
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Thread-Blocking-at-Groovy-ExpandoMetaclass-method-in-a-Grails-App-tp4572990p4573123.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

Lari Hotari

Re: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

In reply to this post by Dhanush Gopinath

Hi,

Some questions:

- Could you send the full stack trace as a file attachment?
- What kind of Filters does your app contain? (it's interesting since
FilterConfig.methodMissing gets called if the filter closure calls some
method in the app's *Filters class)
- What is the exact Grails version you are using? (Is it 2.0.0, 2.0.1,
2.0.2 or 2.0.3 ?)

It would help a lot if you could provide some test app that reproduces
the problem.

Your problem behaves the same way as
http://jira.grails.org/browse/GRAILS-8050 (but is in different context).
It can be a bug in
org.codehaus.groovy.grails.plugins.web.filters.FilterConfig's
methodMissing method.

Lari

p.s. There is at least one ExpandoMetaClass related performance issue
(that causes blocking) open on Groovy side, but that doesn't seem to be
the issue in this case: https://jira.codehaus.org/browse/GROOVY-5249

20.04.2012 09:32, Dhanush Gopinath wrote:

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Dhanush Gopinath

RE: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

I have attached the full stacktrace. We are using Grails 2.0.0

We have installed Grails Spring Cache plugin which has the filter GrailsFragmentCachingFilter. We also have one filter for our own use of token redirection. We have come across https://jira.codehaus.org/browse/GROOVY-5249 in our earlier load testing and has applied the patch to the latest groovy source. That issue is now not appearing.

Thanks
Dhanush
-----Original Message-----
From: Lari Hotari [mailto:[hidden email]]
Sent: 20 April 2012 14:11
To: [hidden email]
Cc: Gopinath, Dhanush
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

Some questions:

- Could you send the full stack trace as a file attachment?
- What kind of Filters does your app contain? (it's interesting since FilterConfig.methodMissing gets called if the filter closure calls some method in the app's *Filters class)
- What is the exact Grails version you are using? (Is it 2.0.0, 2.0.1,
2.0.2 or 2.0.3 ?)

It would help a lot if you could provide some test app that reproduces the problem.

Your problem behaves the same way as
http://jira.grails.org/browse/GRAILS-8050 (but is in different context).
It can be a bug in
org.codehaus.groovy.grails.plugins.web.filters.FilterConfig's
methodMissing method.

Lari

p.s. There is at least one ExpandoMetaClass related performance issue (that causes blocking) open on Groovy side, but that doesn't seem to be the issue in this case: https://jira.codehaus.org/browse/GROOVY-5249

20.04.2012 09:32, Dhanush Gopinath wrote:

> We are load testing our Grails application hosted on Glassfish 3.1.1
> App Server. While testing we are constantly getting thread blocked at
> ExpandoMetaClass' performOperationOnMetaClass method. The stack trace
> is given. Is this is a known issue with Grails?
>
> "http-thread-pool-11180(427)" daemon prio=6 tid=0x000000002e1ec800
> nid=0x1e90 waiting for monitor entry [0x000000006944c000]
>
> java.lang.Thread.State: BLOCKED (on object monitor)
> at
> groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)
> - waiting to lock <0x00000007d1ce8e88> (a groovy.lang.ExpandoMetaClass)
> at
> groovy.lang.ExpandoMetaClass.registerInstanceMethod(ExpandoMetaClass.java:873)
> at groovy.lang.ExpandoMetaClass.setProperty(ExpandoMetaClass.java:788)
> at
> org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:179)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:480)
> at
> org.codehaus.groovy.grails.plugins.web.filters.FilterConfig.methodMissing(FilterConfig.groovy:86)
> at sun.reflect.GeneratedMethodAccessor336.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:90)
> at
> groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:828)
>
> The stack trace is loneger and eventually starts from
> org.codehaus.groovy.grails.plugins.web.taglib.SitemeshTagLib.captureTagContent(SitemeshTagLib.groovy).
> Anybody has come across these errors?
>
> --
> View this message in context:
> http://grails.1312388.n4.nabble.com/Thread-Blocking-at-Groovy-ExpandoM
> etaclass-method-in-a-Grails-App-tp4572990p4572990.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

stacktrace.txt (23K) Download Attachment

Dhanush Gopinath

Re: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

In reply to this post by Lari Hotari

Lari Hotari

Re: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

In reply to this post by Dhanush Gopinath

Hi,

This seems to be a performance problem in Grails.

I think I found a workaround.

Here is an example (I was trying to reproduce the problem):

class MyFilters {
    def helperMethod(arg1, arg2) {
        "${arg1} ${arg2}!"
    }
    def noArgsMethod() {
       helperMethod("Hi", "there")
    }
    def filters = {
        all(controller:'*', action:'*') {
            before = {
                println thisObject.helperMethod("Hello", "world")
            }
            after = { Map model ->
                println thisObject.noArgsMethod()
            }
            afterView = { Exception e ->

            }
        }
    }
}

You should prefix any helper method call in your Filters class with "thisObject.". Your code has a call to a helper method on #48 in ApplicationFilters (based on the stack trace you sent).

That prevents a method missing call that is handled by the un-optimized solution in FilterConfig:
https://github.com/grails/grails-core/blob/master/grails-plugin-filters/src/main/groovy/org/codehaus/groovy/grails/plugins/web/filters/FilterConfig.groovy#L87

There is some kind of problem in your case that the method missing "caching" doesn't work at all (and that causes the metaclass modification on each call). I just couldn't re-produce the problem yet. I believe the "thisObject." solution circumvents the problem.

It would be nice if you could tell what the line #48 looks like in your ApplicationFilters.groovy .
(from stacktrace:
        at ApplicationFilters$_closure1_closure4_closure5.doCall(ApplicationFilters.groovy:48)
)
That information could help us reproduce the problem and fix it (without using the "thisObject." workaround).

Regards,

Lari

20.04.2012 11:51, Gopinath, Dhanush wrote:

Hi,

I have attached the full stacktrace. We are using Grails 2.0.0

We have installed Grails Spring Cache plugin which has the filter GrailsFragmentCachingFilter. We also have one filter for our own use of token redirection. We have come across https://jira.codehaus.org/browse/GROOVY-5249 in our earlier load testing and has applied the patch to the latest groovy source. That issue is now not appearing.

Thanks 
Dhanush
-----Original Message-----
From: Lari Hotari [[hidden email]] 
Sent: 20 April 2012 14:11
To: [hidden email]
Cc: Gopinath, Dhanush
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

Some questions:

- Could you send the full stack trace as a file attachment?
- What kind of Filters does your app contain? (it's interesting since FilterConfig.methodMissing gets called if the filter closure calls some method in the app's *Filters class)
- What is the exact Grails version you are using? (Is it 2.0.0, 2.0.1,
2.0.2 or 2.0.3 ?)

It would help a lot if you could provide some test app that reproduces the problem.

Your problem behaves the same way as
http://jira.grails.org/browse/GRAILS-8050 (but is in different context).
It can be a bug in
org.codehaus.groovy.grails.plugins.web.filters.FilterConfig's
methodMissing method.

Lari

p.s. There is at least one ExpandoMetaClass related performance issue (that causes blocking) open on Groovy side, but that doesn't seem to be the issue in this case: https://jira.codehaus.org/browse/GROOVY-5249


20.04.2012 09:32, Dhanush Gopinath wrote:

We are load testing our Grails application hosted on Glassfish 3.1.1 
App Server. While testing we are constantly getting thread blocked at 
ExpandoMetaClass' performOperationOnMetaClass method. The stack trace 
is given. Is this is a known issue with Grails?

"http-thread-pool-11180(427)" daemon prio=6 tid=0x000000002e1ec800
nid=0x1e90 waiting for monitor entry [0x000000006944c000]

    java.lang.Thread.State: BLOCKED (on object monitor)
    at
groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)
    - waiting to lock <0x00000007d1ce8e88> (a groovy.lang.ExpandoMetaClass)
    at
groovy.lang.ExpandoMetaClass.registerInstanceMethod(ExpandoMetaClass.java:873)
    at groovy.lang.ExpandoMetaClass.setProperty(ExpandoMetaClass.java:788)
    at
org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:179)
    at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:480)
    at
org.codehaus.groovy.grails.plugins.web.filters.FilterConfig.methodMissing(FilterConfig.groovy:86)
    at sun.reflect.GeneratedMethodAccessor336.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:90)
    at 
groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:828)

The stack trace is loneger and eventually starts from 
org.codehaus.groovy.grails.plugins.web.taglib.SitemeshTagLib.captureTagContent(SitemeshTagLib.groovy).
Anybody has come across these errors?

--
View this message in context: 
http://grails.1312388.n4.nabble.com/Thread-Blocking-at-Groovy-ExpandoM
etaclass-method-in-a-Grails-App-tp4572990p4572990.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Dhanush Gopinath

RE: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

Line no 48 in our ApplicationFilters.groovy calls a helper method

setEditionsInRequest(request, grailsApplication) which is written in the same class.

Thanks

Dhanush

From: Lari Hotari [mailto:[hidden email]]
Sent: 20 April 2012 15:10
To: Gopinath, Dhanush
Cc: [hidden email]
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

I have attached the full stacktrace. We are using Grails 2.0.0

We have installed Grails Spring Cache plugin which has the filter GrailsFragmentCachingFilter. We also have one filter for our own use of token redirection. We have come across https://jira.codehaus.org/browse/GROOVY-5249 in our earlier load testing and has applied the patch to the latest groovy source. That issue is now not appearing.

Thanks

Dhanush

-----Original Message-----

From: Lari Hotari [[hidden email]]

Sent: 20 April 2012 14:11

To: [hidden email]

Cc: Gopinath, Dhanush

Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

Some questions:

- Could you send the full stack trace as a file attachment?

- What kind of Filters does your app contain? (it's interesting since FilterConfig.methodMissing gets called if the filter closure calls some method in the app's *Filters class)

- What is the exact Grails version you are using? (Is it 2.0.0, 2.0.1,

2.0.2 or 2.0.3 ?)

It would help a lot if you could provide some test app that reproduces the problem.

Your problem behaves the same way as

http://jira.grails.org/browse/GRAILS-8050 (but is in different context).

It can be a bug in

org.codehaus.groovy.grails.plugins.web.filters.FilterConfig's

methodMissing method.

Lari

p.s. There is at least one ExpandoMetaClass related performance issue (that causes blocking) open on Groovy side, but that doesn't seem to be the issue in this case: https://jira.codehaus.org/browse/GROOVY-5249

20.04.2012 09:32, Dhanush Gopinath wrote:

We are load testing our Grails application hosted on Glassfish 3.1.1

App Server. While testing we are constantly getting thread blocked at

ExpandoMetaClass' performOperationOnMetaClass method. The stack trace

is given. Is this is a known issue with Grails?

"http-thread-pool-11180(427)" daemon prio=6 tid=0x000000002e1ec800

nid=0x1e90 waiting for monitor entry [0x000000006944c000]

    java.lang.Thread.State: BLOCKED (on object monitor)

at

groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)

    - waiting to lock <0x00000007d1ce8e88> (a groovy.lang.ExpandoMetaClass)

at

groovy.lang.ExpandoMetaClass.registerInstanceMethod(ExpandoMetaClass.java:873)

    at groovy.lang.ExpandoMetaClass.setProperty(ExpandoMetaClass.java:788)

at

org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:179)

at

org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:480)

at

org.codehaus.groovy.grails.plugins.web.filters.FilterConfig.methodMissing(FilterConfig.groovy:86)

    at sun.reflect.GeneratedMethodAccessor336.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:90)

at

groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:828)

The stack trace is loneger and eventually starts from

org.codehaus.groovy.grails.plugins.web.taglib.SitemeshTagLib.captureTagContent(SitemeshTagLib.groovy).

Anybody has come across these errors?

--

View this message in context:

http://grails.1312388.n4.nabble.com/Thread-Blocking-at-Groovy-ExpandoM

etaclass-method-in-a-Grails-App-tp4572990p4572990.html

Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------

To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Graeme Rocher-4

Re: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Administrator

In reply to this post by Dhanush Gopinath

The stack trace seems to indicate it is your own ApplicationFilters class.

Although that doesn't rule out that Spring Cache is impacted as well.
Can you please raise a JIRA for this.

If possible attach an example

Thanks

On Fri, Apr 20, 2012 at 10:51 AM, Gopinath, Dhanush
<[hidden email]> wrote:

> Hi,
>
> I have attached the full stacktrace. We are using Grails 2.0.0
>
> We have installed Grails Spring Cache plugin which has the filter GrailsFragmentCachingFilter. We also have one filter for our own use of token redirection. We have come across https://jira.codehaus.org/browse/GROOVY-5249 in our earlier load testing and has applied the patch to the latest groovy source. That issue is now not appearing.
>
> Thanks
> Dhanush
> -----Original Message-----
> From: Lari Hotari [mailto:[hidden email]]
> Sent: 20 April 2012 14:11
> To: [hidden email]
> Cc: Gopinath, Dhanush
> Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App
>
> Hi,
>
> Some questions:
>
> - Could you send the full stack trace as a file attachment?
> - What kind of Filters does your app contain? (it's interesting since FilterConfig.methodMissing gets called if the filter closure calls some method in the app's *Filters class)
> - What is the exact Grails version you are using? (Is it 2.0.0, 2.0.1,
> 2.0.2 or 2.0.3 ?)
>
> It would help a lot if you could provide some test app that reproduces the problem.
>
> Your problem behaves the same way as
> http://jira.grails.org/browse/GRAILS-8050 (but is in different context).
> It can be a bug in
> org.codehaus.groovy.grails.plugins.web.filters.FilterConfig's
> methodMissing method.
>
> Lari
>
> p.s. There is at least one ExpandoMetaClass related performance issue (that causes blocking) open on Groovy side, but that doesn't seem to be the issue in this case: https://jira.codehaus.org/browse/GROOVY-5249
>
>
> 20.04.2012 09:32, Dhanush Gopinath wrote:
>> We are load testing our Grails application hosted on Glassfish 3.1.1
>> App Server. While testing we are constantly getting thread blocked at
>> ExpandoMetaClass' performOperationOnMetaClass method. The stack trace
>> is given. Is this is a known issue with Grails?
>>
>> "http-thread-pool-11180(427)" daemon prio=6 tid=0x000000002e1ec800
>> nid=0x1e90 waiting for monitor entry [0x000000006944c000]
>>
>> java.lang.Thread.State: BLOCKED (on object monitor)
>> at
>> groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)
>> - waiting to lock <0x00000007d1ce8e88> (a groovy.lang.ExpandoMetaClass)
>> at
>> groovy.lang.ExpandoMetaClass.registerInstanceMethod(ExpandoMetaClass.java:873)
>> at groovy.lang.ExpandoMetaClass.setProperty(ExpandoMetaClass.java:788)
>> at
>> org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:179)
>> at
>> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:480)
>> at
>> org.codehaus.groovy.grails.plugins.web.filters.FilterConfig.methodMissing(FilterConfig.groovy:86)
>> at sun.reflect.GeneratedMethodAccessor336.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:90)
>> at
>> groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:828)
>>
>> The stack trace is loneger and eventually starts from
>> org.codehaus.groovy.grails.plugins.web.taglib.SitemeshTagLib.captureTagContent(SitemeshTagLib.groovy).
>> Anybody has come across these errors?
>>
>> --
>> View this message in context:
>> http://grails.1312388.n4.nabble.com/Thread-Blocking-at-Groovy-ExpandoM
>> etaclass-method-in-a-Grails-App-tp4572990p4572990.html
>> Sent from the Grails - user mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>

Lari Hotari

Re: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

In reply to this post by Dhanush Gopinath

Does it fix the performance problem if you prefix that line with "thisObject." :

thisObject.setEditionsInRequest(request, grailsApplication)

(add "thisObject." prefix to all helper method calls in the ApplicationFilters class's before/after/afterView closures.)

Regards,

Lari

20.04.2012 12:59, Gopinath, Dhanush wrote:

Hi,

Line no 48 in our ApplicationFilters.groovy calls a helper method

setEditionsInRequest(request, grailsApplication) which is written in the same class.

Thanks

Dhanush

From: Lari Hotari [[hidden email]]
Sent: 20 April 2012 15:10
To: Gopinath, Dhanush
Cc: [hidden email]
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

This seems to be a performance problem in Grails.

I think I found a workaround.

Here is an example (I was trying to reproduce the problem):

class MyFilters {
    def helperMethod(arg1, arg2) {
        "${arg1} ${arg2}!"
    }
    def noArgsMethod() {
       helperMethod("Hi", "there")
    }
    def filters = {
        all(controller:'*', action:'*') {
            before = {
                println thisObject.helperMethod("Hello", "world")
            }
            after = { Map model ->
                println thisObject.noArgsMethod()
            }
            afterView = { Exception e ->

            }
        }
    }
}

You should prefix any helper method call in your Filters class with "thisObject.". Your code has a call to a helper method on #48 in ApplicationFilters (based on the stack trace you sent).

That prevents a method missing call that is handled by the un-optimized solution in FilterConfig:
https://github.com/grails/grails-core/blob/master/grails-plugin-filters/src/main/groovy/org/codehaus/groovy/grails/plugins/web/filters/FilterConfig.groovy#L87

There is some kind of problem in your case that the method missing "caching" doesn't work at all (and that causes the metaclass modification on each call). I just couldn't re-produce the problem yet. I believe the "thisObject." solution circumvents the problem.

It would be nice if you could tell what the line #48 looks like in your ApplicationFilters.groovy .
(from stacktrace:
        at ApplicationFilters$_closure1_closure4_closure5.doCall(ApplicationFilters.groovy:48)
)
That information could help us reproduce the problem and fix it (without using the "thisObject." workaround).

Regards,

Lari

20.04.2012 11:51, Gopinath, Dhanush wrote:
Hi,
 
I have attached the full stacktrace. We are using Grails 2.0.0
 
We have installed Grails Spring Cache plugin which has the filter GrailsFragmentCachingFilter. We also have one filter for our own use of token redirection. We have come across https://jira.codehaus.org/browse/GROOVY-5249 in our earlier load testing and has applied the patch to the latest groovy source. That issue is now not appearing.
 
Thanks 
Dhanush
-----Original Message-----
From: Lari Hotari [[hidden email]] 
Sent: 20 April 2012 14:11
To: [hidden email]
Cc: Gopinath, Dhanush
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App
 
Hi,
 
Some questions:
 
- Could you send the full stack trace as a file attachment?
- What kind of Filters does your app contain? (it's interesting since FilterConfig.methodMissing gets called if the filter closure calls some method in the app's *Filters class)
- What is the exact Grails version you are using? (Is it 2.0.0, 2.0.1,
2.0.2 or 2.0.3 ?)
 
It would help a lot if you could provide some test app that reproduces the problem.
 
Your problem behaves the same way as
http://jira.grails.org/browse/GRAILS-8050 (but is in different context).
It can be a bug in
org.codehaus.groovy.grails.plugins.web.filters.FilterConfig's
methodMissing method.
 
Lari
 
p.s. There is at least one ExpandoMetaClass related performance issue (that causes blocking) open on Groovy side, but that doesn't seem to be the issue in this case: https://jira.codehaus.org/browse/GROOVY-5249
 
 
20.04.2012 09:32, Dhanush Gopinath wrote:
We are load testing our Grails application hosted on Glassfish 3.1.1 
App Server. While testing we are constantly getting thread blocked at 
ExpandoMetaClass' performOperationOnMetaClass method. The stack trace 
is given. Is this is a known issue with Grails?
 
"http-thread-pool-11180(427)" daemon prio=6 tid=0x000000002e1ec800
nid=0x1e90 waiting for monitor entry [0x000000006944c000]
 
    java.lang.Thread.State: BLOCKED (on object monitor)
    at
groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)
    - waiting to lock <0x00000007d1ce8e88> (a groovy.lang.ExpandoMetaClass)
    at
groovy.lang.ExpandoMetaClass.registerInstanceMethod(ExpandoMetaClass.java:873)
    at groovy.lang.ExpandoMetaClass.setProperty(ExpandoMetaClass.java:788)
    at
org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:179)
    at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:480)
    at
org.codehaus.groovy.grails.plugins.web.filters.FilterConfig.methodMissing(FilterConfig.groovy:86)
    at sun.reflect.GeneratedMethodAccessor336.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:90)
    at 
groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:828)
 
The stack trace is loneger and eventually starts from 
org.codehaus.groovy.grails.plugins.web.taglib.SitemeshTagLib.captureTagContent(SitemeshTagLib.groovy).
Anybody has come across these errors?
 
--
View this message in context: 
http://grails.1312388.n4.nabble.com/Thread-Blocking-at-Groovy-ExpandoM
etaclass-method-in-a-Grails-App-tp4572990p4572990.html
Sent from the Grails - user mailing list archive at Nabble.com.
 
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
 
    http://xircles.codehaus.org/manage_email
 
 

Lari Hotari

Re: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

I reported this issue in the Jira:
http://jira.grails.org/browse/GRAILS-9044

I was able to reproduce the problem. In my test, "thisObject." prefix fixed the problem.

I'll soon attach a test-app to the issue. Please comment on this issue from now on.

Regards,

Lari

20.04.2012 15:38, Lari Hotari wrote:

Does it fix the performance problem if you prefix that line with "thisObject." :

thisObject.setEditionsInRequest(request, grailsApplication)

(add "thisObject." prefix to all helper method calls in the ApplicationFilters class's before/after/afterView closures.)

Regards,

Lari

20.04.2012 12:59, Gopinath, Dhanush wrote:
Hi,

Line no 48 in our ApplicationFilters.groovy calls a helper method

setEditionsInRequest(request, grailsApplication) which is written in the same class.

Thanks

Dhanush

From: Lari Hotari [[hidden email]]
Sent: 20 April 2012 15:10
To: Gopinath, Dhanush
Cc: [hidden email]
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

This seems to be a performance problem in Grails.

I think I found a workaround.

Here is an example (I was trying to reproduce the problem):

class MyFilters {
    def helperMethod(arg1, arg2) {
        "${arg1} ${arg2}!"
    }
    def noArgsMethod() {
       helperMethod("Hi", "there")
    }
    def filters = {
        all(controller:'*', action:'*') {
            before = {
                println thisObject.helperMethod("Hello", "world")
            }
            after = { Map model ->
                println thisObject.noArgsMethod()
            }
            afterView = { Exception e ->

            }
        }
    }
}

You should prefix any helper method call in your Filters class with "thisObject.". Your code has a call to a helper method on #48 in ApplicationFilters (based on the stack trace you sent).

That prevents a method missing call that is handled by the un-optimized solution in FilterConfig:
https://github.com/grails/grails-core/blob/master/grails-plugin-filters/src/main/groovy/org/codehaus/groovy/grails/plugins/web/filters/FilterConfig.groovy#L87

There is some kind of problem in your case that the method missing "caching" doesn't work at all (and that causes the metaclass modification on each call). I just couldn't re-produce the problem yet. I believe the "thisObject." solution circumvents the problem.

It would be nice if you could tell what the line #48 looks like in your ApplicationFilters.groovy .
(from stacktrace:
        at ApplicationFilters$_closure1_closure4_closure5.doCall(ApplicationFilters.groovy:48)
)
That information could help us reproduce the problem and fix it (without using the "thisObject." workaround).

Regards,

Lari

20.04.2012 11:51, Gopinath, Dhanush wrote:
Hi,
 
I have attached the full stacktrace. We are using Grails 2.0.0
 
We have installed Grails Spring Cache plugin which has the filter GrailsFragmentCachingFilter. We also have one filter for our own use of token redirection. We have come across https://jira.codehaus.org/browse/GROOVY-5249 in our earlier load testing and has applied the patch to the latest groovy source. That issue is now not appearing.
 
Thanks 
Dhanush
-----Original Message-----
From: Lari Hotari [[hidden email]] 
Sent: 20 April 2012 14:11
To: [hidden email]
Cc: Gopinath, Dhanush
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App
 
Hi,
 
Some questions:
 
- Could you send the full stack trace as a file attachment?
- What kind of Filters does your app contain? (it's interesting since FilterConfig.methodMissing gets called if the filter closure calls some method in the app's *Filters class)
- What is the exact Grails version you are using? (Is it 2.0.0, 2.0.1,
2.0.2 or 2.0.3 ?)
 
It would help a lot if you could provide some test app that reproduces the problem.
 
Your problem behaves the same way as
http://jira.grails.org/browse/GRAILS-8050 (but is in different context).
It can be a bug in
org.codehaus.groovy.grails.plugins.web.filters.FilterConfig's
methodMissing method.
 
Lari
 
p.s. There is at least one ExpandoMetaClass related performance issue (that causes blocking) open on Groovy side, but that doesn't seem to be the issue in this case: https://jira.codehaus.org/browse/GROOVY-5249
 
 
20.04.2012 09:32, Dhanush Gopinath wrote:
We are load testing our Grails application hosted on Glassfish 3.1.1 
App Server. While testing we are constantly getting thread blocked at 
ExpandoMetaClass' performOperationOnMetaClass method. The stack trace 
is given. Is this is a known issue with Grails?
 
"http-thread-pool-11180(427)" daemon prio=6 tid=0x000000002e1ec800
nid=0x1e90 waiting for monitor entry [0x000000006944c000]
 
    java.lang.Thread.State: BLOCKED (on object monitor)
    at
groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)
    - waiting to lock <0x00000007d1ce8e88> (a groovy.lang.ExpandoMetaClass)
    at
groovy.lang.ExpandoMetaClass.registerInstanceMethod(ExpandoMetaClass.java:873)
    at groovy.lang.ExpandoMetaClass.setProperty(ExpandoMetaClass.java:788)
    at
org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:179)
    at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:480)
    at
org.codehaus.groovy.grails.plugins.web.filters.FilterConfig.methodMissing(FilterConfig.groovy:86)
    at sun.reflect.GeneratedMethodAccessor336.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:90)
    at 
groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:828)
 
The stack trace is loneger and eventually starts from 
org.codehaus.groovy.grails.plugins.web.taglib.SitemeshTagLib.captureTagContent(SitemeshTagLib.groovy).
Anybody has come across these errors?
 
--
View this message in context: 
http://grails.1312388.n4.nabble.com/Thread-Blocking-at-Groovy-ExpandoM
etaclass-method-in-a-Grails-App-tp4572990p4572990.html
Sent from the Grails - user mailing list archive at Nabble.com.
 
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
 
    http://xircles.codehaus.org/manage_email
 
 

Dhanush Gopinath

RE: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

In reply to this post by Lari Hotari

Yes. It helps. Currently we do not have any Blocking threads. But we are seeing a similar problem in other classes where a local private method is called from inside a closure. But this is not consistent. So my question is does all the methods called from a closure needs to be prefixed with thisObject ?

http-thread-pool-8080(443)" daemon prio=6 tid=0x0000000016dd2000 nid=0x9e0 waiting for monitor entry [0x000000003adda000]
java.lang.Thread.State: BLOCKED (on object monitor)
at groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)
- waiting to lock <0x00000007dee525e8> (a groovy.lang.ExpandoMetaClass)
at groovy.lang.ExpandoMetaClass.addSuperMethodIfNotOverridden(ExpandoMetaClass.java:513)
at groovy.lang.ExpandoMetaClass.onSuperMethodFoundInHierarchy(ExpandoMetaClass.java:394)
at groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:813)
at groovy.lang.MetaClassImpl.invokePropertyOrMissing(MetaClassImpl.java:1120)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1073)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1110)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:901)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:721)
at com.espni.domain.dao.BaseDao.invokeMethod(BaseDao.groovy)
at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1136)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1030)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1110)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:901)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149)
at com.espni.domain.dao.StoryDao$_getStories_closure6.doCall(StoryDao.groovy:298)
at sun.reflect.GeneratedMethodAccessor2596.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:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1071)

From: Lari Hotari [mailto:[hidden email]]
Sent: 20 April 2012 18:08
To: Gopinath, Dhanush
Cc: [hidden email]
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

Line no 48 in our ApplicationFilters.groovy calls a helper method

setEditionsInRequest(request, grailsApplication) which is written in the same class.

Thanks

Dhanush

From: Lari Hotari [[hidden email]]
Sent: 20 April 2012 15:10
To: Gopinath, Dhanush
Cc: [hidden email]
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

I have attached the full stacktrace. We are using Grails 2.0.0

We have installed Grails Spring Cache plugin which has the filter GrailsFragmentCachingFilter. We also have one filter for our own use of token redirection. We have come across https://jira.codehaus.org/browse/GROOVY-5249 in our earlier load testing and has applied the patch to the latest groovy source. That issue is now not appearing.

Thanks

Dhanush

-----Original Message-----

From: Lari Hotari [[hidden email]]

Sent: 20 April 2012 14:11

To: [hidden email]

Cc: Gopinath, Dhanush

Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

Some questions:

- Could you send the full stack trace as a file attachment?

- What kind of Filters does your app contain? (it's interesting since FilterConfig.methodMissing gets called if the filter closure calls some method in the app's *Filters class)

- What is the exact Grails version you are using? (Is it 2.0.0, 2.0.1,

2.0.2 or 2.0.3 ?)

It would help a lot if you could provide some test app that reproduces the problem.

Your problem behaves the same way as

http://jira.grails.org/browse/GRAILS-8050 (but is in different context).

It can be a bug in

org.codehaus.groovy.grails.plugins.web.filters.FilterConfig's

methodMissing method.

Lari

p.s. There is at least one ExpandoMetaClass related performance issue (that causes blocking) open on Groovy side, but that doesn't seem to be the issue in this case: https://jira.codehaus.org/browse/GROOVY-5249

20.04.2012 09:32, Dhanush Gopinath wrote:

We are load testing our Grails application hosted on Glassfish 3.1.1

App Server. While testing we are constantly getting thread blocked at

ExpandoMetaClass' performOperationOnMetaClass method. The stack trace

is given. Is this is a known issue with Grails?

"http-thread-pool-11180(427)" daemon prio=6 tid=0x000000002e1ec800

nid=0x1e90 waiting for monitor entry [0x000000006944c000]

    java.lang.Thread.State: BLOCKED (on object monitor)

at

groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)

    - waiting to lock <0x00000007d1ce8e88> (a groovy.lang.ExpandoMetaClass)

at

groovy.lang.ExpandoMetaClass.registerInstanceMethod(ExpandoMetaClass.java:873)

    at groovy.lang.ExpandoMetaClass.setProperty(ExpandoMetaClass.java:788)

at

org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:179)

at

org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:480)

at

org.codehaus.groovy.grails.plugins.web.filters.FilterConfig.methodMissing(FilterConfig.groovy:86)

    at sun.reflect.GeneratedMethodAccessor336.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:90)

at

groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:828)

The stack trace is loneger and eventually starts from

org.codehaus.groovy.grails.plugins.web.taglib.SitemeshTagLib.captureTagContent(SitemeshTagLib.groovy).

Anybody has come across these errors?

--

View this message in context:

http://grails.1312388.n4.nabble.com/Thread-Blocking-at-Groovy-ExpandoM

etaclass-method-in-a-Grails-App-tp4572990p4572990.html

Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------

To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Lari Hotari

Re: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

No you shouldn't need to use the "thisObject." prefix in other places.

That could be another performance bug.

What does your code look like on line #298 in StoryDao?

Regards,

Lari

20.04.2012 16:02, Gopinath, Dhanush wrote:

Yes. It helps. Currently we do not have any Blocking threads. But we are seeing a similar problem in other classes where a local private method is called from inside a closure. But this is not consistent. So my question is does all the methods called from a closure needs to be prefixed with thisObject ?

http-thread-pool-8080(443)" daemon prio=6 tid=0x0000000016dd2000 nid=0x9e0 waiting for monitor entry [0x000000003adda000]
java.lang.Thread.State: BLOCKED (on object monitor)
at groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)
- waiting to lock <0x00000007dee525e8> (a groovy.lang.ExpandoMetaClass)
at groovy.lang.ExpandoMetaClass.addSuperMethodIfNotOverridden(ExpandoMetaClass.java:513)
at groovy.lang.ExpandoMetaClass.onSuperMethodFoundInHierarchy(ExpandoMetaClass.java:394)
at groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:813)
at groovy.lang.MetaClassImpl.invokePropertyOrMissing(MetaClassImpl.java:1120)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1073)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1110)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:901)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:721)
at com.espni.domain.dao.BaseDao.invokeMethod(BaseDao.groovy)
at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1136)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1030)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1110)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:901)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149)
at com.espni.domain.dao.StoryDao$_getStories_closure6.doCall(StoryDao.groovy:298)
at sun.reflect.GeneratedMethodAccessor2596.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:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1071)

From: Lari Hotari [[hidden email]]
Sent: 20 April 2012 18:08
To: Gopinath, Dhanush
Cc: [hidden email]
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Does it fix the performance problem if you prefix that line with "thisObject." :

thisObject.setEditionsInRequest(request, grailsApplication)

(add "thisObject." prefix to all helper method calls in the ApplicationFilters class's before/after/afterView closures.)

Regards,

Lari

20.04.2012 12:59, Gopinath, Dhanush wrote:

Hi,

Line no 48 in our ApplicationFilters.groovy calls a helper method

setEditionsInRequest(request, grailsApplication) which is written in the same class.

Thanks

Dhanush

From: Lari Hotari [[hidden email]]
Sent: 20 April 2012 15:10
To: Gopinath, Dhanush
Cc: [hidden email]
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

This seems to be a performance problem in Grails.

I think I found a workaround.

Here is an example (I was trying to reproduce the problem):

class MyFilters {
    def helperMethod(arg1, arg2) {
        "${arg1} ${arg2}!"
    }
    def noArgsMethod() {
       helperMethod("Hi", "there")
    }
    def filters = {
        all(controller:'*', action:'*') {
            before = {
                println thisObject.helperMethod("Hello", "world")
            }
            after = { Map model ->
                println thisObject.noArgsMethod()
            }
            afterView = { Exception e ->

            }
        }
    }
}

You should prefix any helper method call in your Filters class with "thisObject.". Your code has a call to a helper method on #48 in ApplicationFilters (based on the stack trace you sent).

That prevents a method missing call that is handled by the un-optimized solution in FilterConfig:
https://github.com/grails/grails-core/blob/master/grails-plugin-filters/src/main/groovy/org/codehaus/groovy/grails/plugins/web/filters/FilterConfig.groovy#L87

There is some kind of problem in your case that the method missing "caching" doesn't work at all (and that causes the metaclass modification on each call). I just couldn't re-produce the problem yet. I believe the "thisObject." solution circumvents the problem.

It would be nice if you could tell what the line #48 looks like in your ApplicationFilters.groovy .
(from stacktrace:
        at ApplicationFilters$_closure1_closure4_closure5.doCall(ApplicationFilters.groovy:48)
)
That information could help us reproduce the problem and fix it (without using the "thisObject." workaround).

Regards,

Lari

20.04.2012 11:51, Gopinath, Dhanush wrote:
Hi,
 
I have attached the full stacktrace. We are using Grails 2.0.0
 
We have installed Grails Spring Cache plugin which has the filter GrailsFragmentCachingFilter. We also have one filter for our own use of token redirection. We have come across https://jira.codehaus.org/browse/GROOVY-5249 in our earlier load testing and has applied the patch to the latest groovy source. That issue is now not appearing.
 
Thanks 
Dhanush
-----Original Message-----
From: Lari Hotari [[hidden email]] 
Sent: 20 April 2012 14:11
To: [hidden email]
Cc: Gopinath, Dhanush
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App
 
Hi,
 
Some questions:
 
- Could you send the full stack trace as a file attachment?
- What kind of Filters does your app contain? (it's interesting since FilterConfig.methodMissing gets called if the filter closure calls some method in the app's *Filters class)
- What is the exact Grails version you are using? (Is it 2.0.0, 2.0.1,
2.0.2 or 2.0.3 ?)
 
It would help a lot if you could provide some test app that reproduces the problem.
 
Your problem behaves the same way as
http://jira.grails.org/browse/GRAILS-8050 (but is in different context).
It can be a bug in
org.codehaus.groovy.grails.plugins.web.filters.FilterConfig's
methodMissing method.
 
Lari
 
p.s. There is at least one ExpandoMetaClass related performance issue (that causes blocking) open on Groovy side, but that doesn't seem to be the issue in this case: https://jira.codehaus.org/browse/GROOVY-5249
 
 
20.04.2012 09:32, Dhanush Gopinath wrote:
We are load testing our Grails application hosted on Glassfish 3.1.1 
App Server. While testing we are constantly getting thread blocked at 
ExpandoMetaClass' performOperationOnMetaClass method. The stack trace 
is given. Is this is a known issue with Grails?
 
"http-thread-pool-11180(427)" daemon prio=6 tid=0x000000002e1ec800
nid=0x1e90 waiting for monitor entry [0x000000006944c000]
 
    java.lang.Thread.State: BLOCKED (on object monitor)
    at
groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)
    - waiting to lock <0x00000007d1ce8e88> (a groovy.lang.ExpandoMetaClass)
    at
groovy.lang.ExpandoMetaClass.registerInstanceMethod(ExpandoMetaClass.java:873)
    at groovy.lang.ExpandoMetaClass.setProperty(ExpandoMetaClass.java:788)
    at
org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:179)
    at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:480)
    at
org.codehaus.groovy.grails.plugins.web.filters.FilterConfig.methodMissing(FilterConfig.groovy:86)
    at sun.reflect.GeneratedMethodAccessor336.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:90)
    at 
groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:828)
 
The stack trace is loneger and eventually starts from 
org.codehaus.groovy.grails.plugins.web.taglib.SitemeshTagLib.captureTagContent(SitemeshTagLib.groovy).
Anybody has come across these errors?
 
--
View this message in context: 
http://grails.1312388.n4.nabble.com/Thread-Blocking-at-Groovy-ExpandoM
etaclass-method-in-a-Grails-App-tp4572990p4572990.html
Sent from the Grails - user mailing list archive at Nabble.com.
 
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
 
    http://xircles.codehaus.org/manage_email
 
 

Dhanush Gopinath

RE: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Its like this

contents.each{content->

Story story = getStoryContent(content, sportName, true); // this method is a private method inside the same class

stories.add(story);

}

From: Lari Hotari [mailto:[hidden email]]
Sent: 20 April 2012 18:51
To: Gopinath, Dhanush
Cc: [hidden email]
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

From: Lari Hotari [[hidden email]]
Sent: 20 April 2012 18:08
To: Gopinath, Dhanush
Cc: [hidden email]
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

Line no 48 in our ApplicationFilters.groovy calls a helper method

setEditionsInRequest(request, grailsApplication) which is written in the same class.

Thanks

Dhanush

Hi,

I have attached the full stacktrace. We are using Grails 2.0.0

We have installed Grails Spring Cache plugin which has the filter GrailsFragmentCachingFilter. We also have one filter for our own use of token redirection. We have come across https://jira.codehaus.org/browse/GROOVY-5249 in our earlier load testing and has applied the patch to the latest groovy source. That issue is now not appearing.

Thanks

Dhanush

-----Original Message-----

From: Lari Hotari [[hidden email]]

Sent: 20 April 2012 14:11

To: [hidden email]

Cc: Gopinath, Dhanush

Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

Some questions:

- Could you send the full stack trace as a file attachment?

- What kind of Filters does your app contain? (it's interesting since FilterConfig.methodMissing gets called if the filter closure calls some method in the app's *Filters class)

- What is the exact Grails version you are using? (Is it 2.0.0, 2.0.1,

2.0.2 or 2.0.3 ?)

It would help a lot if you could provide some test app that reproduces the problem.

Your problem behaves the same way as

http://jira.grails.org/browse/GRAILS-8050 (but is in different context).

It can be a bug in

org.codehaus.groovy.grails.plugins.web.filters.FilterConfig's

methodMissing method.

Lari

p.s. There is at least one ExpandoMetaClass related performance issue (that causes blocking) open on Groovy side, but that doesn't seem to be the issue in this case: https://jira.codehaus.org/browse/GROOVY-5249

20.04.2012 09:32, Dhanush Gopinath wrote:

We are load testing our Grails application hosted on Glassfish 3.1.1

App Server. While testing we are constantly getting thread blocked at

ExpandoMetaClass' performOperationOnMetaClass method. The stack trace

is given. Is this is a known issue with Grails?

"http-thread-pool-11180(427)" daemon prio=6 tid=0x000000002e1ec800

nid=0x1e90 waiting for monitor entry [0x000000006944c000]

    java.lang.Thread.State: BLOCKED (on object monitor)

at

groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)

    - waiting to lock <0x00000007d1ce8e88> (a groovy.lang.ExpandoMetaClass)

at

groovy.lang.ExpandoMetaClass.registerInstanceMethod(ExpandoMetaClass.java:873)

    at groovy.lang.ExpandoMetaClass.setProperty(ExpandoMetaClass.java:788)

at

org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:179)

at

org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:480)

at

org.codehaus.groovy.grails.plugins.web.filters.FilterConfig.methodMissing(FilterConfig.groovy:86)

    at sun.reflect.GeneratedMethodAccessor336.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:90)

at

groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:828)

The stack trace is loneger and eventually starts from

org.codehaus.groovy.grails.plugins.web.taglib.SitemeshTagLib.captureTagContent(SitemeshTagLib.groovy).

Anybody has come across these errors?

--

View this message in context:

http://grails.1312388.n4.nabble.com/Thread-Blocking-at-Groovy-ExpandoM

etaclass-method-in-a-Grails-App-tp4572990p4572990.html

Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------

To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Lari Hotari

Re: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Is the getStoryContent method strictly in StoryDao class (or is it in the BaseDao class?)?
Is that call on the line #298?

This is probably a bug (or "feature") in Groovy's ExpandoMetaClass.

btw. Does the "thisObject." prefixing help at this case?
Does it make a difference if the "getStoryContent" method is changed to be public or protected?

Regards,

Lari

20.04.2012 16:26, Gopinath, Dhanush wrote:

Its like this

              contents.each{content->

                     Story story = getStoryContent(content, sportName, true); // this method is a private method inside the same class

                     stories.add(story);

              }

From: Lari Hotari [[hidden email]]
Sent: 20 April 2012 18:51
To: Gopinath, Dhanush
Cc: [hidden email]
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

No you shouldn't need to use the "thisObject." prefix in other places.

That could be another performance bug.

What does your code look like on line #298 in StoryDao?

Regards,

Lari

20.04.2012 16:02, Gopinath, Dhanush wrote:

Yes. It helps. Currently we do not have any Blocking threads. But we are seeing a similar problem in other classes where a local private method is called from inside a closure. But this is not consistent. So my question is does all the methods called from a closure needs to be prefixed with thisObject ?

http-thread-pool-8080(443)" daemon prio=6 tid=0x0000000016dd2000 nid=0x9e0 waiting for monitor entry [0x000000003adda000]
java.lang.Thread.State: BLOCKED (on object monitor)
at groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)
- waiting to lock <0x00000007dee525e8> (a groovy.lang.ExpandoMetaClass)
at groovy.lang.ExpandoMetaClass.addSuperMethodIfNotOverridden(ExpandoMetaClass.java:513)
at groovy.lang.ExpandoMetaClass.onSuperMethodFoundInHierarchy(ExpandoMetaClass.java:394)
at groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:813)
at groovy.lang.MetaClassImpl.invokePropertyOrMissing(MetaClassImpl.java:1120)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1073)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1110)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:901)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:721)
at com.espni.domain.dao.BaseDao.invokeMethod(BaseDao.groovy)
at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1136)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1030)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1110)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:901)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149)
at com.espni.domain.dao.StoryDao$_getStories_closure6.doCall(StoryDao.groovy:298)
at sun.reflect.GeneratedMethodAccessor2596.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:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1071)

From: Lari Hotari [[hidden email]]
Sent: 20 April 2012 18:08
To: Gopinath, Dhanush
Cc: [hidden email]
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Does it fix the performance problem if you prefix that line with "thisObject." :

thisObject.setEditionsInRequest(request, grailsApplication)

(add "thisObject." prefix to all helper method calls in the ApplicationFilters class's before/after/afterView closures.)

Regards,

Lari

20.04.2012 12:59, Gopinath, Dhanush wrote:

Hi,

Line no 48 in our ApplicationFilters.groovy calls a helper method

setEditionsInRequest(request, grailsApplication) which is written in the same class.

Thanks

Dhanush

From: Lari Hotari [[hidden email]]
Sent: 20 April 2012 15:10
To: Gopinath, Dhanush
Cc: [hidden email]
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

This seems to be a performance problem in Grails.

I think I found a workaround.

Here is an example (I was trying to reproduce the problem):

class MyFilters {
    def helperMethod(arg1, arg2) {
        "${arg1} ${arg2}!"
    }
    def noArgsMethod() {
       helperMethod("Hi", "there")
    }
    def filters = {
        all(controller:'*', action:'*') {
            before = {
                println thisObject.helperMethod("Hello", "world")
            }
            after = { Map model ->
                println thisObject.noArgsMethod()
            }
            afterView = { Exception e ->

            }
        }
    }
}

You should prefix any helper method call in your Filters class with "thisObject.". Your code has a call to a helper method on #48 in ApplicationFilters (based on the stack trace you sent).

That prevents a method missing call that is handled by the un-optimized solution in FilterConfig:
https://github.com/grails/grails-core/blob/master/grails-plugin-filters/src/main/groovy/org/codehaus/groovy/grails/plugins/web/filters/FilterConfig.groovy#L87

There is some kind of problem in your case that the method missing "caching" doesn't work at all (and that causes the metaclass modification on each call). I just couldn't re-produce the problem yet. I believe the "thisObject." solution circumvents the problem.

It would be nice if you could tell what the line #48 looks like in your ApplicationFilters.groovy .
(from stacktrace:
        at ApplicationFilters$_closure1_closure4_closure5.doCall(ApplicationFilters.groovy:48)
)
That information could help us reproduce the problem and fix it (without using the "thisObject." workaround).

Regards,

Lari

20.04.2012 11:51, Gopinath, Dhanush wrote:
Hi,
 
I have attached the full stacktrace. We are using Grails 2.0.0
 
We have installed Grails Spring Cache plugin which has the filter GrailsFragmentCachingFilter. We also have one filter for our own use of token redirection. We have come across https://jira.codehaus.org/browse/GROOVY-5249 in our earlier load testing and has applied the patch to the latest groovy source. That issue is now not appearing.
 
Thanks 
Dhanush
-----Original Message-----
From: Lari Hotari [[hidden email]] 
Sent: 20 April 2012 14:11
To: [hidden email]
Cc: Gopinath, Dhanush
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App
 
Hi,
 
Some questions:
 
- Could you send the full stack trace as a file attachment?
- What kind of Filters does your app contain? (it's interesting since FilterConfig.methodMissing gets called if the filter closure calls some method in the app's *Filters class)
- What is the exact Grails version you are using? (Is it 2.0.0, 2.0.1,
2.0.2 or 2.0.3 ?)
 
It would help a lot if you could provide some test app that reproduces the problem.
 
Your problem behaves the same way as
http://jira.grails.org/browse/GRAILS-8050 (but is in different context).
It can be a bug in
org.codehaus.groovy.grails.plugins.web.filters.FilterConfig's
methodMissing method.
 
Lari
 
p.s. There is at least one ExpandoMetaClass related performance issue (that causes blocking) open on Groovy side, but that doesn't seem to be the issue in this case: https://jira.codehaus.org/browse/GROOVY-5249
 
 
20.04.2012 09:32, Dhanush Gopinath wrote:
We are load testing our Grails application hosted on Glassfish 3.1.1 
App Server. While testing we are constantly getting thread blocked at 
ExpandoMetaClass' performOperationOnMetaClass method. The stack trace 
is given. Is this is a known issue with Grails?
 
"http-thread-pool-11180(427)" daemon prio=6 tid=0x000000002e1ec800
nid=0x1e90 waiting for monitor entry [0x000000006944c000]
 
    java.lang.Thread.State: BLOCKED (on object monitor)
    at
groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)
    - waiting to lock <0x00000007d1ce8e88> (a groovy.lang.ExpandoMetaClass)
    at
groovy.lang.ExpandoMetaClass.registerInstanceMethod(ExpandoMetaClass.java:873)
    at groovy.lang.ExpandoMetaClass.setProperty(ExpandoMetaClass.java:788)
    at
org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:179)
    at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:480)
    at
org.codehaus.groovy.grails.plugins.web.filters.FilterConfig.methodMissing(FilterConfig.groovy:86)
    at sun.reflect.GeneratedMethodAccessor336.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:90)
    at 
groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:828)
 
The stack trace is loneger and eventually starts from 
org.codehaus.groovy.grails.plugins.web.taglib.SitemeshTagLib.captureTagContent(SitemeshTagLib.groovy).
Anybody has come across these errors?
 
--
View this message in context: 
http://grails.1312388.n4.nabble.com/Thread-Blocking-at-Groovy-ExpandoM
etaclass-method-in-a-Grails-App-tp4572990p4572990.html
Sent from the Grails - user mailing list archive at Nabble.com.
 
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
 
    http://xircles.codehaus.org/manage_email
 
 

Dhanush Gopinath

RE: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

It is a method strictly in StoryDao. We tried with thisObject. and the performance has improved. I will try making the method public and let you know

Thanks

Dhanush

From: Lari Hotari [mailto:[hidden email]]
Sent: 20 April 2012 19:19
To: Gopinath, Dhanush
Cc: [hidden email]
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Its like this

contents.each{content->

Story story = getStoryContent(content, sportName, true); // this method is a private method inside the same class

stories.add(story);

}

From: Lari Hotari [[hidden email]]
Sent: 20 April 2012 18:51
To: Gopinath, Dhanush
Cc: [hidden email]
Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

Line no 48 in our ApplicationFilters.groovy calls a helper method

setEditionsInRequest(request, grailsApplication) which is written in the same class.

Thanks

Dhanush

Hi,

I have attached the full stacktrace. We are using Grails 2.0.0

We have installed Grails Spring Cache plugin which has the filter GrailsFragmentCachingFilter. We also have one filter for our own use of token redirection. We have come across https://jira.codehaus.org/browse/GROOVY-5249 in our earlier load testing and has applied the patch to the latest groovy source. That issue is now not appearing.

Thanks

Dhanush

-----Original Message-----

From: Lari Hotari [[hidden email]]

Sent: 20 April 2012 14:11

To: [hidden email]

Cc: Gopinath, Dhanush

Subject: Re: [grails-user] Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Hi,

Some questions:

- Could you send the full stack trace as a file attachment?

- What kind of Filters does your app contain? (it's interesting since FilterConfig.methodMissing gets called if the filter closure calls some method in the app's *Filters class)

- What is the exact Grails version you are using? (Is it 2.0.0, 2.0.1,

2.0.2 or 2.0.3 ?)

It would help a lot if you could provide some test app that reproduces the problem.

Your problem behaves the same way as

http://jira.grails.org/browse/GRAILS-8050 (but is in different context).

It can be a bug in

org.codehaus.groovy.grails.plugins.web.filters.FilterConfig's

methodMissing method.

Lari

p.s. There is at least one ExpandoMetaClass related performance issue (that causes blocking) open on Groovy side, but that doesn't seem to be the issue in this case: https://jira.codehaus.org/browse/GROOVY-5249

20.04.2012 09:32, Dhanush Gopinath wrote:

We are load testing our Grails application hosted on Glassfish 3.1.1

App Server. While testing we are constantly getting thread blocked at

ExpandoMetaClass' performOperationOnMetaClass method. The stack trace

is given. Is this is a known issue with Grails?

"http-thread-pool-11180(427)" daemon prio=6 tid=0x000000002e1ec800

nid=0x1e90 waiting for monitor entry [0x000000006944c000]

    java.lang.Thread.State: BLOCKED (on object monitor)

at

groovy.lang.ExpandoMetaClass.performOperationOnMetaClass(ExpandoMetaClass.java:809)

    - waiting to lock <0x00000007d1ce8e88> (a groovy.lang.ExpandoMetaClass)

at

groovy.lang.ExpandoMetaClass.registerInstanceMethod(ExpandoMetaClass.java:873)

    at groovy.lang.ExpandoMetaClass.setProperty(ExpandoMetaClass.java:788)

at

org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:179)

at

org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:480)

at

org.codehaus.groovy.grails.plugins.web.filters.FilterConfig.methodMissing(FilterConfig.groovy:86)

    at sun.reflect.GeneratedMethodAccessor336.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:90)

at

groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:828)

The stack trace is loneger and eventually starts from

org.codehaus.groovy.grails.plugins.web.taglib.SitemeshTagLib.captureTagContent(SitemeshTagLib.groovy).

Anybody has come across these errors?

--

View this message in context:

http://grails.1312388.n4.nabble.com/Thread-Blocking-at-Groovy-ExpandoM

etaclass-method-in-a-Grails-App-tp4572990p4572990.html

Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------

To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Dhanush Gopinath

RE: Thread Blocking at Groovy ExpandoMetaclass method in a Grails App

Making the method public also improves the performance, but not sure if this is the correct workaround.

I also ran into this issue while we increased the load a bit. TeaContextSport is a class inside a plugin which we are using to access some legacy application, and line no 16 tries to invoke an method in the legacy code. But the thread gets Blocked

"http-thread-pool-8080(470)" daemon prio=6 tid=0x00000000160d5000 nid=0x19fc waiting for monitor entry [0x000000003ca2b000]

java.lang.Thread.State: BLOCKED (on object monitor)

at org.codehaus.groovy.reflection.GeneratedMetaMethod$Proxy.proxy(GeneratedMetaMethod.java:78)

- waiting to lock <a href="monitor://%3c0x00000007ccaa5790%3e"><0x00000007ccaa5790> (a org.codehaus.groovy.reflection.GeneratedMetaMethod$Proxy)

at org.codehaus.groovy.reflection.GeneratedMetaMethod$Proxy.doMethodInvoke(GeneratedMetaMethod.java:70)

at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1604)

at groovy.lang.ExpandoMetaClass.getProperty(ExpandoMetaClass.java:1140)

at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3332)

at groovy.lang.ExpandoMetaClass.getProperty(ExpandoMetaClass.java:1152)

at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:161)

at org.codehaus.groovy.runtime.callsite.PojoMetaClassGetPropertySite.callGetProperty(PojoMetaClassGetPropertySite.java:41)

at com.espn.tea.client.TeaContextSport.invokeMethod(TeaContextSport.groovy:16)

at groovy.lang.GroovyObject$invokeMethod.call(Unknown Source)

at com.espn.tea.client.TeaContextClient.invokeMethod(TeaContextClient.groovy:28)

at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:45)

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)

at com.espni.domain.dao.soccer.TeamDao.getTeamById(TeamDao.groovy:61)

at com.espni.domain.dao.soccer.TeamDao.getTeamById(TeamDao.groovy:55)

at com.espni.domain.dao.soccer.TeamDao$getTeamById.call(Unknown Source)

at com.espni.domain.dao.soccer.GameDao.getGame(GameDao.groovy:38)

at com.espni.domain.dao.soccer.GameDao$getGame.callCurrent(Unknown Source)

at com.espni.domain.dao.soccer.GameDao.getGameById(GameDao.groovy:94)

at sun.reflect.GeneratedMethodAccessor1551.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:90)

at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)

at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1071)

at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1110)

at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:901)

at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1016)

at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1110)

at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:901)

at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)

at com.espni.domain.dao.soccer.GameDao$_getGamesByLeagueSeason_closure1.doCall(GameDao.groovy:109)

at sun.reflect.GeneratedMethodAccessor1548.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:90)

at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)

at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1071)

at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1110)

at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:901)

at groovy.lang.Closure.call(Closure.java:412)

at groovy.lang.Closure.call(Closure.java:425)

at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:1377)

at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:1349)

at org.codehaus.groovy.runtime.dgm$162.invoke(Unknown Source)

at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:271)

at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:53)

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)

at com.espni.domain.dao.soccer.GameDao.getGamesByLeagueSeason(GameDao.groovy:107)

at com.espni.domain.dao.soccer.GameDao$getGamesByLeagueSeason.call(Unknown Source)

at com.espni.service.NavigationService.getAllGames(NavigationService.groovy:82)

at com.espni.service.NavigationService.this$2$getAllGames(NavigationService.groovy)

at com.espni.service.NavigationService$this$2$getAllGames$0.callCurrent(Unknown Source)

at com.espni.service.NavigationService.getSiteNavPage(NavigationService.groovy:68)

at com.espni.service.NavigationService$$FastClassByCGLIB$$c0379e8a.invoke()

at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:191)

at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:689)

at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)

at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80)

at org.aspectj.lang.ProceedingJoinPoint$proceed$94.call(Unknown Source)

at grails.plugin.springcache.aop.CachingAspect$_invokeCachedMethod_closure1.doCall(CachingAspect.groovy:39)

at sun.reflect.GeneratedMethodAccessor432.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.PogoMetaMethodSite$PogoCachedMethodSite.invoke(PogoMetaMethodSite.java:226)

at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:52)

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)

at grails.plugin.springcache.aop.CachingAspect$_invokeCachedMethod_closure1.doCall(CachingAspect.groovy)

at sun.reflect.GeneratedMethodAccessor422.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:90)

at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)

at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1071)

at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1110)

at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:901)

at groovy.lang.Closure.call(Closure.java:412)

at groovy.lang.Closure.call(Closure.java:406)

at java_util_concurrent_Callable$call.call(Unknown Source)

at grails.plugin.springcache.SpringcacheService.doWithCacheInternal(SpringcacheService.groovy:155)

at grails.plugin.springcache.SpringcacheService.this$2$doWithCacheInternal(SpringcacheService.groovy)

at grails.plugin.springcache.SpringcacheService$this$2$doWithCacheInternal$2.callCurrent(Unknown Source)

at grails.plugin.springcache.SpringcacheService.doWithCache(SpringcacheService.groovy:84)

at grails.plugin.springcache.SpringcacheService$doWithCache$0.call(Unknown Source)

at grails.plugin.springcache.aop.CachingAspect.invokeCachedMethod(CachingAspect.groovy:38)

at sun.reflect.GeneratedMethodAccessor376.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)

at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)

at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65)

at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)

at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)

at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)

at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:622)

at com.espni.service.NavigationService$$EnhancerByCGLIB$$78519737.getSiteNavPage()

at com.espni.service.NavigationService$getSiteNavPage.call(Unknown Source)

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callSafe(AbstractCallSite.java:68)

at com.espni.controller.BaseController.mainnav(BaseController.groovy:87)

at com.espni.controller.BaseController$mainnav$0.callCurrent(Unknown Source)

at com.espni.controller.TournamentController.index(TournamentController.groovy:30)

at sun.reflect.GeneratedMethodAccessor508.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.web.servlet.mvc.MixedGrailsControllerHelper.invoke(MixedGrailsControllerHelper.java:67)

at org.codehaus.groovy.grails.web.servlet.mvc.AbstractGrailsControllerHelper.handleAction(AbstractGrailsControllerHelper.java:330)

at org.codehaus.groovy.grails.web.servlet.mvc.AbstractGrailsControllerHelper.executeAction(AbstractGrailsControllerHelper.java:211)

at org.codehaus.groovy.grails.web.servlet.mvc.AbstractGrailsControllerHelper.handleURI(AbstractGrailsControllerHelper.java:177)

at org.codehaus.groovy.grails.web.servlet.mvc.AbstractGrailsControllerHelper.handleURI(AbstractGrailsControllerHelper.java:116)

at org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsController.handleRequest(SimpleGrailsController.java:72)

at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)

at org.codehaus.groovy.grails.web.servlet.GrailsDispatcherServlet.doDispatch(GrailsDispatcherServlet.java:325)

at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:827)

at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:882)

at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:778)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)

at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)

at javax.servlet.FilterChain$doFilter$0.call(Unknown Source)

at grails.plugin.springcache.web.GrailsFragmentCachingFilter.doFilter(GrailsFragmentCachingFilter.groovy:66)

at net.sf.ehcache.constructs.web.filter.Filter.doFilter(Filter.java:86)

at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)

at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)

at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:70)