So far I've migrated the classes to use the RunnableManager instead of creating own Threads:
- org.apache.cocoon.components.cron.QuartzJobScheduler$ThreadPool
It creates its own anonymous thread pool from the
RunnableManager#createPool. There is no changes needed wrt its
configuration (read it's backward compatible)- org.apache.cocoon.components.flow.ContinuationsManagerImpl
Uses the default thread pool to periodically run the
expireContinuations method:- org.apache.cocoon.components.hsqldb.ServerImpl
This class uses a thread from the daemon pool to creating its server
thread.- org.apache.cocoon.components.language.programming.java.Jikes
Here the StreamPumper inner class is executed. It uses a CoutDown
instance from the concurrent-util package to join the streamPumper
thread with the main thread.- org.apache.cocoon.transformation.helpers.DefaultIncludeCacheManager
The PreemptiveBooter inner class as well as the LoaderThread inner
class are put under RunnableManager control (later uses a CountDown
instance to singal a finish condition to the main thread).- org.apache.cocoon.transformation.IncludeTransformer$IncludeBuffer
Uses a thread from the daemon pool (I suspect it needs to use daemon
threads but the original code has used one).- org.apache.cocoon.portal.coplet.adapter.impl.AbstractCopletAdapter
The LoaderThread inner class is put under RunnableManager control
and uses a CountDown instance to singal a finish condition to the main
thread as well.- org.apache.cocoon.webapps.portal.components.PortalManagerImpl/CopletThread
It's in the deprecated portal-fw block so I have not considered
migrating it.- org.apache.cocoon.components.source.impl.DelayRefresher
This class uses cron blocks JobScheduler to fire periodical jobs.
Migrating it to the RunnableManager might be appropriate because if an
Cocoon installation switches the default memory based JobStore
(RAMJobStore) of the cron block to a persistent one (QuartzJobStoreCMT
or QuartzJobStoreTX) it might put quite some load onto the machine
because of JDBC traffic.
=> THIS CLASS IS NOT MIGRATED SO FAR (Vadim?)- org.apache.cocoon.components.slide.impl.JMSContentInterceptor
This class uses its own Runnable and Thread to publish messages in the
background. As I do not really know what this part of the class does
someone else might considering the migration to the RunnableManager.
=> THIS CLASS IS NOT MIGRATED SO FAR- org.apache.excalibur.store.impl.StoreJanitorImpl
This is a core component but because it is outside the scope of Cocoon
(lives inthe Excalibur project) I have not migrating it so far. A
possible solutions might be to subclass it and overwrite the start
method to use the daemon thread pool from the RunnableManager
to runn it.
=> THIS CLASS IS NOT MIGRATED SO FAR BUT SUGGESTIONS ARE WELCOMEI haven't found any other classes using their own Thread instances so far but as we have A LOT OF other jars in our libs there might well be others.
I'll start backporting it to the 2.1.x baranch now.
-- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
