tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Algis Rudys <>
Subject Re: Soft termination: a demonstration
Date Mon, 14 Jul 2003 21:06:29 GMT
On Fri, 2003-07-11 at 01:45, Costin Manolache wrote:
> If I understand correctly, you modify the bytecode to insert checks before
> it loops back ? Pretty cool. I haven't looked too much at the code - do you
> do it via a generic ClassLoader ? 

That is correct.  I modified
org.apache.catalina.loader.WebappClassLoader and
org.apache.jasper.servlet.JasperLoader to rewrite classes loaded by
these class loaders while the as a part of the class loading process.

> Are you interested to contribute this to tomcat, or it's just a demo ? 

I am interested in contributing this to Tomcat.  The code is not quite
suitable for production, however, and would take a little bit of work to
get there.  Also, as I noted in the docs, JikesBT (the bytecode
rewriting toolkit I used) is not freely redistributable, which might
mean the code needs to be ported to some other system.

> I'm wondering if the JVM itself wouldn't be a better place to implement
> this functionality ( i.e. a safe implementation of Thread.stop() )

There are a couple of reasons we did it this way:
(1) If soft termination is implemented in the JVM, then you would have
to use the particular implementation of JVM that has this feature, or
you don't get the feature.  The code that I have, on the other hand,
doesn't need to wait until a commercial JVM has this feature
(2) Soft termination has some nice semantics that lend themselves to
being implemented with bytecode rewriting. In particular, when a webapp
is terminated, an exception is thrown which effectively cannot be caught
by the webapp but can be caught by the dispatcher in Tomcat (allowing
Tomcat to deal with the exception relatively cleanly). A JVM
implementation would require a little bit of work to get the same
(3) Note that soft termination doesn't terminate threads, it terminates
classes, so Thread.stop() is not an accurate analogue; a better one
would be a hypothetical Class.stop() or ClassLoader.stop().

> Costin

Algis R.

         Algis Rudys        Rice University        Computer Science
"Heart has nothing to do with it anymore. It's all in the caffeine."
 -- Frank Pembleton, _Homicide_

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message