Cassandra Store, Impurge, Imexpire, And Imcheck -s Q&A (Doc ID 2938337.1)

Last updated on MARCH 28, 2023

Applies to:

Goal

Using: Messaging Server 8.1.0.9.0 version with Cassandra Message Store

Regarding: Cassandra, impurge, imexpire, and imcheck -s

Qn1: It is assumed that the maintenance database is now kept in Cassandra - is that correct? Which index would that be?

Qn2: Is there an opportunity for problems with the impurge processes on different backend (access tier) systems doing maintenance activities on the same folder at the same time or being stuck waiting for a lock held by the impurge process on another backend and then repeating the same work again once the lock is freed/acquired?

Qn3: With classic store (BDB), "imcheck -s" could be used to determine if processes/threads are stalled waiting for a lock and which process/thread is holding that lock. How would that be done with Cassandra?

Qn4: Regarding imquotacheck, there are imsched tasks that run imquotacheck 3 times per day. It would not be prudent for this to run on every access tier system.
Similarly, there are scripts that generate reports. Those are also run by imsched. It would be optimal for them to run once per cluster, not once on every access tier system.

It is known that Cassandra does not use RDBMS ACID transactions with rollback or locking mechanisms, but instead offers atomic, isolated, and durable transactions with eventual/tunable consistency, so that obviates the problem of processes crashing while holding a lock. Or if not, how is that addressed in the Cassandra store?

It was assumed imexpire would only run on one node, because when it starts simultaneously on multiple nodes, only one instance will acquire the lock.
But if Cassandra doesn't really have "locking", how does that work? And is there any way the same mechanism can be used to prevent internal reporting scripts from running on every node of the cluster?
 

Solution