cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Cocoon hang in excalibur-pool
Date Fri, 16 Dec 2005 17:03:06 GMT
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

Mime
View raw message