Christopher Schultz wrote:
jstack.8.txt is the last thread dump where File.exists was stalled.
http://ims.net/jstack/jstack.9.txt
http://ims.net/jstack/jstack.10.txt
http://ims.net/jstack/jstack.11.txt
The server appears to be idle, here.
It's a little weird that thread 9770 has NO STACK INFO AT ALL.
http://ims.net/jstack/jstack.12.txt
http://ims.net/jstack/jstack.13.txt
Also idle.
Yeah, I _thought_ it was still stalled on 9-11, but it looks like I misjudged the timing by a bit. I was flipping back
and forth between virtual windows, hitting jstack while checking if my browser had the response from the server.
Obviously, the File.exists method shouldn't be taking that long... it's
a pretty simple operation. Are you using an NFS or other network share?
Does your disk have any physical problems? Is this machine running next
to any equipment that generates a lot of stray alpha particles? :)
Not that I know of. :) We now know it's hanging on java.io.File.exists(), though, so I suppose that's leading us
somewhere. It's a logical RAID array on four physical disks. I've run fsck on it (when this all first happened) and
it's fine. And this problem persists no matter where the classes are on the disk; whether they're in a JAR file
anywhere, or split out under WEB-INF/classes. I don't think it can be a disk issue. I guess I could write a standalone
Java routine to play with the File.exists() method and see if I can reproduce the delay "manually"....
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
