[jira] [Commented] (JAMES-4221) Limits of Cassandra counters

["vincent royer (Jira)" <se...@james.apache.org>]

    [ https://issues.apache.org/jira/browse/JAMES-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18124602#comment-18124602 ] 

vincent royer commented on JAMES-4221:
--------------------------------------

Cassandra counter are notoriously flaky in all versions of Cassandra (conception and implementaton are both wrong).

I managed to fix that with my own version of Cassandra, a custom secondary index, and a custom CQL schema for james, so I think it won't help you a lot :(

> 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
>            Priority: Major
>
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org