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
m seeing that under 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
. 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
> allocate an id for a given
c), 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 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 tryin
11 matches
Mail list logo