Signed-off-by: Matteo Cafasso <[email protected]>

Signed-off-by: Matteo Cafasso <[email protected]>

Signed-off-by: Matteo Cafasso <[email protected]>

Signed-off-by: Matteo Cafasso <[email protected]>

The deduplication cache was created on the node where the
resource (exchange or queue) was initialized.

If the node crashed and was replaced mnesia could not recover or
recreate the table used as a cache.

After several attempts, it seems the best way to prevent this from
happening is to replicate the table over more nodes to ensure mnesia
can recover it in case of a node disappearing.

To ensure safe enough persistence without replicating too
aggressively, the cache is created on 2/3 of the total cluster nodes.

Signed-off-by: Matteo Cafasso <[email protected]>

RabbitMQ classic queue supports both transient and persistent messages
on the same queue. If a node where a queue relies crashes, transient
messages will be lost whereas persistent will remain.

It is unfortunately non-trivial from the plugin to access to
presistent messages at recover. On the other side, persisting
deduplication headers would be dangerous as we might deduplicate lost
transient messages forever in case of recovery.

The easiest solution is, for now, to flush the cache at startup.

Signed-off-by: Matteo Cafasso <[email protected]>

Signed-off-by: Matteo Cafasso <[email protected]>

Signed-off-by: Matteo Cafasso <[email protected]>