activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Davies <>
Subject Re: [jira] Reopened: (AMQ-677) ActiveMQ broker leaks advisory topics
Date Sun, 09 Apr 2006 17:57:30 GMT
I'm currently profiling the broker for other leaks


On 9 Apr 2006, at 02:29, Andrew Lusk (JIRA) wrote:

>      [ ]
> 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:
>>      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:
>> 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:
> -
> For more information on JIRA, see:

View raw message