You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Luca Zago <lu...@iolabs.it> on 2006/10/25 17:56:03 UTC
Memory Leak in Mina
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?
Thanks in advance,
Luca
Re: Memory Leak in Mina
Posted by Luca Zago <lu...@iolabs.it>.
I am using JProfiler, and I ran the tests in two different days, on
different computer,
and it gave me the same results, the number of instances of
edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$Node
are never garbage collected and always increasing with time.
Luca
Mark Webb ha scritto:
> good information. What profiler are you using?
>
> On 10/25/06, Luca Zago <lu...@iolabs.it> 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?
>> Thanks in advance,
>>
>> Luca
>>
>
Re: Memory Leak in Mina
Posted by Mark Webb <el...@gmail.com>.
good information. What profiler are you using?
On 10/25/06, Luca Zago <lu...@iolabs.it> 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?
> Thanks in advance,
>
> Luca
>
Re: Memory Leak in Mina
Posted by Luca Zago <lu...@iolabs.it>.
ok, I will try to do the following tests, this night, in Italy it's
night already.
I will do a 'sending' session of 3000 messages for 4 different clients
at the same time, then I will check the amount of instances,
I will leave the application without load, for some time, and then check
again if the system released the objects.
If it is not so, I think there is a problem, correct? In that case I
will try to print the references to the classes which held the objects.
I will share with you the results. And I will try the JDK 6.
Thanks again,
Luca
Holger Hoffstaette ha scritto:
> On Wed, 25 Oct 2006 20:52:32 +0100, Robert Greig wrote:
>
>
>> On 25/10/06, Luca Zago <lu...@iolabs.it>
>> wrote:
>>
>>> I don't know how to interpret this behavior, but these objects after one
>>> night of running tests are the majority in the application.
>>>
>> Is it definitely a leak? If you look at the code in the ExecutorFilter you
>> can see that it add events for that session - e.g. data read from the
>> network - and those events are processed in order for the session by a
>> thread from the pool.
>>
>
> That was my question as well - in Mule's case Luca reported a leak in a
> similar event handler, yet after looking at the source in question I could
> not see how that leak could actually ever happen because items are always
> removed via take(), regardless of errors etc. Considering that the
> backport's LinkedBlockingQueue is a straight 1:1 port and tested with the
> JSR 166 tck suite I'd be more than surprised if there really was a bug
> somewhere. It's just a fancy single-linked list after all.
> IMHO it's much more likely that there's something fishy with JProfiler or
> the way Luca uses it. (I've never used JProfiler)
>
> Luca, if you can please try the same tests with JDK 6 and use jhat (part
> of the Mustang tools). It will show you exactly how many live objects are
> held by which owner.
>
> Holger
>
>
>
>
Re: Memory Leak in Mina
Posted by Holger Hoffstaette <ho...@wizards.de>.
On Wed, 25 Oct 2006 20:52:32 +0100, Robert Greig wrote:
> On 25/10/06, Luca Zago <lu...@iolabs.it>
> wrote:
>> I don't know how to interpret this behavior, but these objects after one
>> night of running tests are the majority in the application.
>
> Is it definitely a leak? If you look at the code in the ExecutorFilter you
> can see that it add events for that session - e.g. data read from the
> network - and those events are processed in order for the session by a
> thread from the pool.
That was my question as well - in Mule's case Luca reported a leak in a
similar event handler, yet after looking at the source in question I could
not see how that leak could actually ever happen because items are always
removed via take(), regardless of errors etc. Considering that the
backport's LinkedBlockingQueue is a straight 1:1 port and tested with the
JSR 166 tck suite I'd be more than surprised if there really was a bug
somewhere. It's just a fancy single-linked list after all.
IMHO it's much more likely that there's something fishy with JProfiler or
the way Luca uses it. (I've never used JProfiler)
Luca, if you can please try the same tests with JDK 6 and use jhat (part
of the Mustang tools). It will show you exactly how many live objects are
held by which owner.
Holger
Re: Memory Leak in Mina
Posted by Robert Greig <ro...@gmail.com>.
On 25/10/06, Luca Zago <lu...@iolabs.it> wrote:
> I don't know how to interpret this behavior, but these objects after one
> night of running tests are the majority in the application.
Is it definitely a leak? If you look at the code in the ExecutorFilter
you can see that it add events for that session - e.g. data read from
the network - and those events are processed in order for the session
by a thread from the pool.
Have your clients all finished running and is the system in a steady
state? If so then yes it looks like a problem. If not then it just
looks like your server app is unable to keep up.
RG
Re: Memory Leak in Mina
Posted by Luca Zago <lu...@iolabs.it>.
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
>
>
>
>
Re: Memory Leak in Mina
Posted by Holger Hoffstaette <ho...@wizards.de>.
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