directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rohita <>
Subject Re: [MINA] Apparent DEADLOCK in com.mchange.v2.async.ThreadPoolAsynchronousRunner
Date Fri, 21 Nov 2008 19:11:58 GMT

Hi All,

I am having the same problem of APPARENT DEADLOCK
I am very new to Java.
I am Hibernate3 and c3p0
Data base i am using is MySQL.

Please help me out as i am not able to find out which settings i have to
change to remove this deadlock,
Whenever this deadlock comes site goes down and because of this i am loosing
traffic from site

Here is the stack trace for my error

09:29:04,924  WARN ThreadPoolAsynchronousRunner:608 -
AsynchronousRunner$DeadlockDetector@2f922e72 -- APPARENT DEADLOCK!!!
Creating emergen
cy threads for unassigned pending tasks!
09:29:04,926  WARN ThreadPoolAsynchronousRunner:624 -
AsynchronousRunner$DeadlockDetector@2f922e72 -- APPARENT DEADLOCK!!!
Complete Status:
        Managed Threads: 3
        Active Threads: 3
        Active Tasks: 
sk@b3249a2 (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1)
        Pending Tasks: 


Alessandro Torrisi wrote:
> I want to refer to a standard library, so if the patch becomes official 
> it's better ! I understood this patch improves performance...
> I wait for your moves before modify it myself.
> Bye,
> Alex
> wrote:
>> I have had a similar problems implementing broadcast, and I have 
>> modified the ByteBuffer of MINA 8.0 making a method of
>> asReadOnly() that create a java.nio.ByteBuffer from the asReadOnly of 
>> the wrapped nio.buffer.
>> The problem is that the readOnly will share the original byte[] or 
>> direct array, so I had hacked the mina bytebuffer just a little in 
>> this way:
>> In the MINA byteBuffer.asReadOnly() I create a new mina 
>> DefaultByteBuffer container and get into that the nio.buffer copy and 
>> the reference to the original mina bytebuffer, and a boolean flag that 
>> says if the DefaultByteBuffer wrap a readOnly copy or a real writable 
>> nio.bytebuffer. I do an aquire() of the original MINA byteBuffer.
>> So when the MINA ByteBuffer copy is released, the release method just 
>> look at the flag and release the original mina bytebuffer.
>> The MINA bytebuffer copy _must_ be not pooled obviusly.
>> In this way there is no need to make a copy of the data, but only a 
>> new nio.bytebuffer that use the same byte[] or direct array, and the 
>> original ByteBuffer will be released only when all the copies will be 
>> already written to the channel.
>> If you'd like it I can modify the MINA ByteBuffer of the 9.1 in the 
>> same way, it shouldn't be hard.
>> by Fed
>>     ----- Original Message -----
>>     *From:* Trustin Lee <>
>>     *To:* Apache Directory Developers List
>>     <>
>>     *Sent:* Friday, January 13, 2006 1:21 AM
>>     *Subject:* Re: [MINA] Apparent DEADLOCK in
>>     com.mchange.v2.async.ThreadPoolAsynchronousRunner
>>     Hi Alex,
>>     2006/1/12, Alessandro Torrisi <
>>     <>>:
>>         I use a buffer size of 2048 bytes...not so much
>>         Can you explain me this better ? Can I do something to improve
>>         or it's simply a fact ?
>>     Could you try to turn off the 'pooled' property of the buffers
>>     when you broadcast:
>>     buf.setPooled(false);
>>     Please let me know if this helps.  And please make sure you increased
>>     the direct buffer size as we suggested in the FAQ section.
>>     HTH,
>>     Trustin
>>     -- 
>>     what we call human nature is actually human habit
>>     --
>>     PGP Key ID: 0x854B996C 

View this message in context:
Sent from the Apache Directory Project mailing list archive at

View raw message