Caldarale, Charles R wrote:
The key lines have a 3+ second response time:
2498 15:24:35 stat64("/net/ims/jcms/Object.class", 0x7b6b9c20) = -1 ENOENT (No such
file or directory) <3.020996>
Most of the calls return in much less than a millisecond, but there are a few
ENOENT (not all) responses that hit this 3-second delay. All of the slow ones
are looking at the /net/ims/jcms directory; what is that? Why is it in this
webapp's classpath? (It might be in the jar's META-INF entries.)
Wow, good eye, Chuck, and those add up to at least 35 seconds of the delay -
the bulk of it. I have absolutely no idea
why it's looking there. I certainly didn't put /net/ims/jcms in the classpath,
and the jar file that contains
net.ims.jcms just has a stub MANIFEST.MF entry, nothing else, in META-INF. I
don't have a META-INF directory under the
web app ROOT. The only place classes are stored under /net/ims/jcms is within
WEB-INF/lib/jcms.jar. But this is
clearly where the bulk of the time is spent, and one can see how this could
scale up really poorly, since Tomcat is
looking for random core classes like Object.class and Throwable.class under
/net/ims/jcms.
For comparison, here is the strace output from a test JSP that imports all of
the net.ims.jcms classes explicitly (no
wildcird import), and responds in three seconds:
http://ims.net/media/strace-test-explicit.txt
You can see the read/GET near the top and the write HTTP 200 response near the
bottom. There is only ONE attempt to
find a file under /net/ims/jcms, and that only takes .025 sec.
It looks like we've boiled the problem, at least in this test JSP case, down to
the classloader wasting 3 seconds per
try on stat-ing core Java classes in an imaginary location, /net/ims/jcms, on
the server's filesystem, which actually
corresponds to a path WITHIN a jar file that I wrote, and which doesn't contain
any core Java classes. This sure seems
like a bug to me, but why it is manifested only on this one server, and primarily
when I use a <%@ page
import="net.ims.jcms.*" %> call, remains a mystery. I can see how these
3-second errant lookups can really bog down the
server when it starts up, though, when a ton of classes are being loaded for
page requests on several virtual hosts.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
