Home/ Questions/Q 8056621
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-05T08:46:06+00:00

I have been intermittently encountering a difficult to replicate issue now for a few

  • 0

I have been intermittently encountering a difficult to replicate issue now for a few weeks. It seems (ie I can’t yet be sure) that if the Grails app is not touched overnight something is perhaps unloaded causing:

GSP rendered with values such as:

<meta http-equiv="org.apache.commons.lang.StringUtils@72cd722b" content="org.apache.commons.lang.StringUtils@4e520b18">

<link href="/appname/static/bundle-bundle_application_head.css" type="org.apache.commons.lang.StringUtils@31da0262" rel="org.apache.commons.lang.StringUtils@774121fe" media="org.apache.commons.lang.StringUtils@6008482c" />

<body style="org.apache.commons.lang.StringUtils@49533701">

<a href="/appname/register/forgotPassword" name="org.apache.commons.lang.StringUtils@815a651" class="org.apache.commons.lang.StringUtils@5689bde">Forgotten Password?</a>

This occurs deployed to Tomcat standalone and also has once leaving Grails running overnight in IntelliJ.

It doesn’t happen every night but on most and I can’t yet track down what the difference is between working and not working.

Nothing in the logs of the either the application or Tomcat to give a clue.

At this point I’m wondering if it is to do with the resources plugin. But any thoughts on what to look at are appreciated

Environment:

   OS Win7 x64 and Redhat 5
Tomcat 7.0.x (also was occuring on latest Glassfish)
Grails 2.0.4
Plugins: 
plugins.cache=1.0.0.RC1
plugins.cache-headers=1.1.5
plugins.compress=0.4
plugins.console=1.1
plugins.executor=0.3
plugins.export=1.3
plugins.fields=1.1
plugins.google-visualization=0.5.2
plugins.grails-melody=1.13
plugins.joda-time=1.4
plugins.mail=1.0
plugins.p6spy=0.5
plugins.quartz-monitor=0.2
plugins.spring-security-core=1.2.7.3
plugins.springcache=1.3.1
plugins.zipped-resources=1.0

Update #1:

Occured again over this weekend, on using Tomcat manager to reload the webapp it fails with the following message but this does not occur on a fresh start of Tomcat:

 INFO: Initializing Spring root WebApplicationContext
Jun 3, 2012 7:53:01 PM org.apache.catalina.core.StandardContext listenerStart
SEVERE: Exception sending context initialized event to listener instance of class org.codehaus.groovy.grails.web.context.GrailsContextLoaderListener
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'grailsApplication' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested exception is java.lang.ExceptionInInitializerError
    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:662)
Caused by: java.lang.ExceptionInInitializerError
    at java.lang.Class.forName(Class.java:247)
    ... 3 more
Caused by: groovy.lang.MissingMethodException: No signature of method: static org.joda.time.DurationFieldType.hour() is applicable for argument types: () values: []
Possible solutions: hours(), wait(), days(), eras(), years(), any()
    at grails.plugin.jodatime.taglib.PeriodTagLib$_getPeriodTypeForFields_closure3.doCall(PeriodTagLib.groovy:87)
    at grails.plugin.jodatime.taglib.PeriodTagLib.getPeriodTypeForFields(PeriodTagLib.groovy:87)
    at grails.plugin.jodatime.taglib.PeriodTagLib.<clinit>(PeriodTagLib.groovy:84)
    ... 4 more

Which I don’t believe as the code in the jodaTime plugin looks ok:

   Line 84: private static final PeriodType DEFAULT_PERIOD_TYPE = getPeriodTypeForFields("hours,minutes,seconds")

    private static PeriodType getPeriodTypeForFields(String fields) {
    Line 87:    def fieldTypes = fields.split(/\s*,\s*/).collect { DurationFieldType."$it"() } as DurationFieldType[]

Update #2

Melody shows that slowly all the Physical memory being gobbled up

Could be related to these log entries if the app is reloaded (and always forces a Tomcat shutdown and start with a hanging java process to be killed)

SEVERE: The web application [/appname] appears to have started a thread named [Timer-1] but has failed to stop it. This is very likely to create a memory leak.
May 31, 2012 6:04:51 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/appname] appears to have started a thread named [DefaultQuartzScheduler_Worker-1] but has failed to stop it. This is very likely to create a memory leak.
May 31, 2012 6:04:51 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads

or it is something along these lines: http://wiki.apache.org/tomcat/MemoryLeakProtection#cclThreadSpawnedByCommonClassLoader

Update #3

Physical memory issue resolved and the app is still broken, looking like the original posting. This time after less idle (a couple of hours)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The issue was having this line in Bootstrap.groovy:

    String.metaClass.mixin StringUtils

    I eventually removed this and have been testing ok now for over 24 hours under all conditions that had ordinarily caused the issue.

    This I had followed from this posting a long time ago from here: Groovy GDK equivalent of Apache Commons StringUtils.capitalize(str) or Perl's ucfirst(str)

    There is some relationship in the error and the code that gave this away but to be honest I am still really at a loss as to what is going on in the mixin to do this over time…back to the books for me.

    • 0