activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hans Bausewein (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQ-1979) Temporary queue on slave not removed in Pure Master/Slave setup
Date Wed, 15 Oct 2008 14:35:52 GMT

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

Hans Bausewein commented on AMQ-1979:
-------------------------------------

Maybe it's removed later by some other cleanup method?

The application, where I've found it is running in JBoss and I suppose JBoss keeps the open
connection in a pool, so then the temporary destinations are not removed.

Problem is that it causes a difference between the master and the slave: on the master the
queue is removed, but on the slave it still exists.
I can reproduce that with this code.

I don't have a problem with this issue anymore, because I've fixed our client code, but I
suppose the same error will be made again and will keep causing headaches. (it was worse in
our case, because the exception on the failing delete attempt was not logged)




> Temporary queue on slave not removed in Pure Master/Slave setup
> ---------------------------------------------------------------
>
>                 Key: AMQ-1979
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1979
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.2.0
>            Reporter: Hans Bausewein
>            Assignee: Gary Tully
>         Attachments: activemqjee-0.0.6-src.tar.gz
>
>
> Maybe not the most logical client code, but it happened here and I guess it will happen
somewhere again:
>   TemporaryQueue reply = session.createTemporaryQueue();      	
>   MessageConsumer consumer = session.createConsumer(reply);
>   Message received = consumer.receive(timeout);
>   ...
>   reply.delete();
>   consumer.close();
> I've removed try/finally blocks to keep it simple.
> See the attached source code.
> It works fine, but set 
>   JmsMessageHandler.REVERSE_ORDER=true
> and the slave will not be cleaned up properly.
> It means that the number of threads is increasing and at some time it will get an OutOfMemoryError
(see AMQ-1849) and the slave dies.

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