You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "René Cordier (Jira)" <se...@james.apache.org> on 2021/01/05 05:01:00 UTC

[jira] [Commented] (JAMES-3407) Read repair for mailbox denormalisation

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

René Cordier commented on JAMES-3407:
-------------------------------------

https://github.com/linagora/james-project/pull/4184 do not test read repair on outdated schema version

> Read repair for mailbox denormalisation
> ---------------------------------------
>
>                 Key: JAMES-3407
>                 URL: https://issues.apache.org/jira/browse/JAMES-3407
>             Project: James Server
>          Issue Type: Improvement
>          Components: cassandra, mailbox
>            Reporter: Benoit Tellier
>            Priority: Major
>             Fix For: 3.6.0
>
>
> = Why
> Following this ADR https://github.com/apache/james-project/pull/248
> Mailbox inconsistencies requires manual intervention of the admin (via the solve-inconsistency webadmin endpoint) to be resolved.
> Having such task to ensure a correct denormalisation state is desirable, but optimally we should not have to rely on the admin to remember running it.
> We would prefer an auto-healing solution
> = Context
> Read repair is a classic mechanism in eventual consistent databases (like cassandra) to piggy back consistency healing operation upon reads.
> A fraction of the reads will have a wider reach, read more data, and ensure it is correctly replicated.
> Cassandra eventual consistency is all about "replication", but "denormalization" consistency needs to be handled at the applicative layer. In the past we did set up "Solve inconsistency" tasks that can be assimilated to Cassandra repairs. In order to achieve denormalization auto-healing, we thus needs to implement "applicative read repairs".
> = Technically speaking
> Upon reads, for each mailbox, the mailbox mapper have a configurable random chance to trigger read repairs.
> In this case both table are read, and the "solve inconsistency" mechanism is applied, if needed.
> Write unit tests demonstrating this "solve inconsistency" behaviour.
> Also read repairs are the missing bit to make the "read only mailboxPath" optimization viable: development needs to happen on top of https://github.com/linagora/james-project/pull/3635 ` POC Denormalize UidValidity as part of MailboxPath projection` branch
> = Definition Of Done
> Record a video : 
>  - Given a read repair chance of 0.2 (20%)
>  - There is a mailbox inconsistency (no OUTBOX) - (remove the mailbox entry manually in cassandra)
>  - The user does many requests - after some time, the inconsistency is fixed: he has an OUTBOX again!
> As an admin, I should be able to configure (or disable) the read-repair-chance for the mailbox entity



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org