[ 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
