Bug ID: 63661
           Summary: Method, loading of jar
                    is slow and recursive from lib folder of application
           Product: Tomcat 9
           Version: 9.0.22
          Hardware: PC
            Status: NEW
          Severity: critical
          Priority: P2
         Component: Catalina
  Target Milestone: -----

Created attachment 36716
screenShot visualVM

My Application:
my application is Java WebApplication, Using Tomcat9 and OpenJDK11 with
Velocity Template Engine and core java for DB interactions, Jquery for
I deploy my application as a docBase application, not like a war file


Problem: My application has performance issues. Http requests from the browser
are slow, basically, backend(Java) taking time to create a response for HTTP

So I drilled down and use VisualVM to look into the main problem area.

I found that my application code is not taking time, its something else, so the
issue is because of Method loads the jars for
every HTTP Request. to resolve this problem I read some of the articles and
Stackoveflow Answers, that helped but partially, issue fixed but not really.

So let's talk about the solution: Solution is to increase the CacheTTL (Cache
time to live).
Basically, the problem is CacheTTL is 5 seconds by default, Tomcat load class
from the jar only for 5 seconds if the application needs a class again, Tomcat
will again load a class from the jar. which is a recursive process, so I tried
to increase the CacheTTL to 30 days. and it worked well. Now Tomcat not load
the class which is once loaded.

But the issue is Application is still slow for the first hit because the first
hit has to load the classes.

So the issue is why Tomcat is so slow to load a class from a jar file.
I debug into this too.
So when we need a class, we give the path of the jar to read a class from this
jar, but the method is called for every jar
available in the lib folder. eg: if we have 250 jars in the Lib folder and we
need one particular class,

You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to