directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rohita <ro...@411web.com>
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 -
com.mchange.v2.async.ThreadPool
AsynchronousRunner$DeadlockDetector@2f922e72 -- APPARENT DEADLOCK!!!
Creating emergen
cy threads for unassigned pending tasks!
09:29:04,926  WARN ThreadPoolAsynchronousRunner:624 -
com.mchange.v2.async.ThreadPool
AsynchronousRunner$DeadlockDetector@2f922e72 -- APPARENT DEADLOCK!!!
Complete Status:
 
        Managed Threads: 3
        Active Threads: 3
        Active Tasks: 
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTa
sk@b3249a2 (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1)
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTa
sk@1280306c
(com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2)
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTa
sk@1deb0bf1
(com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0)
        Pending Tasks: 
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTa
sk@325d0a8f
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTa
sk@7a604c1d
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask@482542af
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask@63d142a
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask@13f6d499
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask@31ff930c
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask@20f1279
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask@2b85c6fd
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask@5bcb225d
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask@753d36bf
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask@5d571bb
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask@1daefb
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask@1ccae0cc
               
com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask@4b6c7fd8

Thanks
Rohit



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
> 
> fedechicco@gmail.com 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 <mailto:trustin@gmail.com>
>>     *To:* Apache Directory Developers List
>>     <mailto:dev@directory.apache.org>
>>     *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 <alessandro.torrisi@eurone.it
>>     <mailto:alessandro.torrisi@eurone.it>>:
>>
>>         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
>>     --
>>     http://gleamynode.net/
>>     PGP Key ID: 0x854B996C 
>>
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-MINA--Apparent-DEADLOCK-in-com.mchange.v2.async.ThreadPoolAsynchronousRunner-tp2310251p20627848.html
Sent from the Apache Directory Project mailing list archive at Nabble.com.


Mime
View raw message