Sam Hokin wrote: > Mark Thomas wrote: >> Sam Hokin wrote: >>> Thanks, Chris. I ran e2fsck with the -c option, which runs badblocks, >>> when I tested it earlier. And I just ran badblocks again - 0 bad blocks >>> found. I wish I could fix this by simply as swapping out a bad disk >>> (notwithstanding Andre's desire for intellectual pursuits), but I really >>> think it's software, either in some service mucking up the JVM or the >>> JVM itself. But it only manifests itself under Tomcat, and then only >>> when this particular package is imported. >> >> Do you see the same issue if you pre-compile that JSP? > > Surprisingly, yes. So it's not only a compilation issue.
Ok. To summarise when you include net.ims.jcms.* in your imports the page compiles quickly but takes ages to respond to the first request. I wonder if this is related to loading a specific class in your library. Can you use a test JSP try and isolate which class(es) are causing the slow down? My thinking is if we can reduce the scope of the problem to importing a single class, we can then separate out that class and reduce the code in it bit by bit until we have the bare minimum that causes the problem. Hopefully, there will be little enough code left that it will be obvious. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
