Migration report from Excalibur Event to RunnableManager

[Giacomo Pati <gi...@apache.org>]

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

RE: Migration report from Excalibur Event to RunnableManager

[Carsten Ziegeler <cz...@apache.org>]

Giacomo Pati wrote: 
> 
> Backporting is finished.
> 
> I've deeply looked at the
> org.apache.excalibur.store.impl.StoreJanitorImpl. The only 
> way to have it use the RunnableManger is by copying the 
> source :-( because that class isn't made for subclassing. I 
> have one ready just to have me see how it could be 
> implemented. To make the class subclassable we have to open 
> up a bunch of getters/setter and overwrite the start and run 
> method. But this is more or less having it copied.
> 
> An other approach would be to refactor the memory management 
> logic into its own method and have the run method call it in 
> its loop body (current impl.). That way subclassing would 
> still overwrite the start and run method but the hole memory 
> management logic will be hidden in its own protected method.
> 
> Please, give me some oppinions on how to proceed. Take into 
> account that if we refactor the excalibur-store package we 
> need to release that right together (or one day before) the 
> cocoon 2.1.6 release if we want to have a StoreJanitor impl. 
> that uses the RunnableManager (I've never released any of the 
> Avalon/Excalibur packages, thus don't know how long it will 
> take). Also remember that the Store is core to Cocoon and IMO 
> the core should use the abilities of core components like the 
> RunnableManager.
> 
> I know many of you don't see why this has any importance nor 
> why that should happen. Most of us run Cocoon in Jetty or 
> Tomcat. But there are also users with BWL and WAS which run 
> Cocoon there in. Recently a commercial app servers vendor has 
> begun to "sandbox" (via RACF!) the deployed servlets and has 
> inhibited thread creation (IIRC the J2EE spec says "your app 
> components may not spawn their own threads". By the 
> single-class-for thread-creation approache used by the 
> RunnableManager we can point them to where to relax the 
> sandboxing to make Cocoon run again. I have evangelized 
> people to use Cocoon as many of aou have as well. Now some of 
> them need to migrate onto the app server release mentioned 
> above out of strategic directions in their companies and of 
> course they expect some support/help/suggestions.
> 
Hmm, not sure what's best here - but afaik doing a release of
excalibur-store might be not possible given the current time
frame, so why not copy the source of the class for now,
and provide at the same time a patch to excalibur? As soon
as they're doing a release we can remove our copy again.

Carsten

Re: Migration report from Excalibur Event to RunnableManager

[Giacomo Pati <gi...@apache.org>]

On Mon, 8 Nov 2004, Giacomo Pati wrote:

> - 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.

Backporting is finished.

I've deeply looked at the 
org.apache.excalibur.store.impl.StoreJanitorImpl. The only way to have 
it use the RunnableManger is by copying the source :-( because that 
class isn't made for subclassing. I have one ready just to have me see 
how it could be implemented. To make the class subclassable we have to 
open up a bunch of getters/setter and overwrite the start and run 
method. But this is more or less having it copied.

An other approach would be to refactor the memory management logic into 
its own method and have the run method call it in its loop body (current 
impl.). That way subclassing would still overwrite the start and run 
method but the hole memory management logic will be hidden in its own 
protected method.

Please, give me some oppinions on how to proceed. Take into account that 
if we refactor the excalibur-store package we need to release that right 
together (or one day before) the cocoon 2.1.6 release if we want to have 
a StoreJanitor impl. that uses the RunnableManager (I've never released 
any of the Avalon/Excalibur packages, thus don't know how long it will 
take). Also remember that the Store is core to Cocoon and IMO the core 
should use the abilities of core components like the RunnableManager.

I know many of you don't see why this has any importance nor why that 
should happen. Most of us run Cocoon in Jetty or Tomcat. But there are 
also users with BWL and WAS which run Cocoon there in. Recently a 
commercial app servers vendor has begun to "sandbox" (via RACF!) the 
deployed servlets and has inhibited thread creation (IIRC the J2EE spec 
says "your app components may not spawn their own threads". By the 
single-class-for thread-creation approache used by the RunnableManager 
we can point them to where to relax the sandboxing to make Cocoon run 
again. I have evangelized people to use Cocoon as many of aou have as 
well. Now some of them need to migrate onto the app server release 
mentioned above out of strategic directions in their companies and of 
course they expect some support/help/suggestions.

-- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com