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
references,
I don't know how to interpret this behavior, but these objects after one
night of running tests are the majority in the application.
Regards,
Luca
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
