Chris, >>> 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: >http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action? >pageId=2669 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 >classes, 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 >ClassLoader. > >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. -- Nikita --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
