You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "McGibbney, Lewis John" <Le...@gcu.ac.uk> on 2010/12/19 19:56:59 UTC
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 [milu71@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 (+0000):
>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@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!)
Posted by Michael Ludwig <mi...@gmx.de>.
Hi Lewis,
McGibbney, Lewis John schrieb am 20.12.2010 um 09:42 (+0000):
> >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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: HTTP Status 500 - Server Internal Error (continued!)
Posted by "McGibbney, Lewis John" <Le...@gcu.ac.uk>.
>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!)
Posted by Michael Ludwig <mi...@gmx.de>.
McGibbney, Lewis John schrieb am 19.12.2010 um 18:56 (+0000):
>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org