tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Funk <>
Subject Re: very slow class loading on initial JSP/servlet request after restart
Date Wed, 25 Feb 2009 12:31:25 GMT
While I am late to this ... Is this an accurate summary?

- Slow re-load on a server
- Server is a production server
- Other servers are OK so it can only be reproduced on production server
- Initial looks at network seem to be no network activity
- There seems to be a hint at File.exists() causing an issue
- The wisdom of the crowds is pointing to disk issue

Would it be possible to copy the tomcat installation and webapp to 
another disk (or new directory) on the same machine and then run the 
copy on an alternate port? If it "fails" like it does on the lower port 
- you have a better sandbox for debugging. If not ... you have a new 
interesting data point in the debug process.

Last oddball question - even though this is a Linux server, is there any 
virus scanning software running?


Mark Thomas wrote:
> 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.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message