cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kyle Gibson <>
Subject Re: Occasionally getting old data back with ConsistencyLevel.ALL
Date Mon, 22 Aug 2011 16:49:03 GMT
I made some changes to my code base that uses cassandra. I went back
to using the "processed" column, but instead of using "0" or "1" I
decided to use "no" and "yes"

You can view the code here:

As you can see from the code, I perform an insert, get, check the
result, if it didn't work, I try to insert again, and check the get.
Each time I do a print out to see what the result is. Each operation
is a CL.ALL.

A few successful IPNs did come through before this one was generated:

OrderedDict([..., (u'processed', u'no'), ...])
Failed to set processed to yes
IPN-5943a4adc8eab68cdbc9d9eff7fa7dc669fa0bce insert 1314012603578714
Failed to set processed to yes
IPN-5943a4adc8eab68cdbc9d9eff7fa7dc669fa0bce insert2 1314012603586201

As expected, this IPN was processed twice.

On Sat, Aug 20, 2011 at 5:37 PM, Peter Schuller
<> wrote:
>> Do you mean the cassandra log, or just logging in the script itself?
> The script itself. I.e, some "independent" verification that the line
> of code after the insert is in fact running, just in case there's some
> kind of silent failure.
> Sounds like you've tried to address it though with the E-Mail:s.
> I suppose it boils down to: Either there is something wrong in your
> environment/code, or Cassandra does have a bug. If the latter, it
> would probably be helpful if you could try to reproduce it in your
> environment in a way which can be shared - such as a script that does
> writes and reads back to confirm the write made it. Or maybe just
> adding more explicit logging to your script (even if it causes some
> log flooding) to "prove" that a write truly happened.
> --
> / Peter Schuller (@scode on twitter)

View raw message