cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: Cocoon hang in excalibur-pool
Date Fri, 16 Dec 2005 07:34:18 GMT
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'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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
>

Mime
View raw message