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
Hello Duc, answers inlined.
On 14/02/2020 17:06, Đức Trần Tiến wrote:
> 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 bet
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 inc
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 impleme
Hi,
What do you think about `.setFetchSize()` to 1 or a number small enough?
This helps to avoid re-read and by the same time, the whole process
requires only one connection to read from a table.
The cassandra documentation dis-encourage this practice because of its poor
performance. But we're exp
I was not knowing this pattern.
I would not use it as it prevents concurrent execution.
(You can very well refresh and check entries in parrallel to go faster)
On 19/02/2020 16:38, Đức Trần Tiến wrote:
> Hi,
> What do you think about `.setFetchSize()` to 1 or a number small enough?
> This helps
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/
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
Hello,
Le 20/02/2020 à 03:22, Tellier Benoit a écrit :
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 eno
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 t
10 matches
Mail list logo