Hello Raphael. You mention risk of cancelling a legitimate action that could have been taken as an inconsistency.
To prevent that, a strategy based on delays could be effective as well: - Detect all the inconsistencies - Wait long enough to be sure ongoing operations are finished. 2 times the Cassandra driver time out should be enough. - Confirm the inconsistency - Then fix it. (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. Regards, Benoit > > Regards, > > Raphaël. > > Le 19/02/2020 à 09:10, Tellier Benoit a écrit : >> Hello Raphael, >> >> The simple fix could be : >> >> - 1. Iterating the in memory list of record >> - 2. For each record, refresh it (re read it from DB to be sure to have >> the latest version of it) >> - 3. Then detect inconsistencies (reading the associated >> denormalization table) >> >> Step 2., currently not implemented in [1], could be a way to mitigate >> these risks. >> >> [1] Solving mailbox inconsistencies: >> https://github.com/linagora/james-project/pull/3110 >> >> That way you decrease the concurrency window to the maximum. >> >> Cheers, >> >> Benoit >> >> On 18/02/2020 23:50, Raphaël Ouazana-Sustowski wrote: >>> Hello, >>> >>> Is there a way to solve inconsistencies while not adding new ones? >>> >>> When you solve inconsistencies, you have a view of data in memory and >>> try to fix it. If the data change between the moment you take this view >>> and the moment you try to fix the inconsistency, you risk to add an >>> other inconsistency, or worst to cancel a legitimate action. >>> >>> Do you see a way to mitigate this risk? >>> >>> Regards, >>> >>> Raphaël. >>> >>> Le 14/02/2020 à 11:06, Đức Trần Tiến a écrit : >>>> Hello people, >>>> >>>> In recent days, James had been recieved a report about the strage >>>> *MailboxNotFoundException*. There were some investigation to find the >>>> cause >>>> of the issue. >>>> We found that there are some inconsistent between mailbox and >>>> mailboxPathV2 >>>> tables. The issue is considered critical and it and bother/annoying >>>> users >>>> to creates, rename, delete mailboxes. >>>> I had open a PR for demonstrate this problem in unit test >>>> https://github.com/linagora/james-project/pull/3100. There are some >>>> taken >>>> actions to be resolving the mailbox inconsistencies. >>>> >>>> But look back to the bigger picture, there're many tables have close >>>> relationships, mailbox and mailboxPathV2 is just an example. There are >>>> several proposals to prevent inconsistent but some have not been >>>> discussed >>>> further than an idea: >>>> >>>> - Introducing a *transaction* bounded with cassandra (it can >>>> systematically resolve the issue) >>>> - Re write the MailboxManager by *EventSourcing* >>>> - Having tools to fix the already existing inconsistent >>>> >>>> *Having tools to fix the already existing inconsistent* >>>> >>>> We have: >>>> - Webadmin Task for solving inconsistent cassandra mappings >>>> - A self healing MessageFastViewProjections >>>> >>>> In developement: >>>> - Webadmin Task for solving inconsistent mailbox & mailboxPath >>>> - Retrying on failed mailbox creation/deletion >>>> >>>> I want to bring this conversation to the mailling list and hope that >>>> we can >>>> contribute solutions, enrich the proposals in order to reduce/fix the >>>> cassandra inconsistencies. >>>> >>>> Thank you! >>>> >>>> Tran Tien Duc >>>> >>> --------------------------------------------------------------------- >>> 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 >> >> > > --------------------------------------------------------------------- > 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
