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: <43A2DFBC.8040209@reverycodes.com>
Date: Fri, 16 Dec 2005 10:39:40 -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>
In-Reply-To: <43A26DFA.7090006@dslextreme.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
   * Why it is blocking (I guessed it is blocking due to resource exhaustion)
   * If it's hard limiting pool - why it's not soft limiting pool
   * Try increasing pipes pool size for a quick fix

Vadim


> I'm wondering if the whole getDocument method needs to be synchronized 
> or whether the scope can be reduced so that it doesn't hold a lock while 
> invoking the pipeline.  This may be dumb, but I'm also wondering why the 
> inner class DocumentHelper is static when it always seems to be created 
> in getDocumentHelper with new.
> 
> Ralph
> 
> Vadim Gritsenko wrote:
> 
>> Looks like you've got a classic deadlock.
>>
>> Request (*) calls XMLFileModule which synchronizes on its internal 
>> cache, and tries to parse a document, which is coming from Cocoon 
>> pipeline, so tree processor looks up a pipeline object.
>>
>> But while this request does this, new requests are coming in, and each 
>> one of them takes one pipeline object out of the pool, and then all 
>> those requests are piling up before XMLFileModule lock.
>>
>> Pipeline pool runs out of resources, and request (*) above blocks 
>> waiting when pool gets resources back.
>>
>> But it won't.
>>
>> What I'm not clear on is IIRC component pools should use soft limiting 
>> pools, so there should be no waiting in ResourceLimitingPool. You may 
>> want to double check this.
>>
>> Vadim