tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: Memory leak with ThreadGroups
Date Sat, 25 Jan 2003 06:47:37 GMT


On Fri, 24 Jan 2003, Tolles, James wrote:

>
> It seems like re-loading a new jsp workw easily and well, only the new
> jsp gets loaded, the application is not restarted. But, if a servelt is
> updated, Tomcat (if reload is on) begins a sequence: tries to serialize
> the session adn save it; reloads the app; then restore the session. Is
> it a class loader issue that prevents tomcat from treating the new
> servlet class tha same as a new jsp?
>

The JSP page compiler goes to an incredible amount of work to make that
happen -- essentially, it creates a new class loader for every JSP page,
and throws that class loader (and therefore the page class) away when you
modify the page.

This works for JSP because the Java code is all generated by the compiler
(well, you can still screw up and cause memory leaks with your scriptlets,
but there's nothing that any server can do about that), and it tries to
ensure that only the container itself ever keeps a reference to the actual
object for the generated page.  Therefore, it can throw away its reference
and have a high degree of confidence that the old object is now GC-able.

For servlets (or for JavaBeans in general), there is no way for the
container to know how many other objects have references to that servlet
-- and that turns out to be pretty common, so the strategy would not be
effective anyway.

Some very early first-generation servlet containers were set up this way,
but it turned out not to work in practice.

Craig



--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message