[
https://issues.apache.org/jira/browse/ARTEMIS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15592730#comment-15592730
]
Justin Bertram commented on ARTEMIS-745:
----------------------------------------
When the broker delivers a message to a core consumer it no longer tracks that
message from an expiration stand-point. The core client has logic to determine
if the message is expired at the time it invokes receive().
If a consumer is closed then any unacknowledged messages that have been
delivered to it will be cancelled back to the broker and expired as necessary
at that point.
So, from a core perspective everything seems to be working as expected.
When a STOMP subscription is created on a topic the broker generates both a
queue to receive those messages as well as a server-side consumer which
basically acts the same way as described above as far as I can tell.
If you still feel there is a problem please supply a real, reproducible
test-case that conclusively demonstrates the issue. This could be a modified
version of one of the examples we ship or even better would be a new test in
{{org.apache.activemq.artemis.tests.integration.stomp.StompTest}}.
> Messages sent to a jms topic address are not expiring in temporary queue
> created via core API
> ---------------------------------------------------------------------------------------------
>
> Key: ARTEMIS-745
> URL: https://issues.apache.org/jira/browse/ARTEMIS-745
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 1.1.0
> Environment: Redhat Linux 6.2
> Reporter: Ruben Cala
> Assignee: Justin Bertram
>
> I am publishing messages to a topic address (jms.topic.<address>). I set the
> message expiration to be 2 seconds (publishing via core api). I have two
> consumers, one using core api, one using generic stomp protocol. The core
> api creates a temporary queue to receive the messages from the address. The
> stomp consumer relies on the auto-generated temporary queue mechanism
> provided by the broker. To investigate slow consumer scenarios, both
> consumers are not acknowledging the messages.
> In JConsole for the stomp consumer, its queue MessagesAcknowledged attribute
> count rises, while the MessageCount stays constant with the MessagesAdded
> count (low number around 5 usually).
> For the core api consumer, however, its queue MessagesAcknowledged attribute
> count stays at 0, while its MessageCount attribute increases with the
> MessagesAdded number. This eventually causes the broker to run out of memory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
