activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manuel Teira (JIRA)" <j...@apache.org>
Subject [jira] Created: (AMQ-1297) Memory leak creating temporary queues
Date Tue, 26 Jun 2007 14:38:32 GMT
Memory leak creating temporary queues
-------------------------------------

                 Key: AMQ-1297
                 URL: https://issues.apache.org/activemq/browse/AMQ-1297
             Project: ActiveMQ
          Issue Type: Bug
          Components: Broker
    Affects Versions: 4.1.1
            Reporter: Manuel Teira
         Attachments: amq.zip

After observing severe memory leaks in our production servers, eventually finishing with the
JVM GC running intensively and activemq dropping connections due to inactivity (and even out
of memory errors), we have proceeded in the following way, trying to isolate the error cause:

1.-Create a single client to be able to produce the same effect on an standalone activemq
broker (our servers are actually embedding a broker, but for the sake of clarity, we thought
it should be better to isolate the broker in a dedicated JVM). In the first test code, the
client just used a group of threads to create sessions, send a message on a producer created
on that session, and expect a return message in a consumer, created on a temporary queue of
the given session, setted as jmsReplyTo to the message. Later, we find out that we didn't
need to send any message to produce the memory leak. I'm attaching the code of the client,
that summarizing, does the following:
 * es.tid.planb.test.JMSBug <queue> <threads> <iters>
   - Creates a connection to the broker and starts it.
   - Creates <threads> threads. Each thread does, <iters>/<threads> times:
       - Creates a session
       - Creates a producer on <queue>, a temporary queue and a consumer on this temporary
queue.
       - Closes the session and the temporary queue.
       (Note that it doesn't need to send any message for the leak to show)
   - Wait for all the threads to finish, and closes the connection.


2.-We tested the client against:
 activemq 4.1.1
 activemq 4.1-SNAPSHOT (apache-activemq-4.1-20070615.012351-63.tar.gz)
 activemq 4.2-SNAPSHOT (apache-activemq-4.2-20070607.230602-81.tar.gz)

 Using the Sun JVMs:
 1.5.0_07
 1.5.0_11
 1.6.0

running on Sun UltraSparc, solaris 9 architecture.

Using the configuration that I'm also attaching to this mail. It uses a openwire and an stomp
connector (just to resemble our failing scenario), and a oracle datasource (anyway, we have
reproduced the same leaks using the derby bundled database).


3.-We observed the following facts:
 -The memory consumption grows up, and doesn't get lower, even after the clients finishes
(and even forcing the Garbage Collector to run).
 - Looking at jmap heap histograms, it seems that a lot of objects are not released (org.apache.activemq.broker.region.Topic)
being among them.
- Disabling the advisoryTopic support in the broker leads to a less severe leakage, but anyway,
unacceptable for our requisites.
- Using the Derby embedded database, the heap growed to similar sizes.
- activemq 4.2-SNAPSHOT seems to leek less memory, but is still severe enough (and produced
for us even worse problems (AMQ-1296)
- Commenting out the creation of the temporary queue and the consumer on it seems to avoid
the leakage.
- The amount of memory leaked doesn't seem related with the number of threads the client uses
to do its job. The only difference is the time involved as you can see in the included charts.

4.-I'm sending you the following information.
- The source code of the test program (JMSBug.java)
- The activemq xbean configuration (activemq.xml)
- The heap sizes and histograms for the following cases:
   * Just after starting activemq (histo-startup and heap-startup)
   * After starting, running JMSBug (with threads=1 iters=20000) and forcing the GC from the
JMX console (histo-1-20000 and heap-1-20000).
   * After starting, running JMSBug (with threads=50 iters=20000) and forcing the GC from
the JMX console (histo-50-20000 and heap-50-20000).
- A pair of screenshots of the heap chart after running both tests. (jmx-heap-1-20000.png
and jmx-heap-50-20000.png) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message