I'm currently profiling the broker for other leaks
cheers,
Rob
On 9 Apr 2006, at 02:29, Andrew Lusk (JIRA) wrote:
[ https://issues.apache.org/activemq/browse/AMQ-677?page=all ]
Andrew Lusk reopened AMQ-677:
-----------------------------
I got a fresh snapshot of trunk after your latest patch, and tested
it with the code I attached above. It still exhibits this memory
bloat problem, after several thousand iterations. Did this code
work for you with this fix?
Also, the fix that was put in only removes consumer advisory
topics, when producer advisory topics are just as much of a
problem. The fix will also crash when info == null (when I
mentioned putting that line in just after the fireAdvisory call, I
meant still within the checked info != null block).
The code I provided was a stopgap solution that caused other
serious problems for me (and maybe only worked because I was a few
weeks back from trunk). In my tree I'm going with the second thing
I mentioned (not creating advisory topics for temporary
destinations) which is working fine for me while I work on
investigating some other issues that have come up with higher
numbers of iterations.
ActiveMQ broker leaks advisory topics
-------------------------------------
Key: AMQ-677
URL: https://issues.apache.org/activemq/browse/AMQ-677
Project: ActiveMQ
Type: Bug
Components: Broker
Environment: linux, near-trunk version of ActiveMQ
Reporter: Andrew Lusk
Assignee: Rob Davies
Fix For: 4.0 RC3
Attachments: ProducerTool.java
When I run the attached code, which AFAIK is completely legal JMS,
the ActiveMQ broker grows to 500+ mb and crashes due to being out
of heap space.
Some investigation with hprof has lead me to believe that the
advisory topics created by the MessageConsumers (and Producers,
but I use the same producer each time so that's not causing a
problem) are being put into a DestinationMap and not being removed.
The rough origin of this is in the addProducer call in
AdvisoryBroker, which creates the advisory topic.
Note that this memory is not freed when the DestinationInfo
removing the original temptopic is received, nor when the actual
client exits. The object lifetime of these advisory destinations
seems very poorly defined. If they are implicitly created by the
server, they should be implicitly destroyed by the same.
To reproduce, I've been running this code with -Dtopic=true and -
Dmax=10000 (though the problem shows up well before this amount).
This is just a modified version of the example ProducerTool (note
it doesn't actually send any messages).
Please verify the correctness of the attached code.
Andrew Lusk
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
