[ 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: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org