cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Cocoon hang in excalibur-pool
Date Fri, 16 Dec 2005 15:39:40 GMT
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


> 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

View raw message