RE: HTTP Status 500 - Server Internal Error (continued!)
I'm not sure the thread Tomcat points out wasn't stopped is related to Commons Logging. Could it be that you created the thread in your app? I think that you are correct here although if I post more of the log for you to see then maybe we can confirm whether it is a common issue or not 20-Dec-2010 08:52:46 org.apache.catalina.startup.Catalina start INFO: Server startup in 8843 ms 20-Dec-2010 08:55:09 org.apache.coyote.http11.Http11AprProtocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 20-Dec-2010 08:55:09 org.apache.coyote.ajp.AjpAprProtocol pause INFO: Pausing Coyote AJP/1.3 on ajp-8009 20-Dec-2010 08:55:10 org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina 20-Dec-2010 08:55:11 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [Thread-4] but has failed to stop it. This is very likely to create a memory leak. 20-Dec-2010 08:55:11 org.apache.coyote.http11.Http11AprProtocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8080 20-Dec-2010 08:55:11 org.apache.coyote.ajp.AjpAprProtocol destroy INFO: Stopping Coyote AJP/1.3 on ajp-8009 This one? This is about references held by a class in the container classloader to a class in the webapp classloader, which prevents *all* of the webapp classes from being unloaded on undeploy. The problem is not related to Tomcat's complaint about the thread that wasn't stopped. The wiki entry I was referring to was this one (I should have included it in last post). It has a direct link to the one you provided http://wiki.apache.org/commons/Logging/FrequentlyAskedQuestions under subheading (towards the bottom) A memory leak occurs when undeploying/redeploying a webapp that uses Commons Logging. How do I fix this?. This refers to commons-logging-1.0.5.jar, the jar version used within the tika parser plugin in my webapp is version 1.1.1, this is why I am unsure as to how accurate the code is in this wiki entry (although it was last edited on 2010-05-05) actually is. It then goes on to mention that the deployment descriptor for the webapp would need to be updated etc... this is what I was referring to when I mentioned the can of worms. In reading about ClassLoader I have come full circle and have ended up running back into my friend the Endorsed Standards Override Mechanism. I made Jena (which uses its own OWL parser, therefore no need for xerces) available to Tomcat in an endorsed folder, this should override the JAXP API's this seemed to solve the parser problem. If the error I am getting is not related to commons logging, and instead as you mentioned (and as shown in logs) related to the WebappClassLoader then I will pursue this route. Sorry for long post Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education’s Widening Participation Initiative of the Year 2009 and Herald Society’s Education Initiative of the Year 2009 http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html
Re: HTTP Status 500 - Server Internal Error (continued!)
Hi Lewis, McGibbney, Lewis John schrieb am 20.12.2010 um 09:42 (+): I'm not sure the thread Tomcat points out wasn't stopped is related to Commons Logging. Could it be that you created the thread in your app? I think that you are correct here although if I post more of the log for you to see then maybe we can confirm whether it is a common issue or not 20-Dec-2010 08:55:11 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [Thread-4] but has failed to stop it. This is very likely to create a memory leak. Well, Thread-4 isn't very informative, is it? You could take a thread dump just before shutting down Tomcat and then check if the unruly thread Tomcat points out is still running is also contained in the thread dump. If so you'll have more information on what causes this issue. In reading about ClassLoader I have come full circle and have ended up running back into my friend the Endorsed Standards Override Mechanism. I made Jena (which uses its own OWL parser, therefore no need for xerces) available to Tomcat in an endorsed folder, this should override the JAXP API's this seemed to solve the parser problem. http://jena.sourceforge.net/ - JAR is 23 MB You should probably place Jena in your webapp's WEB-INF/lib/ folder. This page has information on why to do so: http://wiki.apache.org/commons/Logging/UndeployMemoryLeak Notably: It is therefore a complete mystery to me why people seem so keen to push libraries up out of the components where they belong and into the container's library directories. It's like pushing user code into the operating system kernel. Just don't do it. The endorsed/ folder is not intended to accommodate arbitrary third party libraries. You can read up on what's meant to go there on the Java doc page I posted a link to. For example, the XML parser is. -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: HTTP Status 500 - Server Internal Error (continued!)
Hi I managed to get over the parser issue by following your suggestions. Just as I thought things were gradually getting better I am now encountering errors with the class org/apache/common/logging/LogFactory when I try to launch webapp on Tomcat. Reading my Tomcat output logs I notice the following code in the final few lines before the console window closes. SEVERE: A web application appears to have started a thread named [Thread-4] but has failed to stop it. This is very likely to create a memory leak. Having delved into the world of commons logging I am interested to hear whether the correct solution to solve a memory leak when deploying/undeploying a webapp is to include a class which implements ServletContextListener(according to commons wiki FAQ's). This is the last thing that I would have expected when experimenting with a new plugin for my webapp and I am concerned that in beating the parser problem I have opened a can of worms. Does anyone have any comments here please. Thanks Lewis From: Michael Ludwig [mil...@gmx.de] Sent: 19 December 2010 12:35 To: users@tomcat.apache.org Subject: Re: HTTP Status 500 - Server Internal Error McGibbney, Lewis John schrieb am 18.12.2010 um 21:20 (+): I understand this now, my initial understanding was that Tomcat was distributed with a version of xerces (or some other) parser implementation Tomcat isn't, but the Sun JRE is shipping a forked and modified Apache Xerces. It has acquired a reputation for bugginess, though, which is why many people prefer to use Apache Xerces (formerly known as IBM XML4J, donated in 1999). I am trying to get to the bottom of what org.apache.xerces.util.XMLChar is and why it is causing the exceptions and errors when I lanuch the webapp. Something's compiled against this class and complains that it cannot be loaded. You need to make Apache Xerces available to the webapp in question. This can be achieved by putting the relevant JAR(s) in WEB-INF/lib. In the case of Xerces, however, it is preferable to put the JAR(s) into %CATALINA_HOME%\endorsed (which may not exist but may be created) so they will be available to all of Tomcat and outmatch the Sun fork shipping with the JRE. Can you expand on your final statement to provide more detail please, I am unfamilar with this configuration. Take a look at the setclasspath and catalina shell scripts in %CATALINA_HOME%\bin. Search them for endorsed and read up on the Java Endorsed Standards Override Mechanism: http://download.oracle.com/javase/6/docs/technotes/guides/standards/index.html -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Email has been scanned for viruses by Altman Technologies' email management service - www.altman.co.uk/emailsystems Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education’s Widening Participation Initiative of the Year 2009 and Herald Society’s Education Initiative of the Year 2009 http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html
Re: HTTP Status 500 - Server Internal Error (continued!)
McGibbney, Lewis John schrieb am 19.12.2010 um 18:56 (+): I managed to get over the parser issue by following your suggestions. Fine! I am now encountering errors with the class org/apache/common/logging/LogFactory when I try to launch webapp on Tomcat. Commons Logging is frequently encountered as a dependency in JARs you might want to include with your app - and unfortunately not always in compatible versions. Reading my Tomcat output logs I notice the following code in the final few lines before the console window closes. SEVERE: A web application appears to have started a thread named [Thread-4] but has failed to stop it. This is very likely to create a memory leak. Newer Tomcats detect errors that previously went by unnoticed. I'm not sure the thread Tomcat points out wasn't stopped is related to Commons Logging. Could it be that you created the thread in your app? Having delved into the world of commons logging I am interested to hear whether the correct solution to solve a memory leak when deploying/ undeploying a webapp is to include a class which implements ServletContextListener(according to commons wiki FAQ's). http://wiki.apache.org/commons/Logging/UndeployMemoryLeak This one? This is about references held by a class in the container classloader to a class in the webapp classloader, which prevents *all* of the webapp classes from being unloaded on undeploy. The problem is not related to Tomcat's complaint about the thread that wasn't stopped. I am concerned that in beating the parser problem I have opened a can of worms. Hmm, the missing Apache Xerces and the dangling thread are unlikely to be related. -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
