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.