[
https://issues.apache.org/jira/browse/JAMES-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17212363#comment-17212363
]
Matthieu Baechler commented on JAMES-3406:
------------------------------------------
>> Could you explain why multi-dc + LOCAL_QUORUM + LOCAL_SERIAL is a bad idea?
> Because the transaction (and strong consistency) only happens within a DC
> with such a solution, as far as I understand.
> Maybe I need to add more details here?
Yes, I have the same analysis. However, it's probably the only scalable setup.
If we want to have a scalable mail server we should dig that solution.
>> Actually I think it's because we really want UID generation to be monotonic
>> to avoid re-assigning a mail uid but writing it in the doc could help to
>> workaround that particular topic, with for example a very different uid
>> generation implementation that would rely on in-memory datastructure.
> Got the point. However change to Uid Validity means full resynch.
I don't get the link between changing the implementation of uid generation and
invalidating some uidvalidity. In-memory in my sentence where not about
"transient information" but rather "fast to synchronize vs Cassandra LWT". Yes,
I'm being nostalgic of ZooKeeper uid generator.
> From what I saw it results to a Fetch of the MessageId headers.
> While doable in theory, in practice it would likely result in an inefficient
> solution.
> Maybe a shortcut here is stating that IMAP don't scale multi-DC but the JMAP
> can (as it is a more modern protocol) without major data loss (other than
> flags).
> What do you think?
I think that we could ensure that without IMAP we are really scalable than
tackle the IMAP scalability issue.
> Documentation page - distributed James consistency model
> --------------------------------------------------------
>
> Key: JAMES-3406
> URL: https://issues.apache.org/jira/browse/JAMES-3406
> Project: James Server
> Issue Type: Improvement
> Components: cassandra, Documentation, elasticsearch, guice, rabbitmq
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.6.0
>
>
> Document, in a dedicated section of the new documentation website the
> consistency model
> (`/docs/modules/servers/pages/distributed/architecture/consistency-model.md`)
> - Data Replication
> - Words about Cassandra consistency model
> - Words about ElasticSearch consistency model
> - Discourage General usage Cassandra MultiDC set-up (because of
> Lightweight Transaction)
> - De-normalization
> - Which data is denormalized ?
> - What can go wrong (denormalization inconsistencies) ?
> - `Solve Inconsistency tasks`
> - Applicative read repairs
> - Consistency across data stores
> - Write to object storage first, then position Cassandra meta-data
> - Cassandra <=> ElasticSearch: point to the EventBus (async, retries,
> dead-letter) + reIndex
> - Recovering RabbitMQ mailQueue from the Cassandra projection
> Don't forget to point/reuse existing ADRs !
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
