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: http://pastebin.com/gRBC16e7 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: IPN-5943a4adc8eab68cdbc9d9eff7fa7dc669fa0bce 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 <peter.schul...@infidyne.com> 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) >
