Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Date: Mon, 8 Nov 2004 09:20:59 +0100 (CET)
From: Giacomo Pati <giacomo@apache.org>
To: dev@cocoon.apache.org
Subject: Migration report from Excalibur Event to RunnableManager 
Message-ID: <Pine.LNX.4.61.0411080829530.9165@lapgp.otego.com>
X-GPG-PUBLIC_KEY: 
 http://pks.gpg.cz:11371/pks/lookup?op=get&search=0x371005D8BA4A9F94
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N


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 WELCOME

I 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