You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by rohita <ro...@411web.com> on 2008/11/21 20:11:58 UTC
Re: [MINA] Apparent DEADLOCK in
com.mchange.v2.async.ThreadPoolAsynchronousRunner
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 <ma...@gmail.com>
>> *To:* Apache Directory Developers List
>> <ma...@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
>> <ma...@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.
Re: [MINA] Apparent DEADLOCK in com.mchange.v2.async.ThreadPoolAsynchronousRunner
Posted by Emmanuel Lecharny <el...@gmail.com>.
How can it be connected to Directory ? The initial problem, back in
2006, was related to MINA, which was then a subprojet to Directory.
If you have a problem with MINA, just post to the MINA mailing list.
>From the stack trace you are posting, I don't think this is even a
MINA poblem, so please post to the mailing list which is associated
with the tools you ar eusong.
Thanks !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com