Earlier I reported the following bug against C* 2.0.5
https://issues.apache.org/jira/browse/CASSANDRA-7176
It seems to be fixed in C* 2.0.7, but we are still seeing similar
suspicious timeouts.
We have a cluster of C* 2.0.7, DC1:3, DC2:3
We have the following table:
CREATE TABLE conditional_updat
ote:
> On Mon, May 5, 2014 at 2:03 PM, Mohica Jasha wrote:
>
>> Our prod deployment:
>>
>> C* 2.0.5, DC1:3, DC2:3
>>
>
> Not directly related to your bug report, which I would file an Apache JIRA
> regarding, but...
>
> https://engineering.eventbrite.com/what-version-of-cassandra-should-i-run/
>
> =Rob
>
>
Most likely it is the following query:
DELETE from conditional_update_lock where resource_id = '${myresourceid}' IF
lock_id = ${myuuid};
We are using datastax 2.0.1 and the datastax threw a ReadtimeoutException
On Mon, May 5, 2014 at 5:03 PM, Mohica Jasha wrote:
> forgot
forgot to say which Cassandra version we are using.
Our prod deployment:
C* 2.0.5, DC1:3, DC2:3
On Mon, May 5, 2014 at 5:01 PM, Mohica Jasha wrote:
> one query in our prod system under heavy load failed.
> I cant tell which query it was. But I don't think we were using
one query in our prod system under heavy load failed.
I cant tell which query it was. But I don't think we were using an invalid
consistency level since our configuration work all the time except when it
goes under heavy load.
If I can reproduce this I will pass more information.
I wonder if this
There is a discrepancy between the two documentation:
http://wiki.apache.org/cassandra/Durability
Cassandra's default configuration sets the commitlog_sync mode to periodic,
> causing the commitlog to be synced every commitlog_sync_period_in_ms
> milliseconds,
> so you can potentially lose up to
I have been testing against C* 2.0.1. It turned out that the bug is
resolved in C* 2.0.2.
On Fri, Nov 15, 2013 at 12:57 PM, Robert Coli wrote:
> On Fri, Nov 15, 2013 at 7:10 AM, Mohica Jasha wrote:
>
>> Cassandra 2.0.2 does not persist the map collection when I specify an
>
Cassandra 2.0.2 does not persist the map collection when I specify an
if-not-exists clause in the insert operation:
cqlsh:mohica>CREATE TABLE simple (id1 TEXT, ,my_map MAP,PRIMARY
KEY (id1));
cqlsh:mohica>INSERT INTO simple(id1,my_map) VALUES
('id1',{'a1':'b1','a2':'b1'}) if not exists;
[applied
Querying a table with 5000 thousands tombstones take 3 minutes to complete!
But Querying the same table with the same data pattern with 10,000 entries
takes a fraction of second to complete!
Details:
1. created the following table:
CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy
Hey,
I created a table with a wide row. Query on the wide row after removing the
entries and flushing the table becomes very slow. I am aware of the impact
of tombstones but it seems that there is a deadlock which prevents the
query to be completed.
step by step:
1. creating the keyspace and the
10 matches
Mail list logo
