The test scenario is pretty much the same as the other JIRA: ENTMQ-801.

Producers: 800 MQTT clients connect to the Broker with cleanSession=false, create ~40 subscriptions each, and start publishing messages of 1.5KB in size, at the frequency of 1 msg every 30 sec or so. Publishers are running in a local Ubuntu box connected to the Internet through Ethernet on our company network.

Consumers: 5 MQTT clients connect to the Broker, create ~10 subscriptions each matching all messages published by the Producers, and very rarely publish a larger message (10KB) randomly addressed to one of the Producers.

So here is test steps:

1. A first test is run where each producer publishes few thousand messages and then disconnect.

1. Consumers receive all expected messages (although a big slow) and remain connected.

1. Without restarting the broker, the producers are restarted.
   They reconnect and start creating their subscriptions.

At this point, the broker memory and cpu increase and quickly the JVM starts doing Full GC. The CPU reaches 100% and the broker gets into a halt state of constant Full GC cycles over and over again. Then most likely, broker will throw OOM error with "GC limit excceeded" message.