date:20121120


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500994#comment-13500994
 ] 

Daniel Strawson commented on CASSANDRA-4973:


Hi sorry about this - the column family definition I gave in the description 
was wrong - I've just checked and it was off a different machine, I'd made a 
change to caching to turn on row caching.  Could this be something to do with 
the issue?  Looking through the current schema, the column families where I've 
noticed the index disappear all are onces where I have turned caching on.  I've 
just checked a CF that I hadn't looked at before but has caching on and as 
indexes and it's giving the same issue, so whilst this isn't proof, the 
evidence points this way.

Here is the current output from 'show schema' for the CF 'region' :

create column family region
  with column_type = 'Standard'
  and comparator = 'UTF8Type'
  and default_validation_class = 'BytesType'
  and key_validation_class = 'UTF8Type'
  and read_repair_chance = 0.1
  and dclocal_read_repair_chance = 0.0
  and gc_grace = 864000
  and min_compaction_threshold = 4
  and max_compaction_threshold = 32
  and replicate_on_write = true
  and compaction_strategy = 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
  and caching = 'ALL'
  and column_metadata = [
{column_name : 'countryCode',
validation_class : UTF8Type,
index_name : 'region_countryCode_idx',
index_type : 0},
{column_name : 'label',
validation_class : UTF8Type}]
  and compression_options = {'sstable_compression' : 
'org.apache.cassandra.io.compress.SnappyCompressor'};


 Secondary Index stops returning rows
 

 Key: CASSANDRA-4973
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4973
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.2, 1.1.6
 Environment: Centos 6.3, Java 1.6.0_35, cass. 1.1.2 upgraded to 1.1.6
Reporter: Daniel Strawson

 I've been using cassandra on a project for a little while in development and 
 have recently suddenly started having an issue where the secondary index 
 stops working, this is happening on my new production system, we are not yet 
 live.   Things work ok one moment, then suddenly queries to the cf through 
 the secondary index stop returning data.  I've seen it happen on 3 CFs. I've 
 tried:
 - various nodetools repair / scrub / rebuild_indexes options, none seem to 
 make a difference.
 - Doing a 'update column family whatever with column_metadata=[]' then 
 repeating with my correct column_metadata definition.  This seems to fix the 
 problem (temporarily) until it comes back.
 The last time it happened I had just restarted cassandra, so it could be that 
 which is causing the issue, I've got the production system ok at the moment, 
 I will try restarting a bit later when its not being used and if I can get 
 the issue to reoccur I will add more information.
 The problem first manifested itself in 1.1.2, so I upgraded to 1.1.6, this 
 has not fixed it.
 Here is an example of the create column family I'm using for one of the CFs 
 that affected:
 create column family region
   with column_type = 'Standard'
   and comparator = 'UTF8Type'
   and default_validation_class = 'BytesType'
   and key_validation_class = 'UTF8Type'
   and read_repair_chance = 0.1
   and dclocal_read_repair_chance = 0.0
   and gc_grace = 864000
   and min_compaction_threshold = 4
   and max_compaction_threshold = 32
   and replicate_on_write = true
   and compaction_strategy = 
 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
   and caching = 'KEYS_ONLY'
   and column_metadata = [
 
 {column_name : 'label',
 validation_class : UTF8Type},
 
 {column_name : 'countryCode',
 validation_class : UTF8Type,
 index_name : 'region_countryCode_idx',
 index_type : 0},
 
 ]
   and compression_options = {'sstable_compression' : 
 'org.apache.cassandra.io.compress.SnappyCompressor'};
 I've noticed that CASSANDRA-4785 looks similar, in my case once the system 
 has the problem, it doesn't go away until I fix it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CASSANDRA-4973) Secondary Index stops returning rows


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500994#comment-13500994
 ] 

Daniel Strawson edited comment on CASSANDRA-4973 at 11/20/12 10:55 AM:
---

Hi sorry about this - the column family definition I gave in the description 
was wrong - I've just checked and it was off a different machine, I'd made a 
change to caching to turn on row caching.  Could this be something to do with 
the issue?  Looking through the current schema, the column families where I've 
noticed the index disappear are ones where I have turned caching on.  I've just 
checked a CF that I hadn't looked at before but has caching on and also has 
secondary indexes and it's giving the same issue, so whilst this isn't proof, 
the evidence points towards it being something to do with caching.  I will try 
turning off caching and see if the issue goes away.

Here is the current output from 'show schema' for the CF 'region' :

create column family region
  with column_type = 'Standard'
  and comparator = 'UTF8Type'
  and default_validation_class = 'BytesType'
  and key_validation_class = 'UTF8Type'
  and read_repair_chance = 0.1
  and dclocal_read_repair_chance = 0.0
  and gc_grace = 864000
  and min_compaction_threshold = 4
  and max_compaction_threshold = 32
  and replicate_on_write = true
  and compaction_strategy = 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
  and caching = 'ALL'
  and column_metadata = [
{column_name : 'countryCode',
validation_class : UTF8Type,
index_name : 'region_countryCode_idx',
index_type : 0},
{column_name : 'label',
validation_class : UTF8Type}]
  and compression_options = {'sstable_compression' : 
'org.apache.cassandra.io.compress.SnappyCompressor'};


  was (Author: dcstrawson):
Hi sorry about this - the column family definition I gave in the 
description was wrong - I've just checked and it was off a different machine, 
I'd made a change to caching to turn on row caching.  Could this be something 
to do with the issue?  Looking through the current schema, the column families 
where I've noticed the index disappear all are onces where I have turned 
caching on.  I've just checked a CF that I hadn't looked at before but has 
caching on and as indexes and it's giving the same issue, so whilst this isn't 
proof, the evidence points this way.

Here is the current output from 'show schema' for the CF 'region' :

create column family region
  with column_type = 'Standard'
  and comparator = 'UTF8Type'
  and default_validation_class = 'BytesType'
  and key_validation_class = 'UTF8Type'
  and read_repair_chance = 0.1
  and dclocal_read_repair_chance = 0.0
  and gc_grace = 864000
  and min_compaction_threshold = 4
  and max_compaction_threshold = 32
  and replicate_on_write = true
  and compaction_strategy = 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
  and caching = 'ALL'
  and column_metadata = [
{column_name : 'countryCode',
validation_class : UTF8Type,
index_name : 'region_countryCode_idx',
index_type : 0},
{column_name : 'label',
validation_class : UTF8Type}]
  and compression_options = {'sstable_compression' : 
'org.apache.cassandra.io.compress.SnappyCompressor'};

  
 Secondary Index stops returning rows
 

 Key: CASSANDRA-4973
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4973
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.2, 1.1.6
 Environment: Centos 6.3, Java 1.6.0_35, cass. 1.1.2 upgraded to 1.1.6
Reporter: Daniel Strawson

 I've been using cassandra on a project for a little while in development and 
 have recently suddenly started having an issue where the secondary index 
 stops working, this is happening on my new production system, we are not yet 
 live.   Things work ok one moment, then suddenly queries to the cf through 
 the secondary index stop returning data.  I've seen it happen on 3 CFs. I've 
 tried:
 - various nodetools repair / scrub / rebuild_indexes options, none seem to 
 make a difference.
 - Doing a 'update column family whatever with column_metadata=[]' then 
 repeating with my correct column_metadata definition.  This seems to fix the 
 problem (temporarily) until it comes back.
 The last time it happened I had just restarted cassandra, so it could be that 
 which is causing the issue, I've got the production system ok at the moment, 
 I will try restarting a bit later when its not being used and if I can get 
 the issue to reoccur I will add more information.
 The problem first manifested itself in 1.1.2, so I upgraded to 1.1.6, this 
 has not fixed it.
 Here is an example of the create column family I'm using for one of the

[jira] [Commented] (CASSANDRA-4973) Secondary Index stops returning rows


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501077#comment-13501077
 ] 

Daniel Strawson commented on CASSANDRA-4973:


I've tried setting caching back to 'KEYS_ONLY' on the region CF, restarted and 
the secondary indexes continue working, so I'm fairly happy that this issue 
relates to the caching setting.  I will revert my other CFs back to the default 
setting, which is a good enough work around for me for the moment.

 Secondary Index stops returning rows
 

 Key: CASSANDRA-4973
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4973
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.2, 1.1.6
 Environment: Centos 6.3, Java 1.6.0_35, cass. 1.1.2 upgraded to 1.1.6
Reporter: Daniel Strawson

 I've been using cassandra on a project for a little while in development and 
 have recently suddenly started having an issue where the secondary index 
 stops working, this is happening on my new production system, we are not yet 
 live.   Things work ok one moment, then suddenly queries to the cf through 
 the secondary index stop returning data.  I've seen it happen on 3 CFs. I've 
 tried:
 - various nodetools repair / scrub / rebuild_indexes options, none seem to 
 make a difference.
 - Doing a 'update column family whatever with column_metadata=[]' then 
 repeating with my correct column_metadata definition.  This seems to fix the 
 problem (temporarily) until it comes back.
 The last time it happened I had just restarted cassandra, so it could be that 
 which is causing the issue, I've got the production system ok at the moment, 
 I will try restarting a bit later when its not being used and if I can get 
 the issue to reoccur I will add more information.
 The problem first manifested itself in 1.1.2, so I upgraded to 1.1.6, this 
 has not fixed it.
 Here is an example of the create column family I'm using for one of the CFs 
 that affected:
 create column family region
   with column_type = 'Standard'
   and comparator = 'UTF8Type'
   and default_validation_class = 'BytesType'
   and key_validation_class = 'UTF8Type'
   and read_repair_chance = 0.1
   and dclocal_read_repair_chance = 0.0
   and gc_grace = 864000
   and min_compaction_threshold = 4
   and max_compaction_threshold = 32
   and replicate_on_write = true
   and compaction_strategy = 
 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
   and caching = 'KEYS_ONLY'
   and column_metadata = [
 
 {column_name : 'label',
 validation_class : UTF8Type},
 
 {column_name : 'countryCode',
 validation_class : UTF8Type,
 index_name : 'region_countryCode_idx',
 index_type : 0},
 
 ]
   and compression_options = {'sstable_compression' : 
 'org.apache.cassandra.io.compress.SnappyCompressor'};
 I've noticed that CASSANDRA-4785 looks similar, in my case once the system 
 has the problem, it doesn't go away until I fix it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4973) Secondary Index stops returning rows when caching=ALL


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Strawson updated CASSANDRA-4973:
---

Summary: Secondary Index stops returning rows when caching=ALL  (was: 
Secondary Index stops returning rows)

 Secondary Index stops returning rows when caching=ALL
 -

 Key: CASSANDRA-4973
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4973
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.2, 1.1.6
 Environment: Centos 6.3, Java 1.6.0_35, cass. 1.1.2 upgraded to 1.1.6
Reporter: Daniel Strawson

 I've been using cassandra on a project for a little while in development and 
 have recently suddenly started having an issue where the secondary index 
 stops working, this is happening on my new production system, we are not yet 
 live.   Things work ok one moment, then suddenly queries to the cf through 
 the secondary index stop returning data.  I've seen it happen on 3 CFs. I've 
 tried:
 - various nodetools repair / scrub / rebuild_indexes options, none seem to 
 make a difference.
 - Doing a 'update column family whatever with column_metadata=[]' then 
 repeating with my correct column_metadata definition.  This seems to fix the 
 problem (temporarily) until it comes back.
 The last time it happened I had just restarted cassandra, so it could be that 
 which is causing the issue, I've got the production system ok at the moment, 
 I will try restarting a bit later when its not being used and if I can get 
 the issue to reoccur I will add more information.
 The problem first manifested itself in 1.1.2, so I upgraded to 1.1.6, this 
 has not fixed it.
 Here is an example of the create column family I'm using for one of the CFs 
 that affected:
 create column family region
   with column_type = 'Standard'
   and comparator = 'UTF8Type'
   and default_validation_class = 'BytesType'
   and key_validation_class = 'UTF8Type'
   and read_repair_chance = 0.1
   and dclocal_read_repair_chance = 0.0
   and gc_grace = 864000
   and min_compaction_threshold = 4
   and max_compaction_threshold = 32
   and replicate_on_write = true
   and compaction_strategy = 
 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
   and caching = 'KEYS_ONLY'
   and column_metadata = [
 
 {column_name : 'label',
 validation_class : UTF8Type},
 
 {column_name : 'countryCode',
 validation_class : UTF8Type,
 index_name : 'region_countryCode_idx',
 index_type : 0},
 
 ]
   and compression_options = {'sstable_compression' : 
 'org.apache.cassandra.io.compress.SnappyCompressor'};
 I've noticed that CASSANDRA-4785 looks similar, in my case once the system 
 has the problem, it doesn't go away until I fix it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4977) Expose new SliceQueryFilter features through Thrift interface

2012-11-20 Thread aaa (JIRA)

aaa created CASSANDRA-4977:
--

 Summary: Expose new SliceQueryFilter features through Thrift 
interface
 Key: CASSANDRA-4977
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4977
 Project: Cassandra
  Issue Type: Improvement
  Components: API
Affects Versions: 1.2.0 beta 2
Reporter: aaa


SliceQueryFilter has some very useful new features like ability to specify a 
composite column prefix to group by and specify a limit of groups to return.

This is very useful if for example I have a wide row with columns prefixed by 
timestamp and I want to retrieve the latest columns, but I don't know the 
column names. Say I have a row
{{row - (t1, c1), (t1, c2)... (t1, cn) ... (t0,c1) ... etc}}

Query slice range (t1,) group by prefix (1) limit (1)

As a more general question, is the Thrift interface going to be kept up-to-date 
with the feature changes or will it be left behind (a mistake IMO) ?



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4977) Expose new SliceQueryFilter features through Thrift interface

2012-11-20 Thread Cristian Opris (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501124#comment-13501124
 ] 

Cristian Opris commented on CASSANDRA-4977:
---

This was posted by me but apparently was logged with an anonymous account at 
the time

 Expose new SliceQueryFilter features through Thrift interface
 -

 Key: CASSANDRA-4977
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4977
 Project: Cassandra
  Issue Type: Improvement
  Components: API
Affects Versions: 1.2.0 beta 2
Reporter: aaa

 SliceQueryFilter has some very useful new features like ability to specify a 
 composite column prefix to group by and specify a limit of groups to return.
 This is very useful if for example I have a wide row with columns prefixed by 
 timestamp and I want to retrieve the latest columns, but I don't know the 
 column names. Say I have a row
 {{row - (t1, c1), (t1, c2)... (t1, cn) ... (t0,c1) ... etc}}
 Query slice range (t1,) group by prefix (1) limit (1)
 As a more general question, is the Thrift interface going to be kept 
 up-to-date with the feature changes or will it be left behind (a mistake IMO) 
 ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Cassandra Wiki] Update of ClientOptions by MatBrown

2012-11-20 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Cassandra Wiki for 
change notification.

The ClientOptions page has been changed by MatBrown:
http://wiki.apache.org/cassandra/ClientOptions?action=diffrev1=159rev2=160

Comment:
Add Cequel to client list

* FluentCassandra: https://github.com/managedfusion/fluentcassandra
   * Ruby:
* Fauna: https://github.com/twitter/cassandra
+   * Cequel: http://github.com/brewster/cequel
   * PHP:
* Cassandra PHP Client Library: 
https://github.com/kallaspriit/Cassandra-PHP-Client-Library
* phpcassa: http://github.com/thobbs/phpcassa

[jira] [Updated] (CASSANDRA-4885) Remove or rework per-row bloom filters

2012-11-20 Thread Jason Brown (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Brown updated CASSANDRA-4885:
---

Attachment: 0002-CASSANRDA-4885-update-test.patch

Ok, took some work, but (re-)corrupted the target data file to trigger the 
scrub. I tried deleting large blocks, scribbling over vast swathes, and even 
minor surgical changes (changing length of col names), but, in the end, the 
best was to just overwrite the first 64 bytes with 0x00.

 Remove or rework per-row bloom filters
 --

 Key: CASSANDRA-4885
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4885
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jonathan Ellis
Assignee: Jason Brown
 Fix For: 1.3

 Attachments: 0001-CASSANRDA-4885-Remove-per-row-bloom-filter.patch, 
 0002-CASSANRDA-4885-update-test.patch


 Per-row bloom filters may be a misfeature.
 On small rows we don't create them.
 On large rows we essentially only do slice queries that can't take advantage 
 of it.
 And on very large rows if we ever did deserialize it, the performance hit of 
 doing so would outweigh the benefit of skipping the actual read.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4803) CFRR wide row iterators improvements

2012-11-20 Thread JIRA


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501242#comment-13501242
 ] 

Piotr Kołaczkowski commented on CASSANDRA-4803:
---

0007 - this is for rolling upgrade. When you upgrade one node and the other 
nodes don't have describe_splits_ex yet, starting a hadoop job on a newly 
upgraded node fails.

As for 0004 / 0006 fixes - I agree. Let's move them to a separate ticket. 

 CFRR wide row iterators improvements
 

 Key: CASSANDRA-4803
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4803
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Affects Versions: 1.1.0
Reporter: Piotr Kołaczkowski
Assignee: Piotr Kołaczkowski
 Fix For: 1.1.7

 Attachments: 
 0004-Better-token-range-wrap-around-handling-in-CFIF-CFRR.patch, 
 0006-Code-cleanup-refactoring-in-CFRR.-Fixed-bug-with-mis.patch, 
 0007-Fallback-to-describe_splits-in-case-describe_splits_.patch


 {code}
  public float getProgress()
 {
 // TODO this is totally broken for wide rows
 // the progress is likely to be reported slightly off the actual but 
 close enough
 float progress = ((float) iter.rowsRead() / totalRowCount);
 return progress  1.0F ? 1.0F : progress;
 }
 {code}
 The problem is iter.rowsRead() does not return the number of rows read from 
 the wide row iterator, but returns number of *columns* (every row is counted 
 multiple times). 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4803) CFRR wide row iterators improvements

2012-11-20 Thread JIRA


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501243#comment-13501243
 ] 

Piotr Kołaczkowski commented on CASSANDRA-4803:
---

BTW: I don't get email notifications from ASF Jira. It is because I registered 
long, long time ago and my email is obsolete. How to change my email to a newer 
one? I can't see an option in the user profile for doing that. 

 CFRR wide row iterators improvements
 

 Key: CASSANDRA-4803
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4803
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Affects Versions: 1.1.0
Reporter: Piotr Kołaczkowski
Assignee: Piotr Kołaczkowski
 Fix For: 1.1.7

 Attachments: 
 0004-Better-token-range-wrap-around-handling-in-CFIF-CFRR.patch, 
 0006-Code-cleanup-refactoring-in-CFRR.-Fixed-bug-with-mis.patch, 
 0007-Fallback-to-describe_splits-in-case-describe_splits_.patch


 {code}
  public float getProgress()
 {
 // TODO this is totally broken for wide rows
 // the progress is likely to be reported slightly off the actual but 
 close enough
 float progress = ((float) iter.rowsRead() / totalRowCount);
 return progress  1.0F ? 1.0F : progress;
 }
 {code}
 The problem is iter.rowsRead() does not return the number of rows read from 
 the wide row iterator, but returns number of *columns* (every row is counted 
 multiple times). 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4417) invalid counter shard detected

2012-11-20 Thread Ed Solovey (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501249#comment-13501249
 ] 

Ed Solovey commented on CASSANDRA-4417:
---

We are on 1.1.6 and are seeing this on a three node cluster with replication 
factor of 2.  Is there a workaround for this?  Corrupted counters are a 
showstopper for us and we'll have to move off Cassandra if we can't resolve 
this.

 invalid counter shard detected 
 ---

 Key: CASSANDRA-4417
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4417
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
 Environment: Amazon Linux
Reporter: Senthilvel Rangaswamy
 Attachments: cassandra-mck.log.bz2, err.txt


 Seeing errors like these:
 2012-07-06_07:00:27.22662 ERROR 07:00:27,226 invalid counter shard detected; 
 (17bfd850-ac52-11e1--6ecd0b5b61e7, 1, 13) and 
 (17bfd850-ac52-11e1--6ecd0b5b61e7, 1, 1) differ only in count; will pick 
 highest to self-heal; this indicates a bug or corruption generated a bad 
 counter shard
 What does it mean ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4877) Range queries return fewer result after a lot of delete

2012-11-20 Thread Sylvain Lebresne (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylvain Lebresne updated CASSANDRA-4877:


Attachment: 0002-Rename-maxIsColumns-to-countCQL3Rows.patch
0001-4877.patch

Attaching patch to fix this. The problem is that our handling of LIMIT was 
still not correct, in particular when NamesQueryFilter where used, as delete 
rows were wrongfully counted.

One problem with that patch is that we may still under-count in a mixed 1.1/1.2 
cluster because 1.1 nodes won't know how to count correctly. That's sad, but at 
the same time changing this in 1.1 would be hard and dangerous and CQL3 is beta 
in 1.1 after all.

Note that I'm attaching 2 patches. The first one is the bulk of the fix. The 
second one is mostly a renaming of the 'maxIsColumn' parameters that is used in 
a number of place to 'countCQL3Rows' because that describe more faithfully what 
this parameter actually do.

 Range queries return fewer result after a lot of delete
 ---

 Key: CASSANDRA-4877
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4877
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Reporter: julien campan
Assignee: Sylvain Lebresne
 Fix For: 1.2.0 rc1

 Attachments: 0001-4877.patch, 
 0002-Rename-maxIsColumns-to-countCQL3Rows.patch


 Hi, I'm testing on the trunk version
 I'm using : [cqlsh 2.3.0 | Cassandra 1.2.0-beta1-SNAPSHOT | CQL spec 3.0.0 | 
 Thrift protocol 19.35.0]
 My use case is :
 I create a table
 CREATE TABLE premier (
 id int PRIMARY KEY,
 value int
 ) WITH
 comment='' AND
 caching='KEYS_ONLY' AND
 read_repair_chance=0.10 AND
 dclocal_read_repair_chance=0.00 AND
 gc_grace_seconds=864000 AND
 replicate_on_write='true' AND
 compression={'sstable_compression': 'SnappyCompressor'};
 1) I insert 10 000 000 rows (they are like id = 1 and value =1)
 2) I delete 2 000 000 rows (i use random method to choose the key value)
 3) I do select * from premier ; and my result is 7944 instead of 10 000.
 4) if if do select * from premier limit 2 ; my result is 15839 .
 So after a lot of delete, the range operator is not working.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[3/6] git commit: Merge branch 'cassandra-1.2.0' into cassandra-1.2

Merge branch 'cassandra-1.2.0' into cassandra-1.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c235229e
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c235229e
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c235229e

Branch: refs/heads/trunk
Commit: c235229e9cf9e59ef88cb8674c03b5b3c64e7cbb
Parents: efded00 553b9e8
Author: Yuki Morishita yu...@apache.org
Authored: Tue Nov 20 12:20:02 2012 -0600
Committer: Yuki Morishita yu...@apache.org
Committed: Tue Nov 20 12:20:02 2012 -0600

--
 .../apache/cassandra/service/StorageService.java   |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--

[1/6] git commit: Merge branch 'cassandra-1.2' into trunk

Updated Branches:
  refs/heads/cassandra-1.2 efded0046 - c235229e9
  refs/heads/cassandra-1.2.0 edf63d8a5 - 553b9e86d
  refs/heads/trunk 633dbbd7a - 44b7b7a62


Merge branch 'cassandra-1.2' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/44b7b7a6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/44b7b7a6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/44b7b7a6

Branch: refs/heads/trunk
Commit: 44b7b7a62bf54b084a2696bb7f6a9985fcde54cc
Parents: 633dbbd c235229
Author: Yuki Morishita yu...@apache.org
Authored: Tue Nov 20 12:20:20 2012 -0600
Committer: Yuki Morishita yu...@apache.org
Committed: Tue Nov 20 12:20:20 2012 -0600

--
 .../apache/cassandra/service/StorageService.java   |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--

[5/6] git commit: need to set initialized flag when do initServer

need to set initialized flag when do initServer


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/553b9e86
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/553b9e86
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/553b9e86

Branch: refs/heads/cassandra-1.2.0
Commit: 553b9e86d0da87738cbce9c39a5a8de8f5ed12d2
Parents: edf63d8
Author: Yuki Morishita yu...@apache.org
Authored: Tue Nov 20 12:19:46 2012 -0600
Committer: Yuki Morishita yu...@apache.org
Committed: Tue Nov 20 12:19:46 2012 -0600

--
 .../apache/cassandra/service/StorageService.java   |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/553b9e86/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index 0206f40..17b21d9 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -410,6 +410,7 @@ public class StorageService implements 
IEndpointStateChangeSubscriber, StorageSe
 throw new UnsupportedOperationException(StorageService does 
not support switching modes.);
 return;
 }
+initialized = true;
 isClientMode = false;
 
 // Ensure StorageProxy is initialized on start-up; see CASSANDRA-3797.

[4/6] git commit: need to set initialized flag when do initServer

need to set initialized flag when do initServer


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/553b9e86
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/553b9e86
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/553b9e86

Branch: refs/heads/trunk
Commit: 553b9e86d0da87738cbce9c39a5a8de8f5ed12d2
Parents: edf63d8
Author: Yuki Morishita yu...@apache.org
Authored: Tue Nov 20 12:19:46 2012 -0600
Committer: Yuki Morishita yu...@apache.org
Committed: Tue Nov 20 12:19:46 2012 -0600

--
 .../apache/cassandra/service/StorageService.java   |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/553b9e86/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index 0206f40..17b21d9 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -410,6 +410,7 @@ public class StorageService implements 
IEndpointStateChangeSubscriber, StorageSe
 throw new UnsupportedOperationException(StorageService does 
not support switching modes.);
 return;
 }
+initialized = true;
 isClientMode = false;
 
 // Ensure StorageProxy is initialized on start-up; see CASSANDRA-3797.

[6/6] git commit: need to set initialized flag when do initServer

need to set initialized flag when do initServer


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/553b9e86
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/553b9e86
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/553b9e86

Branch: refs/heads/cassandra-1.2
Commit: 553b9e86d0da87738cbce9c39a5a8de8f5ed12d2
Parents: edf63d8
Author: Yuki Morishita yu...@apache.org
Authored: Tue Nov 20 12:19:46 2012 -0600
Committer: Yuki Morishita yu...@apache.org
Committed: Tue Nov 20 12:19:46 2012 -0600

--
 .../apache/cassandra/service/StorageService.java   |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/553b9e86/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index 0206f40..17b21d9 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -410,6 +410,7 @@ public class StorageService implements 
IEndpointStateChangeSubscriber, StorageSe
 throw new UnsupportedOperationException(StorageService does 
not support switching modes.);
 return;
 }
+initialized = true;
 isClientMode = false;
 
 // Ensure StorageProxy is initialized on start-up; see CASSANDRA-3797.

[2/6] git commit: Merge branch 'cassandra-1.2.0' into cassandra-1.2

Merge branch 'cassandra-1.2.0' into cassandra-1.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c235229e
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c235229e
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c235229e

Branch: refs/heads/cassandra-1.2
Commit: c235229e9cf9e59ef88cb8674c03b5b3c64e7cbb
Parents: efded00 553b9e8
Author: Yuki Morishita yu...@apache.org
Authored: Tue Nov 20 12:20:02 2012 -0600
Committer: Yuki Morishita yu...@apache.org
Committed: Tue Nov 20 12:20:02 2012 -0600

--
 .../apache/cassandra/service/StorageService.java   |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--

[jira] [Commented] (CASSANDRA-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)

2012-11-20 Thread Jeremy Hanna (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501351#comment-13501351
 ] 

Jeremy Hanna commented on CASSANDRA-4687:
-

As another data point, one user reported seeing the cache capacity misreporting 
its value in the nodetool info output around the same time as seeing the 
DecoratedKey exceptions in their log.  Once they readjusted the cache capacity 
using nodetool setcachecapacity, the exceptions went away.  They set both key 
and row cache to non-zero values, so it looks like disabling key cache, at 
least for them, wasn't necessary.

So for example, they had 1024M for key cache and 1024M for row cache in the 
cassandra.yaml.  They saw values like the following when running nodetool info 
on a few of the nodes:
{quote}
Key Cache: size 536870880 (bytes), capacity 536870880 (bytes), 81039812 
hits, 95996835 requests, 0.879 recent hit rate, 14400 save period in seconds
Row Cache: size 237336 (bytes), capacity 238282 (bytes), 823752 hits, 
1171017 requests, 0.687 recent hit rate, 0 save period in seconds
{quote}
Note that the capacity value is far below what they configured in their 
cassandra.yaml.

 Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
 ---

 Key: CASSANDRA-4687
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.5
 Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single 
 node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
 Fix For: 1.1.7

 Attachments: 4687-debugging.txt


 Under heavy write load sometimes cassandra fails with assertion error.
 git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
 works fine if global key/row caches disabled in code.
 {quote}
 java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in 
 /var/lib/cassandra/data/...-he-1-Data.db
   at 
 org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
   at 
 org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
   at 
 org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
   at 
 org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
   at 
 org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
   at org.apache.cassandra.db.Table.getRow(Table.java:378)
   at 
 org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
   at 
 org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
   at 
 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:662)
 {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3974) Per-CF TTL

2012-11-20 Thread Jeremy Hanna (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501412#comment-13501412
 ] 

Jeremy Hanna commented on CASSANDRA-3974:
-

So this isn't going into 1.2 because it didn't apply cleanly to trunk?  I'm 
confused why the status is set to open and the target version is not set to 1.3.

 Per-CF TTL
 --

 Key: CASSANDRA-3974
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3974
 Project: Cassandra
  Issue Type: New Feature
Affects Versions: 1.2.0 beta 1
Reporter: Jonathan Ellis
Assignee: Kirk True
Priority: Minor
 Fix For: 1.3

 Attachments: 3974-v8.txt, trunk-3974.txt, trunk-3974v2.txt, 
 trunk-3974v3.txt, trunk-3974v4.txt, trunk-3974v5.txt, trunk-3974v6.txt, 
 trunk-3974v7.txt


 Per-CF TTL would allow compaction optimizations (drop an entire sstable's 
 worth of expired data) that we can't do with per-column.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CASSANDRA-3974) Per-CF TTL

2012-11-20 Thread Jeremy Hanna (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501412#comment-13501412
 ] 

Jeremy Hanna edited comment on CASSANDRA-3974 at 11/20/12 7:49 PM:
---

So this isn't going into 1.2 because it didn't apply cleanly to trunk?  I'm 
confused why the status is set to open and the target version is now set to 1.3.

  was (Author: jeromatron):
So this isn't going into 1.2 because it didn't apply cleanly to trunk?  I'm 
confused why the status is set to open and the target version is not set to 1.3.
  
 Per-CF TTL
 --

 Key: CASSANDRA-3974
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3974
 Project: Cassandra
  Issue Type: New Feature
Affects Versions: 1.2.0 beta 1
Reporter: Jonathan Ellis
Assignee: Kirk True
Priority: Minor
 Fix For: 1.3

 Attachments: 3974-v8.txt, trunk-3974.txt, trunk-3974v2.txt, 
 trunk-3974v3.txt, trunk-3974v4.txt, trunk-3974v5.txt, trunk-3974v6.txt, 
 trunk-3974v7.txt


 Per-CF TTL would allow compaction optimizations (drop an entire sstable's 
 worth of expired data) that we can't do with per-column.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3017) add a Message size limit

[
https://issues.apache.org/jira/browse/CASSANDRA-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501465#comment-13501465
]

Jonathan Ellis commented on CASSANDRA-3017:
---

I've been thinking about that last part and I don't have a good solution. I
*really* don't want to add the complexity of multi-part replies.

Since the goal here is to protect against malformed messages from non-cluster
members, how about this?

We pick a limit large enough to let gossip messages through (64K?) and drop
*all* messages larger than that *from non-cluster members* (according to
Gossiper's knowledge).

This doesn't help you if you're fuzz-testing Cassandra from one of your other
nodes, but hopefully you're not doing that...

I think this also would cause some dropped messages when FD announces that a
node is back up and the cluster tries to replicate stuff to it, but it doesn't
know yet that the source is a cluster member. This should be okay for reads
(since they will be small) but could cause some extra timeouts for writes.

I could see just accepting this, or adding a delay to FD recognition to keep
that as UAE for a bit longer. Or we could just wontfix.

What do you think [~brandon.williams]?

add a Message size limit

Key: CASSANDRA-3017
URL: https://issues.apache.org/jira/browse/CASSANDRA-3017
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Jonathan Ellis
Assignee: Kirk True
Priority: Minor
Labels: lhf
Attachments:
0001-use-the-thrift-max-message-size-for-inter-node-messa.patch,
trunk-3017.txt

We protect the server from allocating huge buffers for malformed message with
the Thrift frame size (CASSANDRA-475). But we don't have similar protection
for the inter-node Message objects.
Adding this would be good to deal with malicious adversaries as well as a
malfunctioning cluster participant.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3961) Make index_interval configurable per column family


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501464#comment-13501464
 ] 

Jonathan Ellis commented on CASSANDRA-3961:
---

Eyeballing this looks reasonable.  Can you rebase to trunk?

 Make index_interval configurable per column family
 --

 Key: CASSANDRA-3961
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3961
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: Cassandra 1.0.7/unix
Reporter: Radim Kolar
Assignee: Radim Kolar
 Fix For: 1.3

 Attachments: cass-interval1.txt, cass-interval2.txt


 After various experiments with mixing OLTP a OLAP workload running on single 
 cassandra cluster i discovered that lot of memory is wasted on holding index 
 samples for CF which are rarely accessed or index is not much used for CF 
 access because slices over keys are used. 
 There is per column family setting for configuring bloom filters - 
 bloom_filter_fp_chance. Please add setting index_interval configurable per CF 
 as well. If this setting is not set or it is zero, default from 
 cassandra.yaml will be used.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3929) Support row size limits

[
https://issues.apache.org/jira/browse/CASSANDRA-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501467#comment-13501467
]

Jonathan Ellis commented on CASSANDRA-3929:
---

The good news is, this looks good. (Nit: getRetainedColumnCount would be a bit
cleaner as a method on CFMetaData.)

The bad news is, I think we need to scope creep -- the right unit of retention
is the cql3 row. For {{COMPACT STORAGE}} there is one row per cell, but
otherwise it gets complicated... there's a this row exists marker cell, and
collection columns become one cell per entry. Dealing with partial (cql3) rows
is not something we want to inflict on users, so we should enable column
tombstoning only on cql3 row boundaries.

cfmetadata.cqlCfDef will have the information we need to do this, in
particulary {{isCompact}} and {{keys}}. (See
www.datastax.com/dev/blog/thrift-to-cql3.)

I suspect you're going to want a unit test or two here.
QueryProcessor.processInternal is probably the easiest way to do cql from a
test.

Support row size limits
---

Key: CASSANDRA-3929
URL: https://issues.apache.org/jira/browse/CASSANDRA-3929
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Jonathan Ellis
Assignee: Dave Brosius
Priority: Minor
Labels: ponies
Fix For: 1.3

Attachments: 3929_b.txt, 3929_c.txt, 3929_d.txt, 3929.txt

We currently support expiring columns by time-to-live; we've also had
requests for keeping the most recent N columns in a row.

[jira] [Commented] (CASSANDRA-3848) EmbeddedCassandraService needs a stop() method


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501468#comment-13501468
 ] 

Jonathan Ellis commented on CASSANDRA-3848:
---

Also note that CassandraDaemon.stop doesn't entirely stop the server, just the 
thrift daemon.  Would suggest calling this something else to avoid confusion 
(stopRPC?)

 EmbeddedCassandraService needs a stop() method
 --

 Key: CASSANDRA-3848
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3848
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: David Hawthorne
Priority: Trivial
 Fix For: 1.1.7


 I just need a stop() method in EmbeddedCassandraService so I can shut it down 
 as part of my unit tests, so I can test fail behavior.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3017) add a Message size limit


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501474#comment-13501474
 ] 

Brandon Williams commented on CASSANDRA-3017:
-

Hmm, the problem is with vnodes, we can't really ever know what the largest 
gossip payload will be.  We encode vnodes in binary to be compact, but still 
with a 100 node cluster and 256 vnodes per node, we're way past 64k for a new 
node that needs to receive all the states.

 add a Message size limit
 

 Key: CASSANDRA-3017
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3017
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jonathan Ellis
Assignee: Kirk True
Priority: Minor
  Labels: lhf
 Attachments: 
 0001-use-the-thrift-max-message-size-for-inter-node-messa.patch, 
 trunk-3017.txt


 We protect the server from allocating huge buffers for malformed message with 
 the Thrift frame size (CASSANDRA-475).  But we don't have similar protection 
 for the inter-node Message objects.
 Adding this would be good to deal with malicious adversaries as well as a 
 malfunctioning cluster participant.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4945) CQL3 does handle List append or prepend with a Prepared list


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-4945:
--

Reviewer: jbellis  (was: xedin)

 CQL3 does handle List append or prepend with a Prepared list
 --

 Key: CASSANDRA-4945
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4945
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0 beta 2
 Environment: CQL3 Thrift methods (new)
Reporter: Rick Shaw
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 1.2.0 rc1

 Attachments: 4945.txt


 I can successfully update a List using the literal syntax:
 {code}
 UPDATE testcollection SET L = [98,99,100] + L WHERE k = 1;
 {code}
 And I can successfully upsert a List using the Prepared syntax:
 {code}
 UPDATE testcollection SET L = ? WHERE k = 1
 {code}
 by providing a decoded ListInteger in the bind values.
 But using the prepared syntax for an prepend like:
 {code}
 UPDATE testcollection SET L = ? + L WHERE k = 1
 {code}
 fails with the following message:
 {code}
 java.sql.SQLSyntaxErrorException: InvalidRequestException(why:line 1:33 
 mismatched input '+' expecting K_WHERE)
   at 
 org.apache.cassandra.cql.jdbc.CassandraPreparedStatement.init(CassandraPreparedStatement.java:92)
 ...
 ...
 {code}
 and an append of a prepared syntax like:
 {code}
 UPDATE testcollection SET L = L + ? WHERE k = 1
 {code}
 fails as follows:
 {code}
 java.sql.SQLSyntaxErrorException: InvalidRequestException(why:invalid 
 operation for non commutative columnfamily testcollection)
   at 
 org.apache.cassandra.cql.jdbc.CassandraPreparedStatement.init(CassandraPreparedStatement.java:92)
 ...
 ...
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4891) support for running findbugs


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501477#comment-13501477
 ] 

Jonathan Ellis commented on CASSANDRA-4891:
---

Why is it useful to have this as an ant task?  It's a lot easier to see false 
positives when using findbugs IDE integration.

 support for running findbugs
 

 Key: CASSANDRA-4891
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4891
 Project: Cassandra
  Issue Type: Improvement
  Components: Tests
Affects Versions: 1.3
Reporter: Radim Kolar
 Attachments: cass-findbugs.txt


 add findbugs target to ant task

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4945) CQL3 does handle List append or prepend with a Prepared list


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501475#comment-13501475
 ] 

Jonathan Ellis commented on CASSANDRA-4945:
---

LGTM, +1

 CQL3 does handle List append or prepend with a Prepared list
 --

 Key: CASSANDRA-4945
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4945
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0 beta 2
 Environment: CQL3 Thrift methods (new)
Reporter: Rick Shaw
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 1.2.0 rc1

 Attachments: 4945.txt


 I can successfully update a List using the literal syntax:
 {code}
 UPDATE testcollection SET L = [98,99,100] + L WHERE k = 1;
 {code}
 And I can successfully upsert a List using the Prepared syntax:
 {code}
 UPDATE testcollection SET L = ? WHERE k = 1
 {code}
 by providing a decoded ListInteger in the bind values.
 But using the prepared syntax for an prepend like:
 {code}
 UPDATE testcollection SET L = ? + L WHERE k = 1
 {code}
 fails with the following message:
 {code}
 java.sql.SQLSyntaxErrorException: InvalidRequestException(why:line 1:33 
 mismatched input '+' expecting K_WHERE)
   at 
 org.apache.cassandra.cql.jdbc.CassandraPreparedStatement.init(CassandraPreparedStatement.java:92)
 ...
 ...
 {code}
 and an append of a prepared syntax like:
 {code}
 UPDATE testcollection SET L = L + ? WHERE k = 1
 {code}
 fails as follows:
 {code}
 java.sql.SQLSyntaxErrorException: InvalidRequestException(why:invalid 
 operation for non commutative columnfamily testcollection)
   at 
 org.apache.cassandra.cql.jdbc.CassandraPreparedStatement.init(CassandraPreparedStatement.java:92)
 ...
 ...
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4753) Timeout reporter writes hints for the local node


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501479#comment-13501479
 ] 

Jonathan Ellis commented on CASSANDRA-4753:
---

Here is one solution.

- Created LocalMutationRunnable that retries with hint backpressure if it gets 
dropped
- Added an updated v3, with an additional assert to make sure we don't 
introduce a bug if we decide to allow using the coordinator as a batchlog 
member in non-single-node clusters

 Timeout reporter writes hints for the local node
 

 Key: CASSANDRA-4753
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4753
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
 Fix For: 1.2.0

 Attachments: 4753.txt, 4753-v2.txt, 4753-v3.txt


 MessagingService.java:330 calls StorageProxy.scheduleLocalHint() without 
 checking if the local node is the target. This causes 
 StorageProxy.scheduleLocalHint to throw AssertionError sometimes.
 Got this error when some batches are timed out. This can happen because even 
 local batches now go through StorageProxy.sendMessages and aren't just 
 rm.apply()'d.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4753) Timeout reporter writes hints for the local node


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501483#comment-13501483
 ] 

Jonathan Ellis commented on CASSANDRA-4753:
---

Here is one solution: http://github.com/jbellis/cassandra/branches/4753-5

- Created LocalMutationRunnable that retries with hint backpressure if it gets 
dropped
- Added an updated v3, with an additional assert to make sure we don't 
introduce a bug if we decide to allow using the coordinator as a batchlog 
member in non-single-node clusters

 Timeout reporter writes hints for the local node
 

 Key: CASSANDRA-4753
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4753
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
 Fix For: 1.2.0

 Attachments: 4753.txt, 4753-v2.txt, 4753-v3.txt


 MessagingService.java:330 calls StorageProxy.scheduleLocalHint() without 
 checking if the local node is the target. This causes 
 StorageProxy.scheduleLocalHint to throw AssertionError sometimes.
 Got this error when some batches are timed out. This can happen because even 
 local batches now go through StorageProxy.sendMessages and aren't just 
 rm.apply()'d.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (CASSANDRA-4880) Endless loop flushing+compacting system/schema_keyspaces and system/schema_columnfamilies


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams reopened CASSANDRA-4880:
-


I think something's still wrong in 1.1, concurrent schema changes aren't 
settling: 
http://buildbot.datastax.com:8010/builders/cassandra-1.1/builds/567/steps/shell/logs/stdio

Everything works in 1.2.

 Endless loop flushing+compacting system/schema_keyspaces and 
 system/schema_columnfamilies
 -

 Key: CASSANDRA-4880
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4880
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.6, 1.2.0 beta 1
 Environment: Linux x86_64 3.4.9, sun-jdk 1.6.0_33
Reporter: Mina Naguib
Assignee: Pavel Yaskevich
 Fix For: 1.1.7, 1.2.0 rc1

 Attachments: CASSANDRA-4880.patch


 After upgrading a node from 1.1.2 to 1.1.6, the startup sequence entered a 
 loop as seen here:
 http://mina.naguib.ca/misc/cassandra_116_startup_loop.txt
 Stopping and starting the node entered the same loop.
 Reverting back to 1.1.2 started successfully.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4891) support for running findbugs


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501496#comment-13501496
 ] 

Radim Kolar commented on CASSANDRA-4891:


because currently is eclipse findbugs plugin broken in E4.2, while it is fixed 
in repository, its not released yet and its in soon status for about 8 
months. I would not count on it.

 support for running findbugs
 

 Key: CASSANDRA-4891
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4891
 Project: Cassandra
  Issue Type: Improvement
  Components: Tests
Affects Versions: 1.3
Reporter: Radim Kolar
 Attachments: cass-findbugs.txt


 add findbugs target to ant task

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4753) Timeout reporter writes hints for the local node


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-4753:
--

Comment: was deleted

(was: Here is one solution.

- Created LocalMutationRunnable that retries with hint backpressure if it gets 
dropped
- Added an updated v3, with an additional assert to make sure we don't 
introduce a bug if we decide to allow using the coordinator as a batchlog 
member in non-single-node clusters)

 Timeout reporter writes hints for the local node
 

 Key: CASSANDRA-4753
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4753
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
 Fix For: 1.2.0

 Attachments: 4753.txt, 4753-v2.txt, 4753-v3.txt


 MessagingService.java:330 calls StorageProxy.scheduleLocalHint() without 
 checking if the local node is the target. This causes 
 StorageProxy.scheduleLocalHint to throw AssertionError sometimes.
 Got this error when some batches are timed out. This can happen because even 
 local batches now go through StorageProxy.sendMessages and aren't just 
 rm.apply()'d.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4880) Endless loop flushing+compacting system/schema_keyspaces and system/schema_columnfamilies

2012-11-20 Thread Pavel Yaskevich (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501504#comment-13501504
 ] 

Pavel Yaskevich commented on CASSANDRA-4880:


Could that be that those two stub nodes running on different versions - one on 
recent and one on previous? That would explain why they have disagreement. It's 
tested on rolling restart by CASSANDRA-4837.

 Endless loop flushing+compacting system/schema_keyspaces and 
 system/schema_columnfamilies
 -

 Key: CASSANDRA-4880
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4880
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.6, 1.2.0 beta 1
 Environment: Linux x86_64 3.4.9, sun-jdk 1.6.0_33
Reporter: Mina Naguib
Assignee: Pavel Yaskevich
 Fix For: 1.1.7, 1.2.0 rc1

 Attachments: CASSANDRA-4880.patch


 After upgrading a node from 1.1.2 to 1.1.6, the startup sequence entered a 
 loop as seen here:
 http://mina.naguib.ca/misc/cassandra_116_startup_loop.txt
 Stopping and starting the node entered the same loop.
 Reverting back to 1.1.2 started successfully.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4880) Endless loop flushing+compacting system/schema_keyspaces and system/schema_columnfamilies


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501508#comment-13501508
 ] 

Brandon Williams commented on CASSANDRA-4880:
-

Nope, those tests all run with the same version.

 Endless loop flushing+compacting system/schema_keyspaces and 
 system/schema_columnfamilies
 -

 Key: CASSANDRA-4880
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4880
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.6, 1.2.0 beta 1
 Environment: Linux x86_64 3.4.9, sun-jdk 1.6.0_33
Reporter: Mina Naguib
Assignee: Pavel Yaskevich
 Fix For: 1.1.7, 1.2.0 rc1

 Attachments: CASSANDRA-4880.patch


 After upgrading a node from 1.1.2 to 1.1.6, the startup sequence entered a 
 loop as seen here:
 http://mina.naguib.ca/misc/cassandra_116_startup_loop.txt
 Stopping and starting the node entered the same loop.
 Reverting back to 1.1.2 started successfully.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4880) Endless loop flushing+compacting system/schema_keyspaces and system/schema_columnfamilies

2012-11-20 Thread Pavel Yaskevich (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501511#comment-13501511
 ] 

Pavel Yaskevich commented on CASSANDRA-4880:


Interesting... Ok, I will try to figure it out asap.

 Endless loop flushing+compacting system/schema_keyspaces and 
 system/schema_columnfamilies
 -

 Key: CASSANDRA-4880
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4880
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.6, 1.2.0 beta 1
 Environment: Linux x86_64 3.4.9, sun-jdk 1.6.0_33
Reporter: Mina Naguib
Assignee: Pavel Yaskevich
 Fix For: 1.1.7, 1.2.0 rc1

 Attachments: CASSANDRA-4880.patch


 After upgrading a node from 1.1.2 to 1.1.6, the startup sequence entered a 
 loop as seen here:
 http://mina.naguib.ca/misc/cassandra_116_startup_loop.txt
 Stopping and starting the node entered the same loop.
 Reverting back to 1.1.2 started successfully.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4880) Endless loop flushing+compacting system/schema_keyspaces and system/schema_columnfamilies

2012-11-20 Thread Pavel Yaskevich (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Yaskevich updated CASSANDRA-4880:
---

Attachment: CASSANDRA-4880-fix.patch

We don't need special RM deserialization handler any more, verified that tests 
are now passing.

 Endless loop flushing+compacting system/schema_keyspaces and 
 system/schema_columnfamilies
 -

 Key: CASSANDRA-4880
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4880
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.6, 1.2.0 beta 1
 Environment: Linux x86_64 3.4.9, sun-jdk 1.6.0_33
Reporter: Mina Naguib
Assignee: Pavel Yaskevich
 Fix For: 1.1.7, 1.2.0 rc1

 Attachments: CASSANDRA-4880-fix.patch, CASSANDRA-4880.patch


 After upgrading a node from 1.1.2 to 1.1.6, the startup sequence entered a 
 loop as seen here:
 http://mina.naguib.ca/misc/cassandra_116_startup_loop.txt
 Stopping and starting the node entered the same loop.
 Reverting back to 1.1.2 started successfully.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4899) add gitignore


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501627#comment-13501627
 ] 

Radim Kolar commented on CASSANDRA-4899:


can be this committed? its highly annoying to work with git extensions because 
it shows 2798 uncommitted files.

 add gitignore
 -

 Key: CASSANDRA-4899
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4899
 Project: Cassandra
  Issue Type: Task
Reporter: Radim Kolar
Assignee: Radim Kolar
 Attachments: cass-gitignore.txt




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-3961) Make index_interval configurable per column family


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radim Kolar updated CASSANDRA-3961:
---

Attachment: cass-interval3.txt

 Make index_interval configurable per column family
 --

 Key: CASSANDRA-3961
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3961
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: Cassandra 1.0.7/unix
Reporter: Radim Kolar
Assignee: Radim Kolar
 Fix For: 1.3

 Attachments: cass-interval1.txt, cass-interval2.txt, 
 cass-interval3.txt


 After various experiments with mixing OLTP a OLAP workload running on single 
 cassandra cluster i discovered that lot of memory is wasted on holding index 
 samples for CF which are rarely accessed or index is not much used for CF 
 access because slices over keys are used. 
 There is per column family setting for configuring bloom filters - 
 bloom_filter_fp_chance. Please add setting index_interval configurable per CF 
 as well. If this setting is not set or it is zero, default from 
 cassandra.yaml will be used.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-3961) Make index_interval configurable per column family


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radim Kolar updated CASSANDRA-3961:
---

Attachment: cass-interval4.txt

 Make index_interval configurable per column family
 --

 Key: CASSANDRA-3961
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3961
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: Cassandra 1.0.7/unix
Reporter: Radim Kolar
Assignee: Radim Kolar
 Fix For: 1.3

 Attachments: cass-interval1.txt, cass-interval2.txt, 
 cass-interval3.txt, cass-interval4.txt


 After various experiments with mixing OLTP a OLAP workload running on single 
 cassandra cluster i discovered that lot of memory is wasted on holding index 
 samples for CF which are rarely accessed or index is not much used for CF 
 access because slices over keys are used. 
 There is per column family setting for configuring bloom filters - 
 bloom_filter_fp_chance. Please add setting index_interval configurable per CF 
 as well. If this setting is not set or it is zero, default from 
 cassandra.yaml will be used.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4897) Allow tiered compaction define max sstable size


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radim Kolar updated CASSANDRA-4897:
---

Attachment: cass-maxsize2.txt

do not compact bucket with maximum sized tables.

 Allow tiered compaction define max sstable size
 ---

 Key: CASSANDRA-4897
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4897
 Project: Cassandra
  Issue Type: Improvement
Reporter: Radim Kolar
 Attachments: cass-maxsize1.txt, cass-maxsize2.txt


 Lucene is doing same thing. Correctly configured max segment size will 
 recycle old data faster with less diskspace.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4446) nodetool drain sometimes doesn't mark commitlog fully flushed

2012-11-20 Thread Tamar Fraenkel (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501722#comment-13501722
 ] 

Tamar Fraenkel commented on CASSANDRA-4446:
---

I had the same experience, when I upgraded my cluster from 1.0.9 to 1.0.11. I 
ran drain before the upgrade, upgrade on the node finished and node restarted 
at 2012-11-20 10:20:58, but then I see in the logs reply of commit log:
{quote} 
 INFO [main] 2012-11-20 09:41:13,918 CommitLog.java (line 172) Replaying 
/raid0/cassandra/commitlog/CommitLog-1353402218337.log
 INFO [main] 2012-11-20 09:41:20,360 CommitLog.java (line 179) Log replay 
complete, 0 replayed mutations
 INFO [main] 2012-11-20 10:11:35,635 CommitLog.java (line 167) No commitlog 
files found; skipping replay
 INFO [main] 2012-11-20 10:21:11,631 CommitLog.java (line 172) Replaying 
/raid0/cassandra/commitlog/CommitLog-1353404473899.log
 INFO [main] 2012-11-20 10:21:18,119 CommitLog.java (line 179) Log replay 
complete, 6413 replayed mutations
 INFO [main] 2012-11-20 10:55:46,435 CommitLog.java (line 172) Replaying 
/raid0/cassandra/commitlog/CommitLog-1353406871619.log
 INFO [main] 2012-11-20 10:55:54,139 CommitLog.java (line 179) Log replay 
complete, 3 replayed mutations
{quote} 
This caused over increment of counters


 nodetool drain sometimes doesn't mark commitlog fully flushed
 -

 Key: CASSANDRA-4446
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4446
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.0.10
 Environment: ubuntu 10.04 64bit
 Linux HOSTNAME 2.6.32-345-ec2 #48-Ubuntu SMP Wed May 2 19:29:55 UTC 2012 
 x86_64 GNU/Linux
 sun JVM
 cassandra 1.0.10 installed from apache deb
Reporter: Robert Coli
 Attachments: 
 cassandra.1.0.10.replaying.log.after.exception.during.drain.txt


 I recently wiped a customer's QA cluster. I drained each node and verified 
 that they were drained. When I restarted the nodes, I saw the commitlog 
 replay create a memtable and then flush it. I have attached a sanitized log 
 snippet from a representative node at the time. 
 It appears to show the following :
 1) Drain begins
 2) Drain triggers flush
 3) Flush triggers compaction
 4) StorageService logs DRAINED message
 5) compaction thread excepts
 6) on restart, same CF creates a memtable
 7) and then flushes it [1]
 The columnfamily involved in the replay in 7) is the CF for which the 
 compaction thread excepted in 5). This seems to suggest a timing issue 
 whereby the exception in 5) prevents the flush in 3) from marking all the 
 segments flushed, causing them to replay after restart.
 In case it might be relevant, I did an online change of compaction strategy 
 from Leveled to SizeTiered during the uptime period preceding this drain.
 [1] Isn't commitlog replay not supposed to automatically trigger a flush in 
 modern cassandra?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2356) make the debian package never start by default

2012-11-20 Thread Tamar Fraenkel (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501723#comment-13501723
 ] 

Tamar Fraenkel commented on CASSANDRA-2356:
---

I would also like that fix. The auto restart is a pain after upgrading, since I 
need to merge my cassandra.yaml and cassander-env.sh, and don't want the node 
to restart on its own.

 make the debian package never start by default
 --

 Key: CASSANDRA-2356
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2356
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: Jeremy Hanna
Priority: Minor
  Labels: debian, packaging
 Attachments: 2356.txt


 Currently the debian package that installs cassandra starts cassandra by 
 default.  It sounds like that is a standard debian packaging convention.  
 However, if you want to bootstrap a new node and want to configure it before 
 it creates any sort of state information, it's a pain.  I would think that 
 the common use case would be to have it install all of the init scripts and 
 such but *not* have it start up by default.  That way an admin can configure 
 cassandra with seed, token, host, etc. information and then start it.  That 
 makes it easier to programmatically do this as well - have chef/puppet 
 install cassandra, do some configuration, then do the service start.
 With the current setup, it sounds like cassandra creates state on startup 
 that has to be cleaned before a new configuration can take effect.  So the 
 process of installing turns into:
 * install debian package
 * shutdown cassandra
 * clean out state (data/log dirs)
 * configure cassandra
 * start cassandra
 That seems suboptimal for the default case, especially when trying to 
 automate new nodes being bootstrapped.
 Another case might be when a downed node comes back up and starts by default 
 and tries to claim a token that has already been claimed by another newly 
 bootstrapped node.  Rob is more familiar with that case so I'll let him 
 explain it in the comments.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

git commit: better assertion message to help with issues like CASSANDRA-4976

2012-11-20 Thread dbrosius

Updated Branches:
  refs/heads/trunk 44b7b7a62 - 298606afd


better assertion message to help with issues like CASSANDRA-4976


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/298606af
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/298606af
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/298606af

Branch: refs/heads/trunk
Commit: 298606afdc5d0caf5e47bc8aac327d46e67111d2
Parents: 44b7b7a
Author: Dave Brosius dbros...@apache.org
Authored: Wed Nov 21 02:08:37 2012 -0500
Committer: Dave Brosius dbros...@apache.org
Committed: Wed Nov 21 02:08:37 2012 -0500

--
 .../org/apache/cassandra/db/CounterColumn.java |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/298606af/src/java/org/apache/cassandra/db/CounterColumn.java
--
diff --git a/src/java/org/apache/cassandra/db/CounterColumn.java 
b/src/java/org/apache/cassandra/db/CounterColumn.java
index 1c5fdcd..f8be750 100644
--- a/src/java/org/apache/cassandra/db/CounterColumn.java
+++ b/src/java/org/apache/cassandra/db/CounterColumn.java
@@ -113,7 +113,7 @@ public class CounterColumn extends Column
 @Override
 public IColumn diff(IColumn column)
 {
-assert column instanceof CounterColumn : Wrong class type.;
+assert column instanceof CounterColumn : Wrong class type.  + 
((column == null) ? null : column.getClass().getSimpleName()) +  found.;
 
 if (timestamp()  column.timestamp())
 return column;

[jira] [Commented] (CASSANDRA-4899) add gitignore