activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Lusk (JIRA)" <>
Subject [jira] Commented: (AMQ-677) ActiveMQ broker leaks advisory topics
Date Fri, 07 Apr 2006 22:12:48 GMT
    [ ] 

Andrew Lusk commented on AMQ-677:

Adding this line:

next.removeDestination(context, AdvisorySupport.getConsumerAdvisoryTopic(info.getDestination()),

below the fireAdvisory call in AdvisoryBroker::removeDestination appears to solve this problem,
but at the cost of a very severe performance decrease.  

Would really appreciate traction from someone more familiar with this particular code.

> 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
>  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