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
