Ralph Goers wrote:
OK. I'm wondering if the real problem is simply that the getDocument
method is completely synchronized?
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?
It is not a blocking pool, although the DataSourceComponent uses a
blocking pool. If you run out of connections, it will block.
Everything else acts like a factory when over the limit.
* 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 is a possibility--if the method being called is static or belongs
to a ThreadSafe component.
* If it's hard limiting pool - why it's not soft limiting pool
Again - is that configured somewhere?
Unless you specifically set up a pool in your own component, it is soft
limited.
