The messages will be released when they are acked.
Maybe there's a bug on clearing the queues. Can you check on trunk and raise an issue if that's the case?
The other point of note is that there is descrepancy between the number of MSG files in the largemessage folder and the number of messages in the DLQ. This seems to be accounted for by only some of the messages being actually large while others are small.
I'll try to replicate the scenario with a test example.
Please, try replicating it with trunk
Actually it looks instead that every minute we are publishing a new set of messages on the topics. However these are staying in the largeMessage folder and never being removed. This is odd behaviour for topic messages - is it possible that there is an effect caused by TTL?
In the jmx view I see that this:
There are 5 nondurablesubscriptions but the core addresses (presumably per subscriber) are shown as type Queue:
I've been able to replicate the scenario using the HornetQ trunk .
Every minute we publish a JMS topic message which is (20k size). There are five subscribers receiving the topic messages - these are shown in the JMX as non-durable subscriptions.
So every minute 5 msg files appear in the largemessages folder and these never disappear.
If we turn on zero-persistence with the persistence-enabled in the configuration then the problem is solved but it means also that our queues that need to be persistent will lose that also.
So the question is - why are the topic message files staying in the folder after being read?
I'm attaching a modified HornetQ example based on the topic selector that replicates the problem but those two Jira entries effectively describe the problem. In our example we are regularly publishing topics with selectors but our consumers may not have started or may stop. Jira#431 is this I presume - I cannot add my example test case to the Jira.
We publish large topics that do not have any consumers and hence they accumulate. A restart does not clear them out
The workaround is to set the min-message-size larger than the messages being pushed - is this due to be fixed?