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?
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
