RE: LWT broken?

the 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

Re: LWT broken?

[mailto:doanduy...@gmail.com] *Sent:* Sunday, February 11, 2018 6:11 PM *To:* user <user@cassandra.apache.org> *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=compute

RE: LWT broken?

. Regards, -- Jacques-Henri Berthemet From: DuyHai Doan [mailto:doanduy...@gmail.com] Sent: Sunday, February 11, 2018 6:11 PM To: user <user@cassandra.apache.org> Subject: Re: LWT broken? Mahdi , the issue in your code is here: else // we lost LWT, fetch the winning value 9existing_id =

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

Re: LWT broken?

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

Re: LWT broken?

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

Re: LWT broken?

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,

Re: LWT broken?

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

Re: LWT broken?

nder high contention, LWT may actually not guarantee uniqueness. With a total of 16 million LWT transactions (with peak LWT concurrency around 5k/sec), I found 38 conflicts that should have been impossible. I was wondering if there were any known issues that make LWT broken for this old ver

Re: LWT broken?

ng if there > were any known issues that make LWT broken for this old version of > cassandra. > > I use LWT to guarantee that a 128 bit number (hash) maps to a unique > 64 bit number (id). There could be a large number of threads trying to > allocate an id for a given hash. > >

LWT broken?

d 38 conflicts that should have been impossible. I was wondering if there were any known issues that make LWT broken for this old version of cassandra. I use LWT to guarantee that a 128 bit number (hash) maps to a unique 64 bit number (id). There could be a large number of threads trying to allo