Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F54E0CC.7040309@apache.org>
Date: Tue, 02 Sep 2003 14:26:20 -0400
From: Berin Loritsch <bloritsch@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: CommandManager issues [was Re: Releasing 2.1.1?]
References: <Pine.LNX.4.53.0308301140420.31893@lapgp.otego.com>
	 <1062257067.14367.384.camel@yum.ot>
 <1062335416.14373.441.camel@yum.ot>	 <3F54A0AD.2080404@apache.org>
 <1062519539.1981.630.camel@yum.ot>
In-Reply-To: <1062519539.1981.630.camel@yum.ot>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Bruno Dumon wrote:


> I don't want to spend very much time on this thread anymore, but here's
> the short summary:

Understandable.  Again, I do want to fix the issues.  Also note that it is
accessible to Cocoon committers.

> 
> I don't have any problem with the concepts behind the
> CommandManager/ThreadManager or the event package in general, in fact I
> think they're very good. My last point about the continuous checking of
> events every 100 ms isn't really a big issue for me.

I was catching up over the weekend.

> 
> I only wanted to point out some problems in the current implementation
> as it is. Those problems can of course be fixed, and for Cocoon to
> depend on this system, they also need to be fixed. And maybe I'm also
> wrong on some of these problems.

Some of them I think are misconceptions.

> 
> One of these problems is the above mentioned fact that all events from
> one CommandManager are executed on one thread, no matter how many
> threads you configure in the ThreadManager. I got this only from looking
> at the code, here's the explanation I mentioned earlier in this same
> thread, I hope you can prove me wrong:

This is one of the misconceptions.  More info below.

> 
> If you look at the code of the AbstractThreadManager:
> 
> In the method "register( EventPipeline pipeline )" one PipelineRunner is
> created to handle events from the given EventPipeline (e.g. the one of
> the CommandManager).
> 
> Then in the run() method the PipelineRunners are executed in parallel by
> using the PooledExecutor: m_executor.execute( nextRunner );
> 
> But in the PipelineRunner.run() method, and the
> CommandManager.handleEvents() which is called by it, no new threads are
> started.

The PooledExecutor has a group of threads associated with it.  In fact the
executor is what creates/reuses/manages the threads.  The CommandManager
does not have to create the threads itself.  If you set the THreadManager
(which manages the threads in the PooledExecutor) to use a certain number
of threads, it will use them all.  You are never limited to only one thread.
I usually keep two worker threads per processor working all the time.

There is now also a new ThreadManager that has a thread pool (PooledExecutor)
per PipelineRunner that is registered.  I don't recommend its use just yet
because it hasn't been tested fully.  However, the CommandManager will use
as many threads as the ThreadManager will allow.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin