activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arthur Naseef (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-5557) GC of inactive queues should happen even if consumers > 0
Date Mon, 02 Feb 2015 04:33:34 GMT

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

Arthur Naseef commented on AMQ-5557:
------------------------------------

As I mentioned on the USER mail list, it seems odd to want to remove a destination that has
a consumer.  Consumers that sit idle on destinations the application knows will never be used
sounds like a consumer leak to me.

Also note that the broker works better with fewer, more static destinations rather than destinations
that are frequently created and removed.  There is a fair amount of overhead to destination
creation and removal.

Please help me to understand the use-case better.

> GC of inactive queues should happen even if consumers > 0 
> ----------------------------------------------------------
>
>                 Key: AMQ-5557
>                 URL: https://issues.apache.org/jira/browse/AMQ-5557
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.10.1
>            Reporter: Kevin Burton
>
> In my app we use lots of ephemeral queues which are active for a while, and then become
inactive.
> Queue GC is very important for us.
> Right now , there is no safe way to use queue GC in this scenario if any future messages
could come into the queue.  Even if there's a low probability of this happening.
> Ideally the way this would work is if the queue is empty, and nothing is written to it
for the inactiveTimoutBeforeGC interval than it is GCd... regardless of the number of consumers
and producers.
> If producers/consumers WANT to disconnect, they can listen to advisory messages that
the queue has been GCd and then disconnect when the advisory message says that the queue has
been destroyed.
> Trying to emulate this by disconnecting yields tons of potential race bugs.
> For example, if you have a 60 second window, and you have no messages written, so you
close your consumer, it's totally possible that 1 message comes in 1ms after you disconnect.
> You would have no way of knowing this.  This message would stay there, not consumed ,
forever.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message