Hi,
We are upgrading our 1.0 Cassandra installation to 1.2 (via 1.1), and had
Cassandra 1.2.5 running in test for a while.
Everything seems fine except that exceptions like below come sporadically,
without correlating with anything else. They *seem* to come during work hours,
so it can be that
This is potentially just a bad query. It looks like
ThriftValidation#validateFilterClauses just checks the indexes and values
are of the right type and does not compare actual values. In other words,
the query could have made it that far with a bad comparison value.
What exception are you getting
That's good news.
But the thing is - I don't have the client exception, so I cannot tell if this
is what really happens.
I checked the logs for each of our client applications, but no exceptions, so
the only other possibility is that someone manually runs a bad query. It's
possible, but still a
Quite a bit, IIRC. The thrift methods get_range_slices and get_index_slices
where merged under the hood to share a code path.
On Mon, Aug 19, 2013 at 9:50 AM, tamas.fold...@thomsonreuters.com wrote:
That’s good news.
But the thing is – I don’t have the client exception, so I cannot tell
Meant to put this in up top, but if you are upgrading, it would behoove you
to upgrade to the latest 1.2.8 (
https://github.com/apache/cassandra/blob/cassandra-1.2/CHANGES.txt)
On Mon, Aug 19, 2013 at 9:57 AM, Nate McCall n...@thelastpickle.com wrote:
Quite a bit, IIRC. The thrift methods
I've got a 3-node cassandra cluster (16G/4-core VMs ESXi v5 on 2.5Ghz
machines not shared with any other VMs). I'm inserting time-series data
into a single column-family using wide rows (timeuuids) and have a
3-part partition key so my primary key is something like ((a, b, day),
How big are the batch sizes? In other words, how many rows are you sending
per insert operation?
Other than the above, not much else to suggest without seeing some example
code (on pastebin, gist or similar, ideally).
On Mon, Aug 19, 2013 at 5:49 PM, Keith Freeman 8fo...@gmail.com wrote:
I've
Sure, I've tried different numbers for batches and threads, but
generally I'm running 10-30 threads at a time on the client, each
sending a batch of 100 insert statements in every call, using the
QueryBuilder.batch() API from the latest datastax java driver, then
calling the Session.execute()
I'd suggest using prepared statements that you initialize at application
start up and switching to use Session.executeAsync coupled with Google
Guava Futures API to get better throughput on the client side.
On Mon, Aug 19, 2013 at 10:14 PM, Keith Freeman 8fo...@gmail.com wrote:
Sure, I've
