tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: JSP class loader
Date Tue, 25 Jul 2006 14:23:14 GMT
Nikita,

>> 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,
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:
http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669

> 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?

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?

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
classes, then you really might have to hack the JSP compiler and/or
loader (if they are different) to separate each JSP into its own
ClassLoader.

I'm very interested to see how this turns out.

-chris



Mime
View raw message