Hello Raphael, On 20/02/2020 14:35, Raphaël Ouazana-Sustowski wrote: > Hello, >
[...] > > > I don't see how you expect waiting for some time on one node of a > distributed system can help. Distributed concensus cannot be resolved > just by waiting some time on one node. > > >> - Confirm the inconsistency >> - Then fix it. > > > You still have the exact same window of error: between "confirm the > inconsistency" and "fix it" a concurrent operation can happen, either on > the same server, or on an other one. We agree on that, However, given the hypothesis that "a mailbox creation is time bounded", then we will be certain at the moment we "confirm" that the concurrent "mailbox creation" did complete. The "confirm" phase will then be able to distinguish inconsistencies from concurrent valid operations. I "forgot" to mention the hypothesis of validity in which the statement of previous email is valid. I'm sorry about it because I believe it ease the understanding of the above proposal. To discuss its limitation, a kill-the-world GC can very well invalidate it, causing a write to take longer that the aformentioned wait delay. That's why I agree with you that "no 'triking' can protect us from all possible errors". (I admit there are errors, I'm not pretending to come up with an approach that systematically solves any error.) > > Telling that the solution is pretty simple, if you can "fix it" in a > lightweight transaction assuring your assumption is correct. > > >> (night is generally of good advice) >> >> >> On 19/02/2020 23:27, Raphaël Ouazana-Sustowski wrote: >>> Hello, >>> >>> My main concern is that trying to solve some inconsistencies, we risk to >>> introduce some incorrectness. >>> >>> Your proposal is probably reducing the window of error, but it >>> potentially adds errors where we had only inconsistencies. Do we accept >>> that trade-off? >> An inconsistency is an error in itself, so I am. > > > IMHO not the same kind of error. An inconsistency is an error that has > been reported to the user. Here we can potentially blindly change some > valid data without warning the user. > > > Regards, > > Raphaël. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
