Caldarale, Charles R wrote:
I'll poke around in the webapp classloader to see if I can find anything
interesting, but in the meantime, is there a /net directory on the problematic
server? If there is and it targets a remote file system, that might explain
the long delay on these stat() calls.
You DA MAN, Charles! It exists, owned by root, created when the machine was last booted, is empty and is currently
locked. One of the other, non-problematic, servers has a similar empty /net directory; the other doesn't.
[r...@pluto tmp]# stat /net
File: `/net'
Size: 0 Blocks: 0 IO Block: 1024 directory
Device: 14h/20d Inode: 4937 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2009-02-26 09:18:38.479994369 -0600
Modify: 2009-02-24 12:32:45.839946431 -0600
Change: 2009-02-24 12:32:45.839946431 -0600
[r...@pluto tmp]# lsof /net
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
automount 2682 root 16r DIR 0,20 0 4937 /net
[r...@pluto]# rmdir /net
rmdir: failed to remove `/net': Device or resource busy
It's created by automount, by the autofs service, along with /misc. /misc and /net are listed in /etc/auto.master. I
guess since Tomcat keeps hitting /net, it's never automatically unmounted. Not sure why /misc stays mounted.
SO, I've shut off autofs (on by default in a Fedora install, apparently), removed /net (and /misc), and SURE ENOUGH, my
test JSP that imports net.ims.jcms.* COMPILES AND RUNS FAST, in less than a second!!!
In summary, for unknown reasons, JDT is searching /net for core Java classes; /net exists, because it's listed in
/etc/auto.master and the autofs daemon created it with automount; JDT's stat on /net/* is slow for unknown reasons, but
that slowness adds up to a huge delay in classloading.
So, we've "fixed" the problem (!!!!) by shutting off autofs and removing /net, but the core issue, that JDT is searching
under /net for core classes, remains. That shouldn't be happening. I'll pursue that a bit on my test instance with
org.apache.jasper.level=ALL.
We're almost there! Thanks, everyone!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
