Lo que está viendo es una interacción entre el comportamiento ActiveMQ message store y que por durable subscriptions on topics.
Cuando tiene suscripciones duraderas, un tema se trata como una cola para el ID de cliente de cada suscriptor (establecido en el Connection). La lógica es que el cliente no quiere perder ningún mensaje cuando se desconectan. Entonces, si se desconectan, la subscripción duradera se mantiene y mantiene vivos los mensajes.
El almacén de mensajes AMQ utiliza los registros de datos para su diario de mensajes. Estos se escriben de forma secuencial, y nunca se eliminan (esto requeriría acceso aleatorio). Hay un segundo archivo que realiza un seguimiento de los mensajes que se han consumido. Una vez que se han consumido todos los mensajes en un archivo de datos, ese archivo se elimina.
Lo que está viendo es que algunos de los mensajes en el archivo de datos no están siendo consumidos por estas suscripciones duraderas y simplemente se quedan. ClientIds para que los suscriptores duraderos no se usen consistentemente causaría este problema. Es probable que exista algún problema con la forma en que se usa la característica, si usa JMX para inspeccionar las suscripciones en el intermediario, lo que debería ayudarlo a rastrear la causa raíz.
Como regla general, cada vez que piense que es posible que desee utilizar una suscripción duradera, use virtual topics en su lugar: son mucho más fáciles de razonar, inspeccionar y cargar el saldo. Por otro lado, si solo desea obtener los últimos dos mensajes cuando vuelva a conectar un suscriptor de tema en lugar de todos los mensajes que se haya perdido, use retroactive consumers.
Una forma fácil de evitar este problema es siempre use a time to live cuando envía un mensaje: casi todos los casos de uso tienen un límite de tiempo en el que un mensaje debe consumirse de todos modos. ActiveMQ caducará mensajes más allá de este punto y liberará los mensajes en los archivos de datos para su eliminación.