inconsistencies happened and check corresponding Cassandra logs to see what
happened.
--
Jacques-Henri Berthemet
From: Mahdi Ben Hamida [mailto:ma...@signalfx.com]
Sent: Monday, February 12, 2018 8:45 PM
To: user@cassandra.apache.org
Subject: Re: LWT broken?
On 2/12/18 2:04 AM, Jacques-Henri Berthemet
met*
*From:* DuyHai Doan [mailto:doanduy...@gmail.com]
*Sent:* Sunday, February 11, 2018 6:11 PM
*To:* user
*Subject:* Re: LWT broken?
Mahdi , the issue in your code is here:
else // we lost LWT, fetch the winning value
9 existing_id = SELECT id FROM hash_id WHERE hash=computed_hash |
consistency
.
Regards,
--
Jacques-Henri Berthemet
From: DuyHai Doan [mailto:doanduy...@gmail.com]
Sent: Sunday, February 11, 2018 6:11 PM
To: user
Subject: Re: LWT broken?
Mahdi , the issue in your code is here:
else // we lost LWT, fetch the winning value
9existing_id = SELECT id FROM hash_id WHERE hash
Mahdi , the issue in your code is here:
else // we lost LWT, fetch the winning value
9existing_id = SELECT id FROM hash_id WHERE hash=computed_hash |
consistency = ONE
You lost LWT, it means that there is a concurrent LWT that has won the
Paxos round and has applied the value using QUORUM/SE
Totally understood that it's not worth (or it's rather incorrect) to mix
serial and non serial operations for LWT tables. It would be highly
satisfying to my engineer mind if someone can explain why that would
cause issues in this particular situation. The only explanation I have
is that a non
If you want consistent reads you have to use the CL that enforces it.
There’s no way around it.
On Fri, Feb 9, 2018 at 2:35 PM Mahdi Ben Hamida wrote:
> In this case, we only write using CAS (code guarantees that). We also
> never update, just insert if not exist. Once a hash exists, it never
> c
In this case, we only write using CAS (code guarantees that). We also
never update, just insert if not exist. Once a hash exists, it never
changes (it may get deleted later and that'll be a CAS delete as well).
--
Mahdi.
On 2/9/18 1:38 PM, Jeff Jirsa wrote:
On Fri, Feb 9, 2018 at 1:33 PM, M
On Fri, Feb 9, 2018 at 1:33 PM, Mahdi Ben Hamida wrote:
> Under what circumstances would we be reading inconsistent results ? Is
> there a case where we end up reading a value that actually end up not being
> written ?
>
>
>
If you ever write the same value with CAS and without CAS (different c
Hi Stefan,
I was hoping we could avoid the cost of a serial read (which I assume is
a lot more expensive than a regular read due to the paxos requirements).
I actually do a serial read at line #9 (ie, when we lose the LWT and
have to read the winning value) and that still fails to ensure the
I'd not recommend using any consistency level but serial for reading
tables updated by LWT operations. Otherwise you might end up reading
inconsistent results.
On 09.02.18 08:06, Mahdi Ben Hamida wrote:
>
> Hello,
>
> I'm running a 2.0.17 cluster (I know, I know, need to upgrade) with 46
> nodes
10 matches
Mail list logo
