-
Bug
-
Resolution: Done
-
Major
-
AMQ 7.10.0.GA
This problem affects large messages published using an AMQP client, and consumed also using an AMQP client.
It only (so far as I can tell) affects broker mesh operation – I cannot reproduce it on a single broker. In addition, it only reproduces when there has been a fail-over between the brokers, with the consumer connected.
My test produces 10 000 messages to a single queue, and consume 10 000 messages. Both the producer and the consumer are at all times connected to the same broker, but the brokers are shut down alternately during the test, so both producer and consumer transfer from one broker to the other.
At the end of the test, `artemis queue stat` reveals no messages in any queue on either broker, and yet there will always be at least a few files in `large-messages/` in one or both brokers. In the worst cases, I have seen over a thousand files stranded in `large-messages/`.
I must stress that no messages are lost – the test does not complete until all messages are sent and received. The test applications keep track of the number of messages, so there is no doubt. The problem is that, over time, huge numbers of files can accumulate in `large-messages/`, and they are not removed.
They can't be removed manually, because some of these files will correspond to real messages, that are waiting to be consumed; there is no easy way to tell which files correspond to real messages, and which do not.
- is cloned by
-
ENTMQBR-7771 [LTS] large-messages/ folder starts to collect duplicate messages after a broker failover, which are never removed
-
- Closed
-