Thanks for you reply.
The JVM bug is an interesting possibility that I have also been wondering
about. It was also upgraded I believe.
The stack trace is a copy and paste from the log file.
I looked at the source yesterday and it also made no sense to me (why it is
recursing or at least seeming to in the stack trace). On a small note the
source you posted I think is a more modern version of that file. The method
from the source I downloaded for 5.5 yesterday reads
public static boolean delete(File dir, boolean logFailure) {
boolean result;
if (dir.isDirectory()) {
result = deleteDir(dir, logFailure);
} else {
if (dir.exists()) {
result = dir.delete();
} else {
result = true;
}
}
if (logFailure && !result) {
log.error(sm.getString(
"expandWar.deleteFailed", dir.getAbsolutePath()));
}
return result;
}
To answer your last question anything at all. Any WAR uploaded or on the server
already. And the deploy will work, just will not undeploy then. My first
thought when I first had trouble was that the WAR was screwed up but no. Any
WAR with any name has the same problems.
I also forgot to mention previously that I tried the anti locking attributes to
context and that did nothing for me either. I tried both the anti jar and anti
resource locking, together and independently.
-----Original Message-----
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, August 31, 2010 3:28 PM
To: Tomcat Users List
Subject: Re: undeploy failure - stack overflow tomcat 5 on RHEL 5
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Maximilian,
On 8/31/2010 2:15 PM, Maximilian Stocker wrote:
> I have a tomcat 5.5 running on a server with redhat enterprise linux
> 5 and everything has been working for the last 7 -8 months without
> problems. On Friday the IT department "patched"/upgraded the server
> (I believe both tomcat and java were moved up minor versions) and now
> any undeploy fails.
>
> The steps for me to produce are.
>
> 1. Deploy any app
> 2. Attempt to undeploy
[snip]
> Aug 30, 2010 1:15:23 PM org.apache.commons.modeler.BaseModelMBean invoke
> SEVERE: Exception invoking method check
> java.lang.StackOverflowError
> at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:76)
> at sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(UTF_8.java:411)
> at sun.nio.cs.UTF_8$Encoder.encodeLoop(UTF_8.java:466)
> at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:561)
> at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:258)
> at java.lang.StringCoding.encode(StringCoding.java:290)
> at java.lang.String.getBytes(String.java:954)
> at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
> at
> java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:243)
> at java.io.File.isDirectory(File.java:771)
> at org.apache.catalina.startup.ExpandWar.delete(ExpandWar.java:360)
Looks like a JVM bug to me.
> And the last line, ExpandWar.delete continues on and on etc.
That's weird that it would have ExpandWar.delete over and over again.
The code for ExpandWar.delete is:
public static boolean delete(File dir) {
if (dir.isDirectory()) {
return deleteDir(dir);
} else {
return dir.delete();
}
}
No recursion there at all. Are you sure you're reading it correctly?
> I tried some "simple" things like making sure all my webapps were deployed by
> the current tomcat and I have been searching on both Google and the Tomcat
> bugdatabase to no avail. This behavior fits closest to the windows locking
> jars problem but again that problem I can't see being the case here. If
> anyone has any ideas of what this might or where to look or try next it would
> be greatly appreciated.
>
> Some information about the setup if it helps.
>
> OS - 2.6.18-194.11.1.el5xen
> JVM - 1.6.0_0-b16 (Sun)
> Tomcat - Apache Tomcat/5.5.23
What's the name of your WAR file? How about the full path to the WAR file?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx9V6UACgkQ9CaO5/Lv0PDf5QCfRZUWZNTUuZx/MNsUxe2FIpkk
xIwAn1YeHgOsUyet3Qelw7Vw+RJEsMQI
=v//+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
