Benoit Tellier created JAMES-4221:
-------------------------------------
Summary: Limits of Cassandra counters
Key: JAMES-4221
URL: https://issues.apache.org/jira/browse/JAMES-4221
Project: James Server
Issue Type: Improvement
Reporter: Benoit Tellier
h3. Why ?
I am I think reaching limits of Cassandra counters with a customer.
They operate a flacky Cassandra cluster causing me tons of headaches with
COUNTERS being one of them.
Despite regular runs of Recompute quota we cannot get a converging run onto the
actual SUM stored in source-of-truth tabled>
h3. Cassandra counter limits
- Not idempotent - not our issue here but worth a not - please note that it is
inherant to the act of counting: in case of error we are stuck under or over
counting.
- Not "SET' semantic. We can only add or remove. The Recompute quota above
does a read-before-write to offset the previous value.
Inherently the counter stores a set of increments per master nodes - if the set
of values is inconsistent within the cluster, we take the offset decision off a
wrong value thus making the count persistently screwed up.
h3. Alternatives
Not using counter is not an option as we would be subject to data races.
LWT usage is out of question for performance reasons.
h3. Redis design
Implement a redis cache atop the Read of the data in source of truth table.
Once coputed this cache is maintained via a mailbox listener by writes.
We could do this for both:
- current-quota via a backend-commons implem of the currentQuotaManager
interface
- Have an interface defined for mailbox-counters in mailbox-store and in
mailbox-redis have an implementation of it.
h3. State of this work
I'd like to potentially propose a POC to my customer to validate it fixes his
issues prior merging this upstream.
Though I am interested by feedback.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
