XOM API for Processing XML with Java

[Wolfgang Hoschek <wolfgang.hoschek AT mac.com>]

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.