activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Lusk (JIRA)" <>
Subject [jira] Reopened: (AMQ-677) ActiveMQ broker leaks advisory topics
Date Sun, 09 Apr 2006 01:29:50 GMT
     [ ]
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