-
Bug
-
Resolution: Not a Bug
-
Major
-
None
-
AMQ 7.8.2.GA
-
None
-
False
-
False
-
-
Customer reports:
Ran the following test scenario to test Expiration for MQTT with settings below
<auto-delete-queues>true</auto-delete-queues> <auto-delete-addresses>true</auto-delete-addresses> <auto-delete-created-queues>true</auto-delete-created-queues> <auto-delete-queues-message-count>0</auto-delete-queues-message-count> <auto-delete-queues-delay>360000</auto-delete-queues-delay>
Also set acceptor to delete sessions
defaultMqttSessionExpiryInterval=360000
- Ran test with 140,000 clients connected (35,000 per broker)
- Stopped test
- Let expiration complete for broker (2.5 hours)
- Ran test again with same client load
- Stopped test
- Let expiration complete for broker (2.5 hours)
- Ran test again with same client load
- Let expiration complete for broker (2.5 hours)
- Captured logs, heap and thread dumps
Expectation
After each expiration complete and test was run again, similar results should follow since all addresses, queues and messages should have expired.
Observations
Notification queue backed up exponentially after each test. Connections reduced after each test. While Addresses, Queues, Messages, Sessions should have expired there are remnants of data from previous test runs.
- is related to
-
ENTMQBR-4653 Introduce Capability To Time Out and Remove Offline Durable Subscribers (Including MQTT)
- Closed
- relates to
-
ENTMQBR-5393 [LTS] Introduce Capability To Time Out and Remove Offline Durable Subscribers (Including MQTT)
- Closed