mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Zago <l...@iolabs.it>
Subject Re: Memory Leak in Mina
Date Wed, 25 Oct 2006 18:28:58 GMT
yes it's an application in which I used both Mule and Mina. today I am 
trying to isolate
the modules, and I created a test application using only Mina, I will to 
the same with Mule tomorrow.
I posted the acutal results for Mina.  Is it normal that these instances 
are never garbage collected?
I am quite sure, since I 'marked' the instances after a garbage 
collected, and then checked the difference after many hours
and these difference was always increasing.I tried to check where the 
references are held, but I could not export that graph in anyway,
and the additional problem is that JProfiler   cannot find always 
instances in the heap of these objects, so not always I can 'track' the 
I don't know how to interpret this behavior, but these objects after one 
night of running tests are the majority in the application.



Holger Hoffstaette ha scritto:
> On Wed, 25 Oct 2006 17:56:03 +0200, Luca Zago wrote:
>> Hi,
>> i am doing a long testing session using a profiiler, against a simple Mina
>> application.
>> I configured simply 3 bindings on different port with the same Handler, on
>> a single SocketAcceptor.
>> The Handler simply broacast the message to all sessions connected. I am
>> using JMeter TCP Sampler, to load the application, simply connect on two
>> ports of the server and in loop send a messages to both, After many hours,
>> I am noticing a a  memory leak problem on the class
>> edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$Node.
>> It seems now that the number of instances of this class is always
>> increasing, without being released by the GC. I checked the allocation
>> references, and I see that the instances are allocated in 
>> org.apache.mina.filter.executor.ExecutorFilter, then
>> org.apache.mina.common.Executor.ThreadModel. In my configuration I didn't
>> set particular parameters for the ThreadModel, did you experience
>> something similar, some configuration can help me?
> OK, seeing that you just posted an *almost identical* message to the Mule
> list I am more than intrigued - the number of overall allocated instances
> is mostly irrelevant, what is relevant is the number of _held_ references.
> It is not surprising that the number of LinkedList nodes only goes up, but
> unless you give us more information about which GC root holds the List and
> its nodes it's impossible to tell where this leak comes from. Are you sure
> you are properly interpreting the JProfiler results?
> Holger

View raw message