[XOM-interest] Cleaning up sweeper thread
wolfgang.hoschek at mac.com
Tue Jan 16 20:30:35 EST 2007
On Jan 16, 2007, at 3:04 PM, Jeroen van Maanen wrote:
> I am using XOM and Nux to build a web application that uses XSLT
> transformations heavily.
> Recently I tried to clean up all the stuff that was still lying around
> after redeploying the application (the application spawns a lot of
> threads so I implemented close() methods on the owners of those
> to stop them).
> The only thread that I cannot get rid of, is the sweeper thread
> that is
> constructed in nux.xom.pool.Pool that clears invalid entries from
> all pools.
> Of course it would help to move nux.jar to the common or shared
> directory of Tomcat, but I'd rather keep everything in one war file.
> Another possibility I thought of was to initialize the pool in a
> group that is specific to the application and use the deprecated
> method to kill it. My last option is to patch nux.xom.Pool either
> with a
> static close() method or with a separate sweeper for each pool
> Any advice on which direction to take would be appreciated.
The sweeper is a java.util.Timer thread that lives forever and wakes
up every N secs (N = 10 by default) to remove invalid or stale pool
entries, which is cheap, taking time close to zero.
Perhaps I'm missing something, but unless you're redeploying your
webapp thousands of times into the same running VM instance it
shouldn't really be a problem to have an idle thread per deployment
lying around. The thread is harmless.
Patching in a public close() method would break modularity because
the sweeper is shared by all pool instances. Cancelling the thread
could affect any number of active third party pools.
Having a separate sweeper thread for each pool would lead to
inefficiencies stemming from the correspondingly increased number of
running threads. It also would not decrease the number of running
threads because a few pool instances are static and live forever
(e.g. XSLTransformPool.GLOBAL_POOL, XQueryPool.GLOBAL_POOL,
BuilderPool.GLOBAL_POOL) and so would their sweeper thread.
In general, redeploying a Java webapp into a running container may be
appealing but in practise isn't entirelly clean, not only because of
threading issues but also because of class loader issues. Is the
priority to redeploy a) quick or b) clean? If it's b) I'd recommend
restarting the VM from scratch. It it's a) then I'm afraid you'll
just have to find ways to live with the idle sweeper thread :-)
More information about the XOM-interest