Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of bloritsch@d-haven.org designates
 65.212.180.79 as permitted sender)
Message-ID: <43A333FA.6030303@d-haven.org>
Date: Fri, 16 Dec 2005 16:39:06 -0500
From: Berin Loritsch <bloritsch@d-haven.org>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
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>
 <43A2F34A.30000@reverycodes.com>
In-Reply-To: <43A2F34A.30000@reverycodes.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Vadim Gritsenko wrote:

> 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? :)


Does the cocoon:// URL call a pipeline you are using in another segment 
of your overall pipeline?  Recursion in the pipeline calling stack can 
lead to locks.

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

Are you sure?