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