activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dejan Bosanac (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (AMQ-2706) Memory leak & huge thread count in broker
Date Fri, 07 May 2010 15:53:47 GMT

    [ https://issues.apache.org/activemq/browse/AMQ-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59252#action_59252
] 

Dejan Bosanac edited comment on AMQ-2706 at 5/7/10 11:52 AM:
-------------------------------------------------------------

Fixed with svn revision 942131.

The problem was with destination infos not being propagated to the remote broker, so temp
destination were kept lingering.

However, I think your solution with new temp queue for every message is not optimal, and you
should use one temp queue and correlation id. See http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html
for more info

      was (Author: dejanb):
    Fixed with svn revision 942131.

The problem was with destination infos not being propagated to the remote broker, so temp
destination were kept lingering.

However, I think you're solution with new temp queue for every message is not optimal, and
you should use one temp queue and correlation id. See http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html
for more info
  
> Memory leak & huge thread count in broker
> -----------------------------------------
>
>                 Key: AMQ-2706
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2706
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.3.1
>         Environment: Linux ubuntu/Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02,
mixed mode)
>            Reporter: Andres
>            Assignee: Dejan Bosanac
>             Fix For: 5.4.0
>
>         Attachments: memtest.zip, snapshot6.png, snapshot7.png
>
>
> I'm using request/replay pattern where client on BrokerA  creates message and start listening
response from temporary-queue, consumer listening on BrokerB, after getting message it sends
respond back to the temporary queue.
> After getting message back, client on BrokerA removes temporary queue and closes session
and closes connection
> Now if I take a look to the jmx then everythink is OK on BrokerA side. No hangig tmp
queues no too many threads. On BrokerB every message lives hanging temporary queue and thread.
Even if I shut down BrokerA there are still hanging tmp queue on brokerB and one extra thread.
> Now if I send 10k messages from BrokerA there is 10K temporary quest and 10K threads
on brokerA
> Example setup:
> | Broker A  <NetworkConnector duplex=true> | ----->  |  Broker B |

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message