directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessandro Torrisi <alessandro.torr...@eurone.it>
Subject Re: [MINA] Apparent DEADLOCK in com.mchange.v2.async.ThreadPoolAsynchronousRunner
Date Wed, 11 Jan 2006 10:43:53 GMT
Yes I'm using c3p0 with hibernate, so I think it's directly managed by 
Hibernate...
How can I do to free ByteBuffers much more as possible ?
With 2000 opened IoSessions I have about 312 Mb of ram busy.
When I receive chat messages I see memory occupation to grow...Is there 
some natural mina
activity I'm losing during reading/writing operations ?

I switched from 10 threads to 5 threads yesterday, it seems to change 
very little.
But I don't have an optimal view of the performance cause Java 
implementation on
Mac Os X is very slow...

The applications main behaviour is to communicate in "blocks", slow, 
then fast, then again slow,
it is not constant. How can be avoided this ?

I know that probably performance it's not the main target of this 
mailing list, but if a network
application is not performant as you well know, it is not used if there 
are many alternatives.
I have to understand if it's a physical architectural limit of Java/Mina 
before seriously going on.

However I can say my application has improved from the beginning ! 
Thanks too this mailing list !

Bye, Alex

Justin Rudd wrote:

>>>Hi ! Yesterday I put in stress my direct connect hub software on Mac
>>>Os X 10.3.4 Tiger with latest Java implementation.
>>>Max fake users reached number is 2500. When I reached this number the
>>>application has thrown this exception:
>>>      
>>>
>
>[snip]
>
>  
>
>>>com.mchange.v2.async.ThreadPoolAsynchronousRunner
>>>$DeadlockDetector@27d98b -- APPARENT DEADLOCK!!! Creating emergency
>>>threads for unassigned pending tasks!
>>>      
>>>
>
>Are you using c3p0?  I haven't done an exhaustive look through the
>source of 0.8.x, but that package prefix - com.mchange - looks like
>c3p0 to me.  If so, are you releasing all your connections?  Because
>c3p0 by default will use some background threads to clean things up. 
>It will spin them off to try and find connections it can use, create
>new connection for clients that are waiting for them, etc.  So if you
>aren't cleaning all your resources up, it will keep spinning off
>threads which will cause it to run out of memory.
>
>If you aren't using c3p0, what other client libraries are you using?
>
>--
>Justin Rudd
>"Get the facts first.  You can distort them later."
>   - Mark Twain
>http://seagecko.org/thoughts/
>  
>


Mime
View raw message