Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43A2F34A.30000@reverycodes.com>
Date: Fri, 16 Dec 2005 12:03:06 -0500
From: Vadim Gritsenko <vadim@reverycodes.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Cocoon hang in excalibur-pool
References: <43A21058.7020606@dslextreme.com>
 <43A23A61.3040501@reverycodes.com> <43A26DFA.7090006@dslextreme.com>
 <43A2DFBC.8040209@reverycodes.com> <43A2E73E.5000408@dslextreme.com>
In-Reply-To: <43A2E73E.5000408@dslextreme.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ralph Goers wrote:
> OK. I'm wondering if the real problem is simply that the getDocument 
> method is completely synchronized?

It's *good*. You don't really want several threads trying to load *same* document.

It's not perfect though. I see that XMLFileModule, when used in conjunction with 
cocoon:// protocol, might be a bit ... inefficient.

Usage of DelayedValidity is prescribed here. Do you want to make a stab at 
implementing delay: protocol? :)


> As far as pools go, I feel like a complete idiot.  See my comments below.
> 
> Vadim Gritsenko wrote:
> 
>> Ralph Goers wrote:
>>
>>> Thanks Vadim. I'm posting this back to the Cocoon list as it seems 
>>> what you are telling me is that the problem is either with the 
>>> XMLFileModule or with running out of components in the pool on the 
>>> pipeline being invoked.
>>>
>>> What I am not clear on is what you are trying to tell me in the last 
>>> paragraph.  Are you saying that the deadlock can be avoided by 
>>> configuring the components being used in the target pipeline 
>>> differently?
>>
>> I've not looked into pool source code yesterday to double check all 
>> points myself. I'm suggesting you to check:
>>
>>   * What type of pool is really used
> 
> Where is that specified?  I know you can specify what type of pipeline 
> you want but where is the type of pool configured?

Follow the stacktrace. Who created pool decides, and I bet that's not something 
which is configured anywhere. See the source code.


>>   * Why it is blocking (I guessed it is blocking due to resource 
>> exhaustion)
> 
> My guess is that the requests are simply coming in faster than 
> XMLFileModule is taking to release the lock.

That's not important, IMHO. Problem is in pool's lock, not XMLFileModule's lock.


>>   * If it's hard limiting pool - why it's not soft limiting pool
> 
> Again - is that configured somewhere?

Don't think so.


>>   * Try increasing pipes pool size for a quick fix
> 
> I assume you mean on the components in the pipeline?  I've never seen a 
> reference before to pipelines themselves being pooled.

public abstract class AbstractProcessingPipeline
         extends AbstractLogEnabled
         implements ProcessingPipeline, Parameterizable, Recyclable {

See that Recyclable? Now try in sitemap:

<map:pipe
   name="caching"
   pool-max="1024"
   src="org.apache.cocoon.components.pipeline.impl.CachingProcessingPipeline">


> Thanks Vadim, and I apologize if some of these seem like really lame 
> questions to you.

Yup.

Vadim