Sam Hokin wrote: > 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".... > > It _could_ be a disk issue. I've seen disks that scan fine contain a growing number of blocks causing read errors and continuous retries.
--David --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
