Thanks for the confirmation!
It looks like the code is capable of handling the data in unsorted order
with assertions disabled; so for the time being I will disable the
assertion for my tests, until the fixes are available.
Thanks,
Soumava
On Mon, Jul 22, 2013 at 1:33 AM, Sylvain Lebresne wrote
Actually, your second stack trace is due to
https://issues.apache.org/jira/browse/CASSANDRA-5788.
On Mon, Jul 22, 2013 at 9:37 AM, Sylvain Lebresne wrote:
>
> unless data was stored in incorrect order and I don't know if that is
>> possible through the API..
>>
>
> That's exactly what happens a
> unless data was stored in incorrect order and I don't know if that is
> possible through the API..
>
That's exactly what happens and that's why I say it's a bug.
>
> ii. I am also seeing some sporadic cases where a single column cas()
> update is hitting this same issue (the bug you mentioned
Thanks for the reply Sylvain! A couple of follow-up questions:
i. The second stack in my mail originated at a getRow() call. What could be
the cause of that? I am assuming data retrieval should not cause any
issues, unless data was stored in incorrect order and I don't know if that
is possible thr
This is a bug really: https://issues.apache.org/jira/browse/CASSANDRA-5786.
This should get fixed in the next beta of 2.0, but if you really want to
test CAS updates in the meantime, you'll have to provide the columns in
(column family comparator) sorted order to the thrift cas() method.
--
Sylva
Hi,
I'm taking a look at the Check and Set functionalities provided by the
cas() API provided by cassandra 2.0 (the code available on git). I'm
running a few tests on a small sized cluster (replication factor 3,
consistency level quorum) with a few clients. I've observed a lot of cases
seem to hit
