tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nikita Belov" <>
Subject RE: JSP class loader
Date Tue, 25 Jul 2006 17:36:57 GMT

>>> If so, then you can't fix the
>>> problem by writing your own JSP compiler and/or ClassLoader.
>> I guess loading each JSP class by separate classloader instance
>> will fix the problem. Classloader will be created when HTTP request
>> recived and no one reference on this classloader instance will be
>> stored during request processing, so it can be destroyed by GC.
>I read through your ClassLoader. It doesn't look like it will compile,

Why? It were compiled and run on my PC.

>but I'll assume that it was just a copy/paste problem into your message.
>I'm not sure what your ClassLoader does differently than any other
>ClassLoader; what have you added? If you haven't changed anything, then
>it's possible that your classloaders are not being GC'd:

As article says, container drops all reference to classloader during 
web-app undeploy. This allows GC to remove classloader and free PermGen.
In our system, JSP deployed inside web-app without web-app
redeply. So references to ClassLoader aren't dropped. It is not 
possible to redeploy web-app, when new JSP arrived, however may be 
we can create separate web-apps for each business process, and 
redeploy it. I will think about it...

>> I am working on system for business processes processing. Each
>> business process can be deployed and launched by user many times.
>> Business process can contain JSP(JSF) pages, also it can contain
>> Java-scriplets (POJO classes) with business logic. Each scriplet is
>> loaded with separate classloader and therefore successfully unloaded
>> from PermGen when classloader destroyed.
>Do you use your own (hand-written) ClassLoader for the scriptlets, or
>one that comes with the JDK?

Yes. It is our own classloader.

>Someone with more knowledge of Tomcat's internal workings would have to
>confirm the behavior of Tomcat when a JSP changes and must be
>recompiled: is the ClassLoader for all JSPs discarded, or is there a
>separate ClassLoader for each JSP?

Looks like Tomcat create classloader for each web-app.

>I'm guessing that the ClassLoader itself is not your problem, but other
>objects retaining references to objects and classes loaded by it. I
>encourage you to read through the article I included above to see if any
>of the "known offenders" could possibly be affecting you -- particularly
>the introspection caches.
>> All JSP classes are loaded
>> by the one Tomcat classloader and can't be unloaded from memory.
>> This is the problem.
>I think they /can/ be unloaded from memory, but again, I'm not exactly
>sure. This might be a question to ask on the Tomcat developer mailing
>list. If Tomcat's ClassLoader really does not discard "old" compiled JSP

Looks like these classes will be removed from PermGen with classloader 
after web-app undeploy.

>then you really might have to hack the JSP compiler and/or
>loader (if they are different) to separate each JSP into its own
>I'm very interested to see how this turns out.

I see, threre are two possible ways for now: modify jsp servlet as I 
going to before or create web-app for each business process and redeploy 
it when new JSP arrived. 


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message