AMQ must start cleanly in reasonable time and with modest memory, however large the journal

Artemis has difficulties starting when there are large numbers of journal files, that is, when there is a large message backlog. "Large" in this case typically means gigabytes. The broker might need more memory to read the journal than can reasonably be allocated, or it might take so long to process the journal that the critical analyser kills the broker.

The critical analyser can be turned off, and more memory can – up to a point – be allocated. However, for all customers these interventions are inconvenient, and for some they are unsuccessful. The situation is particularly painful on OpenShift, where the relevant configuration parameters are not easily modified after installation.

While we all recognize in principle that the broker should be used to store large amounts of data, in practice the situation does arise, and it arises frequently. A common scenario is the failure of whatever it is that is supposed to be consuming messages, leading to a long-term accumulation.

Earlier paging is a solution for some installations, but this does not help customers whose designs rely on selectors, message groups, or message priorities, because these features do not work on paged data. In designs like this, data must be stored in the journal.

ENTMQBR-5987 is a request for some sort of compaction of the journal. Maybe this is a way forward, but there might be other ways. In any case, we really need to have some way to prevent customers' brokers getting into a state where they will not restart.