服务器在一夜之间闲置后，GSP呈现问题 [英] GSP rendering issue after server is idle overnight
问题描述
几周来，我断断续续地遇到了一个难以复制的问题.似乎(即我尚不确定)，如果Grails应用没有一夜之间被触摸，则可能是由于某些原因导致卸载:
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:
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>
这发生在独立部署到Tomcat的情况下，并且有一次让Grails在IntelliJ中运行过夜.
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.
应用程序或Tomcat的日志中都没有任何线索.
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
环境:
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
更新#1:
在这个周末再次发生，在使用Tomcat管理器重新加载Web应用程序时，它失败，并显示以下消息，但这在重新启动Tomcat时不会发生:
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
我不相信，因为jodaTime插件中的代码看起来还不错:
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[]
更新#2
旋律表明，所有物理内存都在缓慢吞噬
Melody shows that slowly all the Physical memory being gobbled up
如果重新加载该应用程序，则可能与这些日志条目相关(并始终强制Tomcat关闭并以挂起的Java进程开始被杀死)
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
或遵循以下内容: http://wiki.apache.org/tomcat/MemoryLeakProtection#cclThreadSpawnedByCommonClassLoader
更新#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)
推荐答案
问题是在Bootstrap.groovy中有此行:
The issue was having this line in Bootstrap.groovy:
String.metaClass.mixin StringUtils
我最终删除了此问题，并且在通常导致该问题的所有条件下，已经过了24小时的正常测试.
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)
错误和代码之间存在一定的关系，但实际上，我仍然不知所措，随着时间的流逝，mixin中发生了什么……返回本书我.
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.
这篇关于服务器在一夜之间闲置后，GSP呈现问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
