Messages killed due to XA rollback result in inaccurate size metrics

1. Create a broker using default settings 2. Edit the address-settings for the catch-all address filter to set redelivery-delay and max-redlivery-delay to 0 (to reproduce more quickly) <address-setting match= "#" > <dead-letter-address> DLQ </dead-letter-address> <expiry-address> ExpiryQueue </expiry-address> <redelivery-delay> 0 </redelivery-delay> <redistribution-delay> 0 </redistribution-delay> <max-redelivery-delay> 0 </max-redelivery-delay> <max-size-bytes> -1 </max-size-bytes> <message-counter-history-day-limit> 10 </message-counter-history-day-limit> <address-full-policy> PAGE </address-full-policy> <auto-create-queues> true </auto-create-queues> <auto-create-addresses> true </auto-create-addresses> <auto-create-jms-queues> true </auto-create-jms-queues> <auto-create-jms-topics> true </auto-create-jms-topics> <auto-delete-queues> false </auto-delete-queues> <auto-delete-addresses> false </auto-delete-addresses> </address-setting> 3. Produce messages to a queue on the broker, then consume with an XA-transacted openwire client that rolls back each transaction. The attached spring-boot application runs an non-transacted producer and transacted consumer that throws an exception, forcing an XA rollback. To run, extract to the same host as the broker (or modify the jmsSource property in application.properties to point to the desired host) and execute with java -jar camel-springboot-activemq-xa-1.0-SNAPSHOT.jar 4. As messages are killed and go to the DLQ, observe the size attributes on the queue (delivering size, persistent size, etc). They go negative as the application runs