PROPOSAL Plan for fixing Cassandra inconsistencies #3125
Conversation
|
|
||
| This plan makes the following assumption: | ||
|
|
||
| - We are not willing to rewrite mailbox/cassandra with event sourcing |
There was a problem hiding this comment.
"because we think we can find solutions that are cheaper that, without being perfect, would allow reduce inconsistency"
That's it?
There was a problem hiding this comment.
That's it.
I would complete:
- because I think event sourcing with a cassandra tooling don't allow to realistically implement mailbox/cassandra.
There was a problem hiding this comment.
because I think event sourcing with a cassandra tooling don't allow to realistically implement mailbox/cassandra.
It would be an valid argument if we had a realistic plan B.
BTW, It's not because you don't know yet how to implement it with Event Sourcing that it's not realistic. Given the complexity of problems we have to face without Event Sourcing, I'm confident to say that it would probably be easier (but less incremental) to jump in the ES boat.
Let's see if that plan works
There was a problem hiding this comment.
It would be an valid argument if we had a realistic plan B.
I'm trying to propose a realistic (incremental) plan B given that no plan A is well specified.
There was a problem hiding this comment.
Of course.
I just want to document why we didn't consider ES so that we can challenge those reasons later.
inconsistencies.md
Outdated
| This plan makes the following assumption: | ||
|
|
||
| - We are not willing to rewrite mailbox/cassandra with event sourcing | ||
| - We will rather identify projections and how to heal them |
There was a problem hiding this comment.
what does "identify projections" mean?
There was a problem hiding this comment.
I adopted a broad definition: "data is duplicated across 2 tables"
There was a problem hiding this comment.
I can't understand the sentence: "instead of doing ES we will rather identify data that are duplicated accross at least 2 tables and how to heal them"
You probably mean "try to identify possibly inconsistent duplicated information"? Don't you?
|
|
||
| This plan makes the following assumption: | ||
|
|
||
| - We are not willing to rewrite mailbox/cassandra with event sourcing |
There was a problem hiding this comment.
because I think event sourcing with a cassandra tooling don't allow to realistically implement mailbox/cassandra.
It would be an valid argument if we had a realistic plan B.
BTW, It's not because you don't know yet how to implement it with Event Sourcing that it's not realistic. Given the complexity of problems we have to face without Event Sourcing, I'm confident to say that it would probably be easier (but less incremental) to jump in the ES boat.
Let's see if that plan works
inconsistencies.md
Outdated
| This plan makes the following assumption: | ||
|
|
||
| - We are not willing to rewrite mailbox/cassandra with event sourcing | ||
| - We will rather identify projections and how to heal them |
There was a problem hiding this comment.
I can't understand the sentence: "instead of doing ES we will rather identify data that are duplicated accross at least 2 tables and how to heal them"
You probably mean "try to identify possibly inconsistent duplicated information"? Don't you?
inconsistencies.md
Outdated
|
|
||
| (prioritized) this section present the conclusion of this studu which details can be found below. | ||
|
|
||
| ## Grooming |
There was a problem hiding this comment.
Does that mean "we still have to figure out what are performance characteristics of LWT and counters"?
There was a problem hiding this comment.
More: does the performance cost of LWT have a real impact for us.
There was a problem hiding this comment.
LWT -> "lightweight transactions" right? (tried to catch up on those^^)
inconsistencies.md
Outdated
|
|
||
| # Details | ||
|
|
||
| ## mailbox/mailboxPath |
There was a problem hiding this comment.
Could we have a classical structured analysis:
- problem statement "tables X, used to get x from y, and table Y, used to get x from z, are written in the following ordering ... that could lead to entries written in ... but not ... The impacts are ..."
- solutions: "we can use ... as a source of truth to fix ... assuming ... limitations are ..."
- implementation: ...
There was a problem hiding this comment.
I will rework the form tommorrow if you wish.
Hopefully we'll have a debate on the merits.
inconsistencies.md
Outdated
|
|
||
| (prioritized) this section present the conclusion of this studu which details can be found below. | ||
|
|
||
| ## Grooming |
There was a problem hiding this comment.
LWT -> "lightweight transactions" right? (tried to catch up on those^^)
| `mailbox` (op1) to remove it from `mailboxPathV2` (op2) and finally we update the `mailbox` to reference it with | ||
| new path (op3). If op1, op2 or op3 fails, we have an entry conflict that might require merging the mailboxes. | ||
| - Delete: We remove the `mailbox` entry, and finally the `mailboxPathV2`. If partially applied, | ||
| then we can have an orphan `mailboxPathV2`. The corresponding mailbox don't exist, but can't either be created. |
There was a problem hiding this comment.
don't we have a design issue here? mailboxPathV2 should be a projection but keep the truth about the existence of the mailbox. While mailbox is the main table which can be used to rebuild the projection(s) but is not seen as the table of truth.
There was a problem hiding this comment.
That's a specificity here yes. Sounds like the source of truth is mailbox as it contains the UID_VALIDITY. Also an immutable identifier sounds like also a desirable property from a source of truth.
Nevertheless we have an invariant on the name that we need to apply. That's why all of this looks a bit brittle.
But the good news is that's it is a behavior that only happen for mailboxes.
There was a problem hiding this comment.
now that we see there are issues related, see https://issues.apache.org/jira/browse/JAMES-3074 what about having UID_VALIDITY in the mailboxPath table instead?
There was a problem hiding this comment.
Also an immutable identifier sounds like also a desirable property from a source of truth
(you won't solve all the issues).
There was a problem hiding this comment.
Putting another domain object into the mailboxPath table, then I wonder is this still be mailboxPath or something else? like mailbox metadata....
There was a problem hiding this comment.
Naming here is the least of my concerns ;-)
…stencies by using the search index
No description provided.