Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0003673 [Resin] minor always 09-04-09 09:13 09-09-09 11:11
Reporter ferg View Status public  
Assigned To ferg
Priority normal Resolution fixed  
Status closed   Product Version 4.0.1
Summary 0003673: duplicate class definition (environment classloader)
Description (rep by Jamison Novak)

I have a somewhat strange issue that I'm not 100% sure how to describe. We're toying with Resin 4.0.1 in our clustered environment and we're seeing a problem that's completely new and completely frustrating to troubleshoot. This issue *only* appears in our clustered (2 physical servers) environment. It does not appear in our single-server Dev environment.
 
We have an in-house CMS application that has startup issues under Resin 4.0.1. It, like all of our other webapps, has the "com.caucho.jsp.JspPrecompileListener" entry to take care of that on startup. Here's the scenario:
 
We run a Perl script that kicks off an Ant build of the webapp, deploys the app under /usr/local/www/cms, then starts up the Resin instance using the system init script. It then deploys the webapp to the second server in the cluster and starts up that Resin instance.
 
9 out of 10 times, the application will fail to start on the second server with the following error:
 
[2009/09/04 10:32:47.010] In-place class redefinition (HotSwap) is available.
[2009/09/04 10:32:49.250] INFO in com.caucho.jsp.TldManager Loading .tld files from global classpath
[2009/09/04 10:32:49.251] Loading .tld files from global classpath
[2009/09/04 10:32:52.641] WARNING in com.caucho.util.ThreadPool java.lang.LinkageError: loader (instance of com/caucho/loader/EnvironmentClassLoader): attempted duplicate class definition for name: "org/apache/commons/logging/impl/LogFactoryImpl"
                                at java.lang.ClassLoader.defineClass1(Native Method)
                                at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
                                at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
                                at com.caucho.loader.DynamicClassLoader.loadClassEntry(DynamicClassLoader.java:1662)
                                at com.caucho.loader.DynamicClassLoader.findClassImpl(DynamicClassLoader.java:1520)
                                at com.caucho.loader.DynamicClassLoader.loadClassImpl(DynamicClassLoader.java:1395)
                                at com.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:1321)
                                at com.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:1302)
                                at org.apache.commons.logging.LogFactory.createFactory(LogFactory.java:1131)
                                at org.apache.commons.logging.LogFactory$2.run(LogFactory.java:1065)
                                at java.security.AccessController.doPrivileged(Native Method)
                                at org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:1062)
                                at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:650)
                                at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685)
                                at org.apache.struts.util.MessageResources.<clinit>(MessageResources.java:54)
                                at org.apache.struts.taglib.html.HtmlTag.<clinit>(HtmlTag.java:43)
                                at java.lang.Class.forName0(Native Method)
                                at java.lang.Class.forName(Class.java:169)
                                at org.apache.strutsel.taglib.html.ELHtmlTagBeanInfo.class$(ELHtmlTagBeanInfo.java:42)
                                at org.apache.strutsel.taglib.html.ELHtmlTagBeanInfo.getPropertyDescriptors(ELHtmlTagBeanInfo.java:42)
                                at java.beans.Introspector.getTargetPropertyInfo(Introspector.java:494)
                                at java.beans.Introspector.getBeanInfo(Introspector.java:404)
                                at java.beans.Introspector.getBeanInfo(Introspector.java:168)
                                at com.caucho.jsp.java.GenericTag.getAttributeMethod(GenericTag.java:663)
                                at com.caucho.jsp.java.GenericTag.endElement(GenericTag.java:194)
                                at com.caucho.jsp.java.JavaJspBuilder.endElement(JavaJspBuilder.java:482)
                                at com.caucho.jsp.JspParser.parseCloseTag(JspParser.java:1704)
                                at com.caucho.jsp.JspParser.parseNode(JspParser.java:496)
                                at com.caucho.jsp.JspParser.parseJsp(JspParser.java:378)
                                at com.caucho.jsp.JspParser.parse(JspParser.java:266)
                                at com.caucho.jsp.JspCompilerInstance.parse(JspCompilerInstance.java:539)
                                at com.caucho.jsp.JspCompilerInstance.generate(JspCompilerInstance.java:475)
                                at com.caucho.jsp.JspPrecompileResource$CompileTask.compilePath(JspPrecompileResource.java:251)
                                at com.caucho.jsp.JspPrecompileResource$CompileTask.run(JspPrecompileResource.java:194)
                                at com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:874)
                                at com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:787)
                           java.lang.LinkageError: loader (instance of com/caucho/loader/EnvironmentClassLoader): attempted duplicate class definition for name: "org/apache/commons/logging/impl/LogFactoryImpl"
 
 
Sometimes, if I manually stop and then restart the instance it starts up without error. Most of the time, however, it just continues to return the above error.
 
The Resin instance on the build server *never* encounters this error. Both servers are configured identically, both servers are using the same resin.xml, and both servers are using the same WAR for the application. Neither server has any non-Caucho-provided JARs under the /usr/local/resin directory (either in lib or ext-lib).
 
I should also note that this only happens with this particular webapp. We have numerous other webapps that do not encounter this problem.
 
Any thoughts on what may be causing this or how to go about troubleshooting it? I've never seen this behavior in any of our previous experiements with non-3.0 Resin on any of our servers.
 
Additional Information
Attached Files

- Relationships

There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
09-04-09 09:13 ferg New Issue
09-04-09 09:23 jnovak Issue Monitored: jnovak
09-09-09 11:11 ferg Assigned To  => ferg
09-09-09 11:11 ferg Status new => closed
09-09-09 11:11 ferg Resolution open => fixed
09-09-09 11:11 ferg Fixed in Version  => 4.0.2


Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
28 total queries executed.
25 unique queries executed.
Powered by Mantis Bugtracker