[
https://issues.apache.org/jira/browse/AMQ-5557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14300871#comment-14300871
]
Arthur Naseef commented on AMQ-5557:
------------------------------------
{quote}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.
{quote}
Look at message TTLs. That's the best way to address timeouts. If there's a
need to ensure no message is ever missed (i.e. once it is produced, the
application *must* get a response), then I highly recommend an architectural
review.
> 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)
