Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Cleaning up sweeper thread

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <wolfgang.hoschek AT mac.com>
  • To: Jeroen van Maanen <jeroenvm AT xs4all.nl>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Cleaning up sweeper thread
  • Date: Tue, 16 Jan 2007 17:30:35 -0800

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 threads
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 thread
group that is specific to the application and use the deprecated stop()
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 instance.

Any advice on which direction to take would be appreciated.

Jeroen

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 :-)

Wolfgang.




Archive powered by MHonArc 2.6.24.

Top of Page