date:20120628


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

Sam Overton commented on CASSANDRA-3881:


Hi David, is this non-committed code that's part of another ticket?

 reduce computational complexity of processing topology changes
 --

 Key: CASSANDRA-3881
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3881
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Peter Schuller
Assignee: Sam Overton
  Labels: vnodes

 This constitutes follow-up work from CASSANDRA-3831 where a partial 
 improvement was committed, but the fundamental issue was not fixed. The 
 maximum practical cluster size was significantly improved, but further work 
 is expected to be necessary as cluster sizes grow.
 _Edit0: Appended patch information._
 h3. Patches
 ||Compare||Raw diff||Description||
 |[00_snitch_topology|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology]|[00_snitch_topology.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology.diff]|Adds
  some functionality to TokenMetadata to track which endpoints and racks exist 
 in a DC.|
 |[01_calc_natural_endpoints|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints]|[01_calc_natural_endpoints.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints.diff]|Rewritten
  O(logN) implementation of calculateNaturalEndpoints using the topology 
 information from the tokenMetadata.|
 
 _Note: These are branches managed with TopGit. If you are applying the patch 
 output manually, you will either need to filter the TopGit metadata files 
 (i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}), 
 or remove them afterward ({{rm .topmsg .topdeps}})._

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3881) reduce computational complexity of processing topology changes


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

David Alves commented on CASSANDRA-3881:


hi sam

yes I was using that ctor to test StorageService.effectiveOwnership, included 
in the CASSANDRA-3047 patch. 

I worked around it since it makes sense that it makes sense that TokenMetadata 
receives token-endpoint mappings through {code}updateNormalTokens{code}, in 
order to build topology. The thing was that while previously the ctor 
{code}TokenMetadata(BiMapToken, InetAddress tokenToEndpointMap){code} was 
usable, now it is not, at least not without getting topology from another 
TokenMetadata instance.

 reduce computational complexity of processing topology changes
 --

 Key: CASSANDRA-3881
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3881
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Peter Schuller
Assignee: Sam Overton
  Labels: vnodes

 This constitutes follow-up work from CASSANDRA-3831 where a partial 
 improvement was committed, but the fundamental issue was not fixed. The 
 maximum practical cluster size was significantly improved, but further work 
 is expected to be necessary as cluster sizes grow.
 _Edit0: Appended patch information._
 h3. Patches
 ||Compare||Raw diff||Description||
 |[00_snitch_topology|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology]|[00_snitch_topology.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology.diff]|Adds
  some functionality to TokenMetadata to track which endpoints and racks exist 
 in a DC.|
 |[01_calc_natural_endpoints|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints]|[01_calc_natural_endpoints.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints.diff]|Rewritten
  O(logN) implementation of calculateNaturalEndpoints using the topology 
 information from the tokenMetadata.|
 
 _Note: These are branches managed with TopGit. If you are applying the patch 
 output manually, you will either need to filter the TopGit metadata files 
 (i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}), 
 or remove them afterward ({{rm .topmsg .topdeps}})._

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4193) cql delete does not delete


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

Sylvain Lebresne commented on CASSANDRA-4193:
-

It is relevant for the 1.1 branch (for which the patch is targeted) since 
CASSANDRA-3708 is 1.2 only.

 cql delete does not delete 
 ---

 Key: CASSANDRA-4193
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4193
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Jackson Chung
Assignee: Sylvain Lebresne
  Labels: cql3
 Fix For: 1.1.2

 Attachments: 4193.txt


 tested in 1.1 and trunk branch on a single node:
 {panel}
 cqlsh:test create table testcf_old ( username varchar , id int , name 
 varchar , stuff varchar, primary key(username,id,name)) with compact storage;
 cqlsh:test insert into testcf_old ( username , id , name , stuff ) values 
 ('abc', 2, 'rst', 'some other bunch of craps');
 cqlsh:test select * from testcf_old;
  username | id | name | stuff
 --++--+---
   abc |  2 |  rst | some other bunch of craps
   abc |  4 |  xyz |  a bunch of craps
 cqlsh:test delete from testcf_old where username = 'abc' and id =2;
 cqlsh:test select * from testcf_old;
  username | id | name | stuff
 --++--+---
   abc |  2 |  rst | some other bunch of craps
   abc |  4 |  xyz |  a bunch of craps
 {panel}
 same also when not using compact:
 {panel}
 cqlsh:test create table testcf ( username varchar , id int , name varchar , 
 stuff varchar, primary key(username,id));
 cqlsh:test select * from testcf;
  username | id | name  | stuff
 --++---+--
   abc |  2 | some other bunch of craps |  rst
   abc |  4 |   xyz | a bunch of craps
 cqlsh:test delete from testcf where username = 'abc' and id =2;
 cqlsh:test select * from testcf;
  username | id | name  | stuff
 --++---+--
   abc |  2 | some other bunch of craps |  rst
   abc |  4 |   xyz | a bunch of craps
 {panel}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CASSANDRA-4385) bug when trying to describe a cf in a pre cql3 case sensitive keyspace


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

Sylvain Lebresne reassigned CASSANDRA-4385:
---

Assignee: paul cannon

 bug when trying to describe a cf in a pre cql3 case sensitive keyspace
 --

 Key: CASSANDRA-4385
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4385
 Project: Cassandra
  Issue Type: Bug
  Components: Drivers
Affects Versions: 1.1.0
 Environment: Linux, Hotspot JDK6, Cassandra 1.1.0 from tarball 
 unmodified, stock config.
Reporter: Al Tobey
Assignee: paul cannon
Priority: Minor
  Labels: cqlsh

 I can't describe column families in my schema defined via cassandra-cli. 
 Update also seems to fail for the same CF's.
 CREATE KEYSPACE Hastur
   with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
   and strategy_options = {replication_factor:2};
 CREATE COLUMN FAMILY LookupByKey
   with compaction_strategy = 'LeveledCompactionStrategy'
   and compression_options = null;
 Then later, https://gist.github.com/3006886

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4385) bug when trying to describe a cf in a pre cql3 case sensitive keyspace


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

Sylvain Lebresne updated CASSANDRA-4385:


Labels: cqlsh  (was: )

 bug when trying to describe a cf in a pre cql3 case sensitive keyspace
 --

 Key: CASSANDRA-4385
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4385
 Project: Cassandra
  Issue Type: Bug
  Components: Drivers
Affects Versions: 1.1.0
 Environment: Linux, Hotspot JDK6, Cassandra 1.1.0 from tarball 
 unmodified, stock config.
Reporter: Al Tobey
Assignee: paul cannon
Priority: Minor
  Labels: cqlsh

 I can't describe column families in my schema defined via cassandra-cli. 
 Update also seems to fail for the same CF's.
 CREATE KEYSPACE Hastur
   with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
   and strategy_options = {replication_factor:2};
 CREATE COLUMN FAMILY LookupByKey
   with compaction_strategy = 'LeveledCompactionStrategy'
   and compression_options = null;
 Then later, https://gist.github.com/3006886

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3881) reduce computational complexity of processing topology changes


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

Sam Overton commented on CASSANDRA-3881:


Ok, I was going to suggest using updateNormalTokens, or you could change ctor 
visibility in your patch if required.

 reduce computational complexity of processing topology changes
 --

 Key: CASSANDRA-3881
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3881
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Peter Schuller
Assignee: Sam Overton
  Labels: vnodes

 This constitutes follow-up work from CASSANDRA-3831 where a partial 
 improvement was committed, but the fundamental issue was not fixed. The 
 maximum practical cluster size was significantly improved, but further work 
 is expected to be necessary as cluster sizes grow.
 _Edit0: Appended patch information._
 h3. Patches
 ||Compare||Raw diff||Description||
 |[00_snitch_topology|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology]|[00_snitch_topology.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology.diff]|Adds
  some functionality to TokenMetadata to track which endpoints and racks exist 
 in a DC.|
 |[01_calc_natural_endpoints|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints]|[01_calc_natural_endpoints.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints.diff]|Rewritten
  O(logN) implementation of calculateNaturalEndpoints using the topology 
 information from the tokenMetadata.|
 
 _Note: These are branches managed with TopGit. If you are applying the patch 
 output manually, you will either need to filter the TopGit metadata files 
 (i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}), 
 or remove them afterward ({{rm .topmsg .topdeps}})._

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

git commit: Fix leveled promote integrity check

2012-06-28 Thread slebresne

Updated Branches:
  refs/heads/trunk dcc479303 - 4725bf71e


Fix leveled promote integrity check


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

Branch: refs/heads/trunk
Commit: 4725bf71e18550ac60f90d9c3561d81c38894124
Parents: dcc4793
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Jun 28 12:39:08 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Jun 28 12:39:08 2012 +0200

--
 .../cassandra/db/compaction/LeveledManifest.java   |   14 +-
 1 files changed, 9 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/4725bf71/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java 
b/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
index eb82e0d..095e0c6 100644
--- a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
+++ b/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
@@ -194,12 +194,16 @@ public class LeveledManifest
 for (SSTableReader ssTableReader : added)
 add(ssTableReader, newLevel);
 
-DecoratedKey last = null;
-Collections.sort(generations[newLevel], SSTable.sstableComparator);
-for (SSTableReader sstable : generations[newLevel])
+if (newLevel != 0)
 {
-assert last == null || sstable.first.compareTo(last)  0;
-last = sstable.last;
+// Integerity check
+DecoratedKey last = null;
+Collections.sort(generations[newLevel], SSTable.sstableComparator);
+for (SSTableReader sstable : generations[newLevel])
+{
+assert last == null || sstable.first.compareTo(last)  0;
+last = sstable.last;
+}
 }
 
 serialize();

[jira] [Commented] (CASSANDRA-4321) stackoverflow building interval tree possible sstable corruptions


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

Sylvain Lebresne commented on CASSANDRA-4321:
-

bq. CompactionsTest.testBlacklistingWithLeveledCompactionStrategy is currently 
failing in trunk because of a similar integrity check that I added to promote()

That's a bug in the integrity check in fact, that should skip the check if 
newLevel=0 (since we can have newLevel=0 following CASSANDRA-4341). With that 
fixed there is no more failure of that unit test (I've committed the fix as 
4725bf71e18550ac60f9).

 stackoverflow building interval tree  possible sstable corruptions
 ---

 Key: CASSANDRA-4321
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4321
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
Reporter: Anton Winter
Assignee: Sylvain Lebresne
 Fix For: 1.1.2

 Attachments: 
 0001-Change-Range-Bounds-in-LeveledManifest.overlapping-v6.txt, 
 0002-Scrub-detects-and-repair-outOfOrder-rows-v6.txt, 
 0003-Create-standalone-scrub-v6.txt, 
 0004-Add-manifest-integrity-check-v6.txt, ooyala-hastur-stacktrace.txt


 After upgrading to 1.1.1 (from 1.1.0) I have started experiencing 
 StackOverflowError's resulting in compaction backlog and failure to restart. 
 The ring currently consists of 6 DC's and 22 nodes using LCS  compression.  
 This issue was first noted on 2 nodes in one DC and then appears to have 
 spread to various other nodes in the other DC's.  
 When the first occurrence of this was found I restarted the instance but it 
 failed to start so I cleared its data and treated it as a replacement node 
 for the token it was previously responsible for.  This node successfully 
 streamed all the relevant data back but failed again a number of hours later 
 with the same StackOverflowError and again was unable to restart. 
 The initial stack overflow error on a running instance looks like this:
 ERROR [CompactionExecutor:314] 2012-06-07 09:59:43,017 
 AbstractCassandraDaemon.java (line 134) Exception in thread 
 Thread[CompactionExecutor:314,1,main]
 java.lang.StackOverflowError
 at java.util.Arrays.mergeSort(Arrays.java:1157)
 at java.util.Arrays.sort(Arrays.java:1092)
 at java.util.Collections.sort(Collections.java:134)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.findMinMedianMax(IntervalNode.java:114)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:49)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 [snip - this repeats until stack overflow.  Compactions stop from this point 
 onwards]
 I restarted this failing instance with DEBUG logging enabled and it throws 
 the following exception part way through startup:
 ERROR 11:37:51,046 Exception in thread Thread[OptionalTasks:1,5,main]
 java.lang.StackOverflowError
 at 
 org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:307)
 at 
 org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:276)
 at 
 org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:230)
 at 
 org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124)
 at 
 org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:228)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:45)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 [snip - this repeats until stack overflow]
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64)
 at

[jira] [Updated] (CASSANDRA-3047) implementations of IPartitioner.describeOwnership() are not DC aware

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

David Alves updated CASSANDRA-3047:
---

Attachment: 3047.patch

applies on top of 3881.

addresses most suggestions, code is a lot less verbose and returned map is now
endpoint-ownership.

implementations of IPartitioner.describeOwnership() are not DC aware

Key: CASSANDRA-3047
URL: https://issues.apache.org/jira/browse/CASSANDRA-3047
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Aaron Morton
Assignee: David Alves
Priority: Trivial
Fix For: 1.1.2

Attachments: 3047.patch, CASSANDRA-3047.patch, CASSANDRA-3047.patch,
CASSANDRA-3047.patch, CASSANDRA-3047.patch

see http://www.mail-archive.com/user@cassandra.apache.org/msg16375.html
When a cluster the multiple rings approach to tokens the output from nodetool
ring is incorrect.
When it uses the interleaved token approach (e.g. dc1, dc2, dc1, dc2) it will
be correct.
It's a bit hacky but could we special case (RP) tokens that are off by 1 and
calculate the ownership per dc ? I guess another approach would be to add
some parameters so the partitioner can be told about the token assignment
strategy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4041) Allow updating column_alias types


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

Sylvain Lebresne commented on CASSANDRA-4041:
-

* In
{noformat}
ListAbstractType? newTypes = new 
ArrayListAbstractType?(((CompositeType) cfm.comparator).types)
{{
add(name.position, CFPropDefs.parseType(validator));
}};
{noformat}
it's set() that should be used, not add(). Nit: I'm not a fan of using the 
collection literal syntax in that case, especially when not using it takes half 
the number of lines.
* CFMetadata.apply() already check whether the new comparator is compatible 
with the old one. So we should probably rely on that rather than duplicating 
the check.
* Nit: CFMetadata.comparator is not final so we don't really need the new clone 
with comparator method.

I've pushed a test for this in the dtests (test that doesn't pass with this 
patch because of the add instead of set). It would really be awesome though if 
everyone took the habit of adding one with every patch for a CQL fix/new 
feature. 

 Allow updating column_alias types
 -

 Key: CASSANDRA-4041
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4041
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Pavel Yaskevich
Priority: Minor
 Fix For: 1.1.2

 Attachments: CASSANDRA-4041.patch


 CASSANDRA-3657 has added the ability to change comparators (including parts 
 of a compositeType) when compatible. The code of CQL3 forbids it currently 
 however so we should lift that limitation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4389) HHOM.scheduleAllDeliveries still expects tokens as row keys

Sam Overton created CASSANDRA-4389:
--

 Summary: HHOM.scheduleAllDeliveries still expects tokens as row 
keys
 Key: CASSANDRA-4389
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4389
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
Reporter: Sam Overton
Assignee: Sam Overton
Priority: Minor


scheduleAllDeliveries needs updating to expect hostIds instead of tokens in the 
HINTS_CF

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4389) HHOM.scheduleAllDeliveries still expects tokens as row keys


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

Sam Overton updated CASSANDRA-4389:
---

Attachment: 4389.patch

Attached patch

 HHOM.scheduleAllDeliveries still expects tokens as row keys
 ---

 Key: CASSANDRA-4389
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4389
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
Reporter: Sam Overton
Assignee: Sam Overton
Priority: Minor
 Attachments: 4389.patch


 scheduleAllDeliveries needs updating to expect hostIds instead of tokens in 
 the HINTS_CF

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4041) Allow updating column_alias types


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

Pavel Yaskevich updated CASSANDRA-4041:
---

Attachment: CASSANDRA-4041-v2.patch

changed add to set and removed clone and validation, there is no reason to 
use manual iteration where construction already gives that to us saving space.

 Allow updating column_alias types
 -

 Key: CASSANDRA-4041
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4041
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Pavel Yaskevich
Priority: Minor
 Fix For: 1.1.2

 Attachments: CASSANDRA-4041-v2.patch, CASSANDRA-4041.patch


 CASSANDRA-3657 has added the ability to change comparators (including parts 
 of a compositeType) when compatible. The code of CQL3 forbids it currently 
 however so we should lift that limitation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4377) CQL3 column value validation bug

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

Sylvain Lebresne commented on CASSANDRA-4377:
-

bq. it was impossible to insert data into the column family except with cqlsh.
Using a basic thrift batch mutate failed on the validation step because it
tried to validate the value

Alright, that part is not expected and is likely a bug.

Though I note that even if we fix that, since we don't expose on the thrift
side everything needed to interpret the value correctly, thrift client won't be
able to work with those kind of table very well. In particular they won't know
how to interpret the value of a get. So I guess we need to either say clearly
that CQL3 table are not meant to be accessed from thrift, or we should probably
start exposing all the column metatada on the thrift side (but we need to
expose the componentIndex part of the metadata in particular and the discussion
on CASSANDRA-4093 is relevant for that).

CQL3 column value validation bug

Key: CASSANDRA-4377
URL: https://issues.apache.org/jira/browse/CASSANDRA-4377
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.1
Reporter: Nick Bailey
Assignee: Sylvain Lebresne
Fix For: 1.1.2

{noformat}
cqlsh create keyspace test with strategy_class = 'SimpleStrategy' and
strategy_options:replication_factor = 1;
cqlsh use test;
cqlsh:test CREATE TABLE stats (
... gid blob,
... period int,
... tid blob,
... sumint,
... uniques blob,
... PRIMARY KEY(gid, period, tid)
... );
cqlsh:test describe columnfamily stats;
CREATE TABLE stats (
gid blob PRIMARY KEY
) WITH
comment='' AND

comparator='CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.BytesType,org.apache.cassandra.db.marshal.UTF8Type)'
AND
read_repair_chance=0.10 AND
gc_grace_seconds=864000 AND
default_validation=text AND
min_compaction_threshold=4 AND
max_compaction_threshold=32 AND
replicate_on_write='true' AND
compaction_strategy_class='SizeTieredCompactionStrategy' AND
compression_parameters:sstable_compression='SnappyCompressor';
{noformat}
You can see in the above output that the stats cf is created with the column
validator set to text, but neither of the non primary key columns defined are
text. It should either be setting metadata for those columns or not setting a
default validator or some combination of the two.

[jira] [Created] (CASSANDRA-4390) Query with WHERE statement delivers wrong results

Stefan Häck created CASSANDRA-4390:
--

 Summary: Query with WHERE statement delivers wrong results
 Key: CASSANDRA-4390
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4390
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.1
 Environment: Linux version 2.6.32-5-amd64 (Debian 2.6.32-45) |cqlsh 
2.2.0 | Cassandra 1.1.1 | CQL spec 2.0.0 | Thrift protocol 19.32.0]
Reporter: Stefan Häck


Data is written to cassandra via phpcassa ( https://github.com/thobbs/phpcassa 
v1.0).

Inspection the records via cqlsh,the query with a WHERE statement doesn't 
deliver all records.

http://imageshack.us/photo/my-images/820/cassandraqueryissue.png/

I'am working with a 2 node cluster and the effect is the same on both nodes. 
Furthermore a nodetool repair, nodetool rebuild has no positive effect. The 
data type for this column is varint. 


**

DESCRIBE COLUMNFAMILY rm_advertisements

CREATE TABLE rm_advertisements (
  KEY text PRIMARY KEY,
  css text,
  form text,
  custom_field2 text,
  vacancy_type text,
  custom_field3 text,
  active boolean,
  vacancy_responsibles text,
  job_site text,
  vacancy_email_notification text,
  custom_field4 text,
  vacancy_name text,
  startdate text,
  vacancy_id varint,
  custom_field5 text,
  html text,
  company_id varint,
  ctime text,
  title text,
  expires text,
  atime text,
  custom_field1 text,
  vacancy_language text,
  tags text,
  mtime text,
  mailapply boolean,
  vacancy_description text,
  vacancy_function text,
  shorthash text
) WITH
  comment='Advertisements' AND
  comparator=text AND
  read_repair_chance=1.00 AND
  gc_grace_seconds=864000 AND
  default_validation=text AND
  min_compaction_threshold=4 AND
  max_compaction_threshold=32 AND
  replicate_on_write='true' AND
  compaction_strategy_class='SizeTieredCompactionStrategy' AND
  compression_parameters:sstable_compression='SnappyCompressor';

CREATE INDEX rm_advertisements_active ON rm_advertisements (active);

CREATE INDEX rm_advertisements_job_site ON rm_advertisements (job_site);

CREATE INDEX rm_advertisements_vacancy_id ON rm_advertisements (vacancy_id);

CREATE INDEX rm_advertisements_company_id ON rm_advertisements (company_id);

CREATE INDEX rm_advertisements_title ON rm_advertisements (title);

CREATE INDEX rm_advertisements_expires ON rm_advertisements (expires);

CREATE INDEX rm_advertisements_vacancy_language ON rm_advertisements 
(vacancy_language);

CREATE INDEX rm_advertisements_mailapply ON rm_advertisements (mailapply);

CREATE INDEX rm_advertisements_shorthash ON rm_advertisements (shorthash);


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4390) Query with WHERE statement delivers wrong results


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

Stefan Häck updated CASSANDRA-4390:
---

Attachment: Cassandra_Query_Issue.png

 Query with WHERE statement delivers wrong results
 -

 Key: CASSANDRA-4390
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4390
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.1
 Environment: Linux version 2.6.32-5-amd64 (Debian 2.6.32-45) |cqlsh 
 2.2.0 | Cassandra 1.1.1 | CQL spec 2.0.0 | Thrift protocol 19.32.0]
Reporter: Stefan Häck
 Attachments: Cassandra_Query_Issue.png


 Data is written to cassandra via phpcassa ( 
 https://github.com/thobbs/phpcassa v1.0).
 Inspection the records via cqlsh,the query with a WHERE statement doesn't 
 deliver all records.
 http://imageshack.us/photo/my-images/820/cassandraqueryissue.png/
 I'am working with a 2 node cluster and the effect is the same on both nodes. 
 Furthermore a nodetool repair, nodetool rebuild has no positive effect. The 
 data type for this column is varint. 
 **
 DESCRIBE COLUMNFAMILY rm_advertisements
 CREATE TABLE rm_advertisements (
   KEY text PRIMARY KEY,
   css text,
   form text,
   custom_field2 text,
   vacancy_type text,
   custom_field3 text,
   active boolean,
   vacancy_responsibles text,
   job_site text,
   vacancy_email_notification text,
   custom_field4 text,
   vacancy_name text,
   startdate text,
   vacancy_id varint,
   custom_field5 text,
   html text,
   company_id varint,
   ctime text,
   title text,
   expires text,
   atime text,
   custom_field1 text,
   vacancy_language text,
   tags text,
   mtime text,
   mailapply boolean,
   vacancy_description text,
   vacancy_function text,
   shorthash text
 ) WITH
   comment='Advertisements' AND
   comparator=text AND
   read_repair_chance=1.00 AND
   gc_grace_seconds=864000 AND
   default_validation=text AND
   min_compaction_threshold=4 AND
   max_compaction_threshold=32 AND
   replicate_on_write='true' AND
   compaction_strategy_class='SizeTieredCompactionStrategy' AND
   compression_parameters:sstable_compression='SnappyCompressor';
 CREATE INDEX rm_advertisements_active ON rm_advertisements (active);
 CREATE INDEX rm_advertisements_job_site ON rm_advertisements (job_site);
 CREATE INDEX rm_advertisements_vacancy_id ON rm_advertisements (vacancy_id);
 CREATE INDEX rm_advertisements_company_id ON rm_advertisements (company_id);
 CREATE INDEX rm_advertisements_title ON rm_advertisements (title);
 CREATE INDEX rm_advertisements_expires ON rm_advertisements (expires);
 CREATE INDEX rm_advertisements_vacancy_language ON rm_advertisements 
 (vacancy_language);
 CREATE INDEX rm_advertisements_mailapply ON rm_advertisements (mailapply);
 CREATE INDEX rm_advertisements_shorthash ON rm_advertisements (shorthash);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4390) Query with WHERE statement delivers wrong results


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

Stefan Häck updated CASSANDRA-4390:
---

Description: 
Data is written to cassandra via phpcassa ( https://github.com/thobbs/phpcassa 
v1.0).

Inspection the records via cqlsh,the query with a WHERE statement doesn't 
deliver all records.

https://issues.apache.org/jira/secure/attachment/12533818/Cassandra_Query_Issue.png

I'am working with a 2 node cluster and the effect is the same on both nodes. 
Furthermore a nodetool repair, nodetool rebuild has no positive effect. The 
data type for this column is varint. 


**

DESCRIBE COLUMNFAMILY rm_advertisements

CREATE TABLE rm_advertisements (
  KEY text PRIMARY KEY,
  css text,
  form text,
  custom_field2 text,
  vacancy_type text,
  custom_field3 text,
  active boolean,
  vacancy_responsibles text,
  job_site text,
  vacancy_email_notification text,
  custom_field4 text,
  vacancy_name text,
  startdate text,
  vacancy_id varint,
  custom_field5 text,
  html text,
  company_id varint,
  ctime text,
  title text,
  expires text,
  atime text,
  custom_field1 text,
  vacancy_language text,
  tags text,
  mtime text,
  mailapply boolean,
  vacancy_description text,
  vacancy_function text,
  shorthash text
) WITH
  comment='Advertisements' AND
  comparator=text AND
  read_repair_chance=1.00 AND
  gc_grace_seconds=864000 AND
  default_validation=text AND
  min_compaction_threshold=4 AND
  max_compaction_threshold=32 AND
  replicate_on_write='true' AND
  compaction_strategy_class='SizeTieredCompactionStrategy' AND
  compression_parameters:sstable_compression='SnappyCompressor';

CREATE INDEX rm_advertisements_active ON rm_advertisements (active);

CREATE INDEX rm_advertisements_job_site ON rm_advertisements (job_site);

CREATE INDEX rm_advertisements_vacancy_id ON rm_advertisements (vacancy_id);

CREATE INDEX rm_advertisements_company_id ON rm_advertisements (company_id);

CREATE INDEX rm_advertisements_title ON rm_advertisements (title);

CREATE INDEX rm_advertisements_expires ON rm_advertisements (expires);

CREATE INDEX rm_advertisements_vacancy_language ON rm_advertisements 
(vacancy_language);

CREATE INDEX rm_advertisements_mailapply ON rm_advertisements (mailapply);

CREATE INDEX rm_advertisements_shorthash ON rm_advertisements (shorthash);


  was:
Data is written to cassandra via phpcassa ( https://github.com/thobbs/phpcassa 
v1.0).

Inspection the records via cqlsh,the query with a WHERE statement doesn't 
deliver all records.

http://imageshack.us/photo/my-images/820/cassandraqueryissue.png/

I'am working with a 2 node cluster and the effect is the same on both nodes. 
Furthermore a nodetool repair, nodetool rebuild has no positive effect. The 
data type for this column is varint. 


**

DESCRIBE COLUMNFAMILY rm_advertisements

CREATE TABLE rm_advertisements (
  KEY text PRIMARY KEY,
  css text,
  form text,
  custom_field2 text,
  vacancy_type text,
  custom_field3 text,
  active boolean,
  vacancy_responsibles text,
  job_site text,
  vacancy_email_notification text,
  custom_field4 text,
  vacancy_name text,
  startdate text,
  vacancy_id varint,
  custom_field5 text,
  html text,
  company_id varint,
  ctime text,
  title text,
  expires text,
  atime text,
  custom_field1 text,
  vacancy_language text,
  tags text,
  mtime text,
  mailapply boolean,
  vacancy_description text,
  vacancy_function text,
  shorthash text
) WITH
  comment='Advertisements' AND
  comparator=text AND
  read_repair_chance=1.00 AND
  gc_grace_seconds=864000 AND
  default_validation=text AND
  min_compaction_threshold=4 AND
  max_compaction_threshold=32 AND
  replicate_on_write='true' AND
  compaction_strategy_class='SizeTieredCompactionStrategy' AND
  compression_parameters:sstable_compression='SnappyCompressor';

CREATE INDEX rm_advertisements_active ON rm_advertisements (active);

CREATE INDEX rm_advertisements_job_site ON rm_advertisements (job_site);

CREATE INDEX rm_advertisements_vacancy_id ON rm_advertisements (vacancy_id);

CREATE INDEX rm_advertisements_company_id ON rm_advertisements (company_id);

CREATE INDEX rm_advertisements_title ON rm_advertisements (title);

CREATE INDEX rm_advertisements_expires ON rm_advertisements (expires);

CREATE INDEX rm_advertisements_vacancy_language ON rm_advertisements 
(vacancy_language);

CREATE INDEX rm_advertisements_mailapply ON rm_advertisements (mailapply);

CREATE INDEX rm_advertisements_shorthash ON rm_advertisements (shorthash);



 Query with WHERE statement delivers wrong results
 -

 Key: CASSANDRA-4390
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4390
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.1
 Environment: Linux version 2.6.32-5-amd64 (Debian 2.6.32-45) |cqlsh 
 2.2.0 | Cassandra 1.1.1 |

[jira] [Updated] (CASSANDRA-4041) Allow updating column_alias types


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

Pavel Yaskevich updated CASSANDRA-4041:
---

Attachment: (was: CASSANDRA-4041-v2.patch)

 Allow updating column_alias types
 -

 Key: CASSANDRA-4041
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4041
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Pavel Yaskevich
Priority: Minor
 Fix For: 1.1.2

 Attachments: CASSANDRA-4041.patch


 CASSANDRA-3657 has added the ability to change comparators (including parts 
 of a compositeType) when compatible. The code of CQL3 forbids it currently 
 however so we should lift that limitation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4041) Allow updating column_alias types


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

Pavel Yaskevich updated CASSANDRA-4041:
---

Attachment: (was: CASSANDRA-4041-v2.patch)

 Allow updating column_alias types
 -

 Key: CASSANDRA-4041
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4041
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Pavel Yaskevich
Priority: Minor
 Fix For: 1.1.2

 Attachments: CASSANDRA-4041-v2.patch, CASSANDRA-4041.patch


 CASSANDRA-3657 has added the ability to change comparators (including parts 
 of a compositeType) when compatible. The code of CQL3 forbids it currently 
 however so we should lift that limitation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4041) Allow updating column_alias types


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

Pavel Yaskevich updated CASSANDRA-4041:
---

Attachment: CASSANDRA-4041-v2.patch

and removed final from the name definition :)

 Allow updating column_alias types
 -

 Key: CASSANDRA-4041
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4041
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Pavel Yaskevich
Priority: Minor
 Fix For: 1.1.2

 Attachments: CASSANDRA-4041-v2.patch, CASSANDRA-4041.patch


 CASSANDRA-3657 has added the ability to change comparators (including parts 
 of a compositeType) when compatible. The code of CQL3 forbids it currently 
 however so we should lift that limitation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4041) Allow updating column_alias types


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

Pavel Yaskevich updated CASSANDRA-4041:
---

Attachment: CASSANDRA-4041-v2.patch

I a bit misunderstood what you meant original so I removed {{ }} notation now 
and made set independent.

 Allow updating column_alias types
 -

 Key: CASSANDRA-4041
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4041
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Pavel Yaskevich
Priority: Minor
 Fix For: 1.1.2

 Attachments: CASSANDRA-4041-v2.patch, CASSANDRA-4041.patch


 CASSANDRA-3657 has added the ability to change comparators (including parts 
 of a compositeType) when compatible. The code of CQL3 forbids it currently 
 however so we should lift that limitation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4041) Allow updating column_alias types


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

Sylvain Lebresne commented on CASSANDRA-4041:
-

+1

 Allow updating column_alias types
 -

 Key: CASSANDRA-4041
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4041
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Pavel Yaskevich
Priority: Minor
 Fix For: 1.1.2

 Attachments: CASSANDRA-4041-v2.patch, CASSANDRA-4041.patch


 CASSANDRA-3657 has added the ability to change comparators (including parts 
 of a compositeType) when compatible. The code of CQL3 forbids it currently 
 however so we should lift that limitation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

git commit: (cql3) allow updating column_alias types patch by Pavel Yaskevich; reviewed by Sylvain Lebresne for CASSANDRA-4041

2012-06-28 Thread xedin

Updated Branches:
  refs/heads/cassandra-1.1 8a3bb80e0 - bc2dea8b6


(cql3) allow updating column_alias types
patch by Pavel Yaskevich; reviewed by Sylvain Lebresne for CASSANDRA-4041


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

Branch: refs/heads/cassandra-1.1
Commit: bc2dea8b67e783514f42d148541043c3d9fed1f3
Parents: 8a3bb80
Author: Pavel Yaskevich xe...@apache.org
Authored: Wed Jun 27 14:58:38 2012 +0300
Committer: Pavel Yaskevich xe...@apache.org
Committed: Thu Jun 28 15:56:20 2012 +0300

--
 CHANGES.txt|1 +
 .../cql3/statements/AlterTableStatement.java   |   13 -
 2 files changed, 9 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bc2dea8b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 8918dee..aa03655 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -21,6 +21,7 @@
(CASSANDRA-4365)
  * add strategy_options to the KSMetaData.toString() output (CASSANDRA-4248)
  * (cql3) fix range queries containing unqueried results (CASSANDRA-4372)
+ * (cql3) allow updating column_alias types (CASSANDRA-4041)
 Merged from 1.0:
  * Set gc_grace on index CF to 0 (CASSANDRA-4314)
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/bc2dea8b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
index 67b7dd7..6523a90 100644
--- a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
@@ -18,19 +18,16 @@
  */
 package org.apache.cassandra.cql3.statements;
 
-import java.io.IOException;
 import java.util.*;
 
 import org.apache.cassandra.cql3.*;
 import org.apache.cassandra.config.*;
-import org.apache.cassandra.io.compress.CompressionParameters;
 import org.apache.cassandra.db.marshal.AbstractType;
 import org.apache.cassandra.db.marshal.CompositeType;
 import org.apache.cassandra.db.marshal.CounterColumnType;
 import org.apache.cassandra.service.MigrationManager;
-import org.apache.cassandra.thrift.CfDef;
-import org.apache.cassandra.thrift.ColumnDef;
 import org.apache.cassandra.thrift.InvalidRequestException;
+
 import static 
org.apache.cassandra.thrift.ThriftValidation.validateColumnFamily;
 
 public class AlterTableStatement extends SchemaAlteringStatement
@@ -98,7 +95,13 @@ public class AlterTableStatement extends 
SchemaAlteringStatement
 cfm.keyValidator(newType);
 break;
 case COLUMN_ALIAS:
-throw new 
InvalidRequestException(String.format(Cannot alter PRIMARY KEY part %s, 
columnName));
+assert cfDef.isComposite;
+
+ListAbstractType? newTypes = new 
ArrayListAbstractType?(((CompositeType) cfm.comparator).types);
+newTypes.set(name.position, 
CFPropDefs.parseType(validator));
+
+cfm.comparator = CompositeType.getInstance(newTypes);
+break;
 case VALUE_ALIAS:
 cfm.defaultValidator(CFPropDefs.parseType(validator));
 break;

[jira] [Updated] (CASSANDRA-4389) HHOM.scheduleAllDeliveries still expects tokens as row keys


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

Sam Overton updated CASSANDRA-4389:
---

Affects Version/s: (was: 1.1.1)
   1.2

 HHOM.scheduleAllDeliveries still expects tokens as row keys
 ---

 Key: CASSANDRA-4389
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4389
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2
Reporter: Sam Overton
Assignee: Sam Overton
Priority: Minor
 Attachments: 4389.patch


 scheduleAllDeliveries needs updating to expect hostIds instead of tokens in 
 the HINTS_CF

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[2/2] git commit: (cql3) allow updating column_alias types patch by Pavel Yaskevich; reviewed by Sylvain Lebresne for CASSANDRA-4041

2012-06-28 Thread xedin

(cql3) allow updating column_alias types
patch by Pavel Yaskevich; reviewed by Sylvain Lebresne for CASSANDRA-4041


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

Branch: refs/heads/trunk
Commit: bc2dea8b67e783514f42d148541043c3d9fed1f3
Parents: 8a3bb80
Author: Pavel Yaskevich xe...@apache.org
Authored: Wed Jun 27 14:58:38 2012 +0300
Committer: Pavel Yaskevich xe...@apache.org
Committed: Thu Jun 28 15:56:20 2012 +0300

--
 CHANGES.txt|1 +
 .../cql3/statements/AlterTableStatement.java   |   13 -
 2 files changed, 9 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bc2dea8b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 8918dee..aa03655 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -21,6 +21,7 @@
(CASSANDRA-4365)
  * add strategy_options to the KSMetaData.toString() output (CASSANDRA-4248)
  * (cql3) fix range queries containing unqueried results (CASSANDRA-4372)
+ * (cql3) allow updating column_alias types (CASSANDRA-4041)
 Merged from 1.0:
  * Set gc_grace on index CF to 0 (CASSANDRA-4314)
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/bc2dea8b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
index 67b7dd7..6523a90 100644
--- a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
@@ -18,19 +18,16 @@
  */
 package org.apache.cassandra.cql3.statements;
 
-import java.io.IOException;
 import java.util.*;
 
 import org.apache.cassandra.cql3.*;
 import org.apache.cassandra.config.*;
-import org.apache.cassandra.io.compress.CompressionParameters;
 import org.apache.cassandra.db.marshal.AbstractType;
 import org.apache.cassandra.db.marshal.CompositeType;
 import org.apache.cassandra.db.marshal.CounterColumnType;
 import org.apache.cassandra.service.MigrationManager;
-import org.apache.cassandra.thrift.CfDef;
-import org.apache.cassandra.thrift.ColumnDef;
 import org.apache.cassandra.thrift.InvalidRequestException;
+
 import static 
org.apache.cassandra.thrift.ThriftValidation.validateColumnFamily;
 
 public class AlterTableStatement extends SchemaAlteringStatement
@@ -98,7 +95,13 @@ public class AlterTableStatement extends 
SchemaAlteringStatement
 cfm.keyValidator(newType);
 break;
 case COLUMN_ALIAS:
-throw new 
InvalidRequestException(String.format(Cannot alter PRIMARY KEY part %s, 
columnName));
+assert cfDef.isComposite;
+
+ListAbstractType? newTypes = new 
ArrayListAbstractType?(((CompositeType) cfm.comparator).types);
+newTypes.set(name.position, 
CFPropDefs.parseType(validator));
+
+cfm.comparator = CompositeType.getInstance(newTypes);
+break;
 case VALUE_ALIAS:
 cfm.defaultValidator(CFPropDefs.parseType(validator));
 break;

[1/2] git commit: merge from 1.1

2012-06-28 Thread xedin

Updated Branches:
  refs/heads/trunk 4725bf71e - 0c7833bd3


merge from 1.1


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

Branch: refs/heads/trunk
Commit: 0c7833bd3530707c393f13bfdac61ae6249947d5
Parents: 4725bf7 bc2dea8
Author: Pavel Yaskevich xe...@apache.org
Authored: Thu Jun 28 16:09:43 2012 +0300
Committer: Pavel Yaskevich xe...@apache.org
Committed: Thu Jun 28 16:09:43 2012 +0300

--
 CHANGES.txt|1 +
 .../cql3/statements/AlterTableStatement.java   |   13 -
 2 files changed, 9 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0c7833bd/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0c7833bd/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
--

[jira] [Commented] (CASSANDRA-4390) Query with WHERE statement delivers wrong results


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

Sylvain Lebresne commented on CASSANDRA-4390:
-

Do you also get wrong result when using cassandra-cli or when using phpcassa to 
fetch the results, or is that a CQL thing only?

 Query with WHERE statement delivers wrong results
 -

 Key: CASSANDRA-4390
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4390
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.1
 Environment: Linux version 2.6.32-5-amd64 (Debian 2.6.32-45) |cqlsh 
 2.2.0 | Cassandra 1.1.1 | CQL spec 2.0.0 | Thrift protocol 19.32.0]
Reporter: Stefan Häck
 Attachments: Cassandra_Query_Issue.png


 Data is written to cassandra via phpcassa ( 
 https://github.com/thobbs/phpcassa v1.0).
 Inspection the records via cqlsh,the query with a WHERE statement doesn't 
 deliver all records.
 https://issues.apache.org/jira/secure/attachment/12533818/Cassandra_Query_Issue.png
 I'am working with a 2 node cluster and the effect is the same on both nodes. 
 Furthermore a nodetool repair, nodetool rebuild has no positive effect. The 
 data type for this column is varint. 
 **
 DESCRIBE COLUMNFAMILY rm_advertisements
 CREATE TABLE rm_advertisements (
   KEY text PRIMARY KEY,
   css text,
   form text,
   custom_field2 text,
   vacancy_type text,
   custom_field3 text,
   active boolean,
   vacancy_responsibles text,
   job_site text,
   vacancy_email_notification text,
   custom_field4 text,
   vacancy_name text,
   startdate text,
   vacancy_id varint,
   custom_field5 text,
   html text,
   company_id varint,
   ctime text,
   title text,
   expires text,
   atime text,
   custom_field1 text,
   vacancy_language text,
   tags text,
   mtime text,
   mailapply boolean,
   vacancy_description text,
   vacancy_function text,
   shorthash text
 ) WITH
   comment='Advertisements' AND
   comparator=text AND
   read_repair_chance=1.00 AND
   gc_grace_seconds=864000 AND
   default_validation=text AND
   min_compaction_threshold=4 AND
   max_compaction_threshold=32 AND
   replicate_on_write='true' AND
   compaction_strategy_class='SizeTieredCompactionStrategy' AND
   compression_parameters:sstable_compression='SnappyCompressor';
 CREATE INDEX rm_advertisements_active ON rm_advertisements (active);
 CREATE INDEX rm_advertisements_job_site ON rm_advertisements (job_site);
 CREATE INDEX rm_advertisements_vacancy_id ON rm_advertisements (vacancy_id);
 CREATE INDEX rm_advertisements_company_id ON rm_advertisements (company_id);
 CREATE INDEX rm_advertisements_title ON rm_advertisements (title);
 CREATE INDEX rm_advertisements_expires ON rm_advertisements (expires);
 CREATE INDEX rm_advertisements_vacancy_language ON rm_advertisements 
 (vacancy_language);
 CREATE INDEX rm_advertisements_mailapply ON rm_advertisements (mailapply);
 CREATE INDEX rm_advertisements_shorthash ON rm_advertisements (shorthash);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4390) Query with WHERE statement delivers wrong results


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

Stefan Häck commented on CASSANDRA-4390:


I get the wrong results even with cassandra-cli also as with phpcassa.

 Query with WHERE statement delivers wrong results
 -

 Key: CASSANDRA-4390
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4390
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.1
 Environment: Linux version 2.6.32-5-amd64 (Debian 2.6.32-45) |cqlsh 
 2.2.0 | Cassandra 1.1.1 | CQL spec 2.0.0 | Thrift protocol 19.32.0]
Reporter: Stefan Häck
 Attachments: Cassandra_Query_Issue.png


 Data is written to cassandra via phpcassa ( 
 https://github.com/thobbs/phpcassa v1.0).
 Inspection the records via cqlsh,the query with a WHERE statement doesn't 
 deliver all records.
 https://issues.apache.org/jira/secure/attachment/12533818/Cassandra_Query_Issue.png
 I'am working with a 2 node cluster and the effect is the same on both nodes. 
 Furthermore a nodetool repair, nodetool rebuild has no positive effect. The 
 data type for this column is varint. 
 **
 DESCRIBE COLUMNFAMILY rm_advertisements
 CREATE TABLE rm_advertisements (
   KEY text PRIMARY KEY,
   css text,
   form text,
   custom_field2 text,
   vacancy_type text,
   custom_field3 text,
   active boolean,
   vacancy_responsibles text,
   job_site text,
   vacancy_email_notification text,
   custom_field4 text,
   vacancy_name text,
   startdate text,
   vacancy_id varint,
   custom_field5 text,
   html text,
   company_id varint,
   ctime text,
   title text,
   expires text,
   atime text,
   custom_field1 text,
   vacancy_language text,
   tags text,
   mtime text,
   mailapply boolean,
   vacancy_description text,
   vacancy_function text,
   shorthash text
 ) WITH
   comment='Advertisements' AND
   comparator=text AND
   read_repair_chance=1.00 AND
   gc_grace_seconds=864000 AND
   default_validation=text AND
   min_compaction_threshold=4 AND
   max_compaction_threshold=32 AND
   replicate_on_write='true' AND
   compaction_strategy_class='SizeTieredCompactionStrategy' AND
   compression_parameters:sstable_compression='SnappyCompressor';
 CREATE INDEX rm_advertisements_active ON rm_advertisements (active);
 CREATE INDEX rm_advertisements_job_site ON rm_advertisements (job_site);
 CREATE INDEX rm_advertisements_vacancy_id ON rm_advertisements (vacancy_id);
 CREATE INDEX rm_advertisements_company_id ON rm_advertisements (company_id);
 CREATE INDEX rm_advertisements_title ON rm_advertisements (title);
 CREATE INDEX rm_advertisements_expires ON rm_advertisements (expires);
 CREATE INDEX rm_advertisements_vacancy_language ON rm_advertisements 
 (vacancy_language);
 CREATE INDEX rm_advertisements_mailapply ON rm_advertisements (mailapply);
 CREATE INDEX rm_advertisements_shorthash ON rm_advertisements (shorthash);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4390) Query with WHERE statement delivers wrong results


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

Sylvain Lebresne commented on CASSANDRA-4390:
-

Have you tried a 'nodetool rebuild_index'?

 Query with WHERE statement delivers wrong results
 -

 Key: CASSANDRA-4390
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4390
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.1
 Environment: Linux version 2.6.32-5-amd64 (Debian 2.6.32-45) |cqlsh 
 2.2.0 | Cassandra 1.1.1 | CQL spec 2.0.0 | Thrift protocol 19.32.0]
Reporter: Stefan Häck
 Attachments: Cassandra_Query_Issue.png


 Data is written to cassandra via phpcassa ( 
 https://github.com/thobbs/phpcassa v1.0).
 Inspection the records via cqlsh,the query with a WHERE statement doesn't 
 deliver all records.
 https://issues.apache.org/jira/secure/attachment/12533818/Cassandra_Query_Issue.png
 I'am working with a 2 node cluster and the effect is the same on both nodes. 
 Furthermore a nodetool repair, nodetool rebuild has no positive effect. The 
 data type for this column is varint. 
 **
 DESCRIBE COLUMNFAMILY rm_advertisements
 CREATE TABLE rm_advertisements (
   KEY text PRIMARY KEY,
   css text,
   form text,
   custom_field2 text,
   vacancy_type text,
   custom_field3 text,
   active boolean,
   vacancy_responsibles text,
   job_site text,
   vacancy_email_notification text,
   custom_field4 text,
   vacancy_name text,
   startdate text,
   vacancy_id varint,
   custom_field5 text,
   html text,
   company_id varint,
   ctime text,
   title text,
   expires text,
   atime text,
   custom_field1 text,
   vacancy_language text,
   tags text,
   mtime text,
   mailapply boolean,
   vacancy_description text,
   vacancy_function text,
   shorthash text
 ) WITH
   comment='Advertisements' AND
   comparator=text AND
   read_repair_chance=1.00 AND
   gc_grace_seconds=864000 AND
   default_validation=text AND
   min_compaction_threshold=4 AND
   max_compaction_threshold=32 AND
   replicate_on_write='true' AND
   compaction_strategy_class='SizeTieredCompactionStrategy' AND
   compression_parameters:sstable_compression='SnappyCompressor';
 CREATE INDEX rm_advertisements_active ON rm_advertisements (active);
 CREATE INDEX rm_advertisements_job_site ON rm_advertisements (job_site);
 CREATE INDEX rm_advertisements_vacancy_id ON rm_advertisements (vacancy_id);
 CREATE INDEX rm_advertisements_company_id ON rm_advertisements (company_id);
 CREATE INDEX rm_advertisements_title ON rm_advertisements (title);
 CREATE INDEX rm_advertisements_expires ON rm_advertisements (expires);
 CREATE INDEX rm_advertisements_vacancy_language ON rm_advertisements 
 (vacancy_language);
 CREATE INDEX rm_advertisements_mailapply ON rm_advertisements (mailapply);
 CREATE INDEX rm_advertisements_shorthash ON rm_advertisements (shorthash);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4340) Cassandra upgrade to 1.1.1 resulted in slow query issue


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

Pavel Yaskevich commented on CASSANDRA-4340:


In the Cassandra starting from version 1.1.x key/row caches _per-CF_ was 
replaced with _global_ key/row caches configurable via conf/cassandra.yaml, did 
you try to tune up {key,row}_cache_size_in_mb properties after upgrade?

 Cassandra upgrade to 1.1.1 resulted in slow query issue
 ---

 Key: CASSANDRA-4340
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4340
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
 Environment: Ubuntu Linux, Java 7, Hector 1.0-1
Reporter: Ivan Ganza
Assignee: Pavel Yaskevich
 Fix For: 1.1.2

 Attachments: CassandraIssue.java


 We have recently introduced Cassandra at the Globe and Mail here in Toronto, 
 Canada.  We are processing and storing the North American stock-market feed.  
 We have found it to work very quickly and things have been looking very good.
 Recently we upgraded to version 1.1.1 and then we have noticed some issues 
 occurring.
 I will try to describe it for you here.  Basically one operation that we very 
 often perform and is very critical is the ability to 'get the latest quote'.  
 This would return to you the latest Quote adjusted against exchange delay 
 rules.  With Cassandra version 1.0.3 we could get a Quote in around 2ms.  
 After update we are looking at time of at least 2-3 seconds.
 The way we query the quote is using a REVERSED SuperSliceQuery  with 
 start=now, end=00:00:00.000 (beginning of day) LIMITED to 1.
 Our investigation leads us to suspect that, since upgrade, Cassandra seems to 
 be reading the sstable from disk even when we request a small range of day 
 only 5 seconds back.  If you look at the output below you can see that the 
 query does NOT get slower as the lookback increases from 5  sec, 60 sec, 15 
 min, 60 min, and 24 hours.
 We also noticed that the query was very fast for the first five minutes of 
 trading, apparently until the first sstable was flushed to disk.  After that 
 we go into query times of 1-2 seconds or so.
 Query time[lookback=5]:[1711ms]
 Query time[lookback=60]:[1592ms]
 Query time[lookback=900]:[1520ms]
 Query time[lookback=3600]:[1294ms]
 Query time[lookback=86400]:[1391ms]
 We would really appreciate input or help on this.
 Cassandra version: 1.1.1
 Hector version: 1.0-1
 ---
 public void testCassandraIssue() {
 try {
   int[] seconds = new int[]{ 5, 60, 60 * 15, 60 * 60, 60 * 60 
 * 24};
   for(int sec : seconds) {
 DateTime start = new DateTime();
 SuperSliceQueryString, String, String, String 
 superSliceQuery = HFactory.createSuperSliceQuery(keyspaceOperator, 
 StringSerializer.get(), StringSerializer.get(), StringSerializer.get(), 
 StringSerializer.get());
 superSliceQuery.setKey(101390 + . + 
 testFormatter.print(start));
 superSliceQuery.setColumnFamily(Quotes);
 
 superSliceQuery.setRange(superKeyFormatter.print(start),
 
 superKeyFormatter.print(start.minusSeconds(sec)),
 true,
 1);
 long theStart = System.currentTimeMillis();
 QueryResultSuperSliceString, String, String 
 result = superSliceQuery.execute();
 long end = System.currentTimeMillis();
 System.out.println(Query time[lookback= + sec + 
 ]:[ + (end - theStart) + ms]);
   }
 } catch(Exception e) {
   e.printStackTrace();
   fail(e.getMessage());
 }
   }
 ---
 create column family Quotes
 with column_type = Super
 and  comparator = BytesType
 and subcomparator = BytesType
 and keys_cached = 7000
 and rows_cached = 0
 and row_cache_save_period = 0
 and key_cache_save_period = 3600
 and memtable_throughput = 255
 and memtable_operations = 0.29
 AND compression_options={sstable_compression:SnappyCompressor, 
 chunk_length_kb:64};

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CASSANDRA-4340) Cassandra upgrade to 1.1.1 resulted in slow query issue


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

Pavel Yaskevich edited comment on CASSANDRA-4340 at 6/28/12 1:54 PM:
-

In the Cassandra starting from version 1.1.x key/row caches _per-CF_ was 
replaced with _global_ key/row caches configurable via conf/cassandra.yaml, did 
you try to tune up {key,row}_cache_size_in_mb properties after upgrade?

Edit: also configuration of the cache could be done via JMX using 
o.a.c.service.CacheServiceMBean

  was (Author: xedin):
In the Cassandra starting from version 1.1.x key/row caches _per-CF_ was 
replaced with _global_ key/row caches configurable via conf/cassandra.yaml, did 
you try to tune up {key,row}_cache_size_in_mb properties after upgrade?
  
 Cassandra upgrade to 1.1.1 resulted in slow query issue
 ---

 Key: CASSANDRA-4340
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4340
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
 Environment: Ubuntu Linux, Java 7, Hector 1.0-1
Reporter: Ivan Ganza
Assignee: Pavel Yaskevich
 Fix For: 1.1.2

 Attachments: CassandraIssue.java


 We have recently introduced Cassandra at the Globe and Mail here in Toronto, 
 Canada.  We are processing and storing the North American stock-market feed.  
 We have found it to work very quickly and things have been looking very good.
 Recently we upgraded to version 1.1.1 and then we have noticed some issues 
 occurring.
 I will try to describe it for you here.  Basically one operation that we very 
 often perform and is very critical is the ability to 'get the latest quote'.  
 This would return to you the latest Quote adjusted against exchange delay 
 rules.  With Cassandra version 1.0.3 we could get a Quote in around 2ms.  
 After update we are looking at time of at least 2-3 seconds.
 The way we query the quote is using a REVERSED SuperSliceQuery  with 
 start=now, end=00:00:00.000 (beginning of day) LIMITED to 1.
 Our investigation leads us to suspect that, since upgrade, Cassandra seems to 
 be reading the sstable from disk even when we request a small range of day 
 only 5 seconds back.  If you look at the output below you can see that the 
 query does NOT get slower as the lookback increases from 5  sec, 60 sec, 15 
 min, 60 min, and 24 hours.
 We also noticed that the query was very fast for the first five minutes of 
 trading, apparently until the first sstable was flushed to disk.  After that 
 we go into query times of 1-2 seconds or so.
 Query time[lookback=5]:[1711ms]
 Query time[lookback=60]:[1592ms]
 Query time[lookback=900]:[1520ms]
 Query time[lookback=3600]:[1294ms]
 Query time[lookback=86400]:[1391ms]
 We would really appreciate input or help on this.
 Cassandra version: 1.1.1
 Hector version: 1.0-1
 ---
 public void testCassandraIssue() {
 try {
   int[] seconds = new int[]{ 5, 60, 60 * 15, 60 * 60, 60 * 60 
 * 24};
   for(int sec : seconds) {
 DateTime start = new DateTime();
 SuperSliceQueryString, String, String, String 
 superSliceQuery = HFactory.createSuperSliceQuery(keyspaceOperator, 
 StringSerializer.get(), StringSerializer.get(), StringSerializer.get(), 
 StringSerializer.get());
 superSliceQuery.setKey(101390 + . + 
 testFormatter.print(start));
 superSliceQuery.setColumnFamily(Quotes);
 
 superSliceQuery.setRange(superKeyFormatter.print(start),
 
 superKeyFormatter.print(start.minusSeconds(sec)),
 true,
 1);
 long theStart = System.currentTimeMillis();
 QueryResultSuperSliceString, String, String 
 result = superSliceQuery.execute();
 long end = System.currentTimeMillis();
 System.out.println(Query time[lookback= + sec + 
 ]:[ + (end - theStart) + ms]);
   }
 } catch(Exception e) {
   e.printStackTrace();
   fail(e.getMessage());
 }
   }
 ---
 create column family Quotes
 with column_type = Super
 and  comparator = BytesType
 and subcomparator = BytesType
 and keys_cached = 7000
 and rows_cached = 0
 and row_cache_save_period = 0
 and key_cache_save_period = 3600
 and memtable_throughput = 255
 and memtable_operations = 0.29
 AND compression_options={sstable_compression:SnappyCompressor, 
 chunk_length_kb:64};

--
This message is automatically

[jira] [Commented] (CASSANDRA-4390) Query with WHERE statement delivers wrong results


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

Stefan Häck commented on CASSANDRA-4390:


That's it! It works. Thanks a lot for your support.

(Now I also found this thread: 
http://comments.gmane.org/gmane.comp.db.cassandra.user/26569 )



 Query with WHERE statement delivers wrong results
 -

 Key: CASSANDRA-4390
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4390
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.1
 Environment: Linux version 2.6.32-5-amd64 (Debian 2.6.32-45) |cqlsh 
 2.2.0 | Cassandra 1.1.1 | CQL spec 2.0.0 | Thrift protocol 19.32.0]
Reporter: Stefan Häck
 Attachments: Cassandra_Query_Issue.png


 Data is written to cassandra via phpcassa ( 
 https://github.com/thobbs/phpcassa v1.0).
 Inspection the records via cqlsh,the query with a WHERE statement doesn't 
 deliver all records.
 https://issues.apache.org/jira/secure/attachment/12533818/Cassandra_Query_Issue.png
 I'am working with a 2 node cluster and the effect is the same on both nodes. 
 Furthermore a nodetool repair, nodetool rebuild has no positive effect. The 
 data type for this column is varint. 
 **
 DESCRIBE COLUMNFAMILY rm_advertisements
 CREATE TABLE rm_advertisements (
   KEY text PRIMARY KEY,
   css text,
   form text,
   custom_field2 text,
   vacancy_type text,
   custom_field3 text,
   active boolean,
   vacancy_responsibles text,
   job_site text,
   vacancy_email_notification text,
   custom_field4 text,
   vacancy_name text,
   startdate text,
   vacancy_id varint,
   custom_field5 text,
   html text,
   company_id varint,
   ctime text,
   title text,
   expires text,
   atime text,
   custom_field1 text,
   vacancy_language text,
   tags text,
   mtime text,
   mailapply boolean,
   vacancy_description text,
   vacancy_function text,
   shorthash text
 ) WITH
   comment='Advertisements' AND
   comparator=text AND
   read_repair_chance=1.00 AND
   gc_grace_seconds=864000 AND
   default_validation=text AND
   min_compaction_threshold=4 AND
   max_compaction_threshold=32 AND
   replicate_on_write='true' AND
   compaction_strategy_class='SizeTieredCompactionStrategy' AND
   compression_parameters:sstable_compression='SnappyCompressor';
 CREATE INDEX rm_advertisements_active ON rm_advertisements (active);
 CREATE INDEX rm_advertisements_job_site ON rm_advertisements (job_site);
 CREATE INDEX rm_advertisements_vacancy_id ON rm_advertisements (vacancy_id);
 CREATE INDEX rm_advertisements_company_id ON rm_advertisements (company_id);
 CREATE INDEX rm_advertisements_title ON rm_advertisements (title);
 CREATE INDEX rm_advertisements_expires ON rm_advertisements (expires);
 CREATE INDEX rm_advertisements_vacancy_language ON rm_advertisements 
 (vacancy_language);
 CREATE INDEX rm_advertisements_mailapply ON rm_advertisements (mailapply);
 CREATE INDEX rm_advertisements_shorthash ON rm_advertisements (shorthash);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CASSANDRA-4390) Query with WHERE statement delivers wrong results


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

Stefan Häck resolved CASSANDRA-4390.


Resolution: Fixed

 Query with WHERE statement delivers wrong results
 -

 Key: CASSANDRA-4390
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4390
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.1
 Environment: Linux version 2.6.32-5-amd64 (Debian 2.6.32-45) |cqlsh 
 2.2.0 | Cassandra 1.1.1 | CQL spec 2.0.0 | Thrift protocol 19.32.0]
Reporter: Stefan Häck
 Attachments: Cassandra_Query_Issue.png


 Data is written to cassandra via phpcassa ( 
 https://github.com/thobbs/phpcassa v1.0).
 Inspection the records via cqlsh,the query with a WHERE statement doesn't 
 deliver all records.
 https://issues.apache.org/jira/secure/attachment/12533818/Cassandra_Query_Issue.png
 I'am working with a 2 node cluster and the effect is the same on both nodes. 
 Furthermore a nodetool repair, nodetool rebuild has no positive effect. The 
 data type for this column is varint. 
 **
 DESCRIBE COLUMNFAMILY rm_advertisements
 CREATE TABLE rm_advertisements (
   KEY text PRIMARY KEY,
   css text,
   form text,
   custom_field2 text,
   vacancy_type text,
   custom_field3 text,
   active boolean,
   vacancy_responsibles text,
   job_site text,
   vacancy_email_notification text,
   custom_field4 text,
   vacancy_name text,
   startdate text,
   vacancy_id varint,
   custom_field5 text,
   html text,
   company_id varint,
   ctime text,
   title text,
   expires text,
   atime text,
   custom_field1 text,
   vacancy_language text,
   tags text,
   mtime text,
   mailapply boolean,
   vacancy_description text,
   vacancy_function text,
   shorthash text
 ) WITH
   comment='Advertisements' AND
   comparator=text AND
   read_repair_chance=1.00 AND
   gc_grace_seconds=864000 AND
   default_validation=text AND
   min_compaction_threshold=4 AND
   max_compaction_threshold=32 AND
   replicate_on_write='true' AND
   compaction_strategy_class='SizeTieredCompactionStrategy' AND
   compression_parameters:sstable_compression='SnappyCompressor';
 CREATE INDEX rm_advertisements_active ON rm_advertisements (active);
 CREATE INDEX rm_advertisements_job_site ON rm_advertisements (job_site);
 CREATE INDEX rm_advertisements_vacancy_id ON rm_advertisements (vacancy_id);
 CREATE INDEX rm_advertisements_company_id ON rm_advertisements (company_id);
 CREATE INDEX rm_advertisements_title ON rm_advertisements (title);
 CREATE INDEX rm_advertisements_expires ON rm_advertisements (expires);
 CREATE INDEX rm_advertisements_vacancy_language ON rm_advertisements 
 (vacancy_language);
 CREATE INDEX rm_advertisements_mailapply ON rm_advertisements (mailapply);
 CREATE INDEX rm_advertisements_shorthash ON rm_advertisements (shorthash);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (CASSANDRA-4390) Query with WHERE statement delivers wrong results


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

Stefan Häck closed CASSANDRA-4390.
--


 Query with WHERE statement delivers wrong results
 -

 Key: CASSANDRA-4390
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4390
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.1
 Environment: Linux version 2.6.32-5-amd64 (Debian 2.6.32-45) |cqlsh 
 2.2.0 | Cassandra 1.1.1 | CQL spec 2.0.0 | Thrift protocol 19.32.0]
Reporter: Stefan Häck
 Attachments: Cassandra_Query_Issue.png


 Data is written to cassandra via phpcassa ( 
 https://github.com/thobbs/phpcassa v1.0).
 Inspection the records via cqlsh,the query with a WHERE statement doesn't 
 deliver all records.
 https://issues.apache.org/jira/secure/attachment/12533818/Cassandra_Query_Issue.png
 I'am working with a 2 node cluster and the effect is the same on both nodes. 
 Furthermore a nodetool repair, nodetool rebuild has no positive effect. The 
 data type for this column is varint. 
 **
 DESCRIBE COLUMNFAMILY rm_advertisements
 CREATE TABLE rm_advertisements (
   KEY text PRIMARY KEY,
   css text,
   form text,
   custom_field2 text,
   vacancy_type text,
   custom_field3 text,
   active boolean,
   vacancy_responsibles text,
   job_site text,
   vacancy_email_notification text,
   custom_field4 text,
   vacancy_name text,
   startdate text,
   vacancy_id varint,
   custom_field5 text,
   html text,
   company_id varint,
   ctime text,
   title text,
   expires text,
   atime text,
   custom_field1 text,
   vacancy_language text,
   tags text,
   mtime text,
   mailapply boolean,
   vacancy_description text,
   vacancy_function text,
   shorthash text
 ) WITH
   comment='Advertisements' AND
   comparator=text AND
   read_repair_chance=1.00 AND
   gc_grace_seconds=864000 AND
   default_validation=text AND
   min_compaction_threshold=4 AND
   max_compaction_threshold=32 AND
   replicate_on_write='true' AND
   compaction_strategy_class='SizeTieredCompactionStrategy' AND
   compression_parameters:sstable_compression='SnappyCompressor';
 CREATE INDEX rm_advertisements_active ON rm_advertisements (active);
 CREATE INDEX rm_advertisements_job_site ON rm_advertisements (job_site);
 CREATE INDEX rm_advertisements_vacancy_id ON rm_advertisements (vacancy_id);
 CREATE INDEX rm_advertisements_company_id ON rm_advertisements (company_id);
 CREATE INDEX rm_advertisements_title ON rm_advertisements (title);
 CREATE INDEX rm_advertisements_expires ON rm_advertisements (expires);
 CREATE INDEX rm_advertisements_vacancy_language ON rm_advertisements 
 (vacancy_language);
 CREATE INDEX rm_advertisements_mailapply ON rm_advertisements (mailapply);
 CREATE INDEX rm_advertisements_shorthash ON rm_advertisements (shorthash);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4390) Query with WHERE statement delivers wrong results


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

Sylvain Lebresne commented on CASSANDRA-4390:
-

I guess that doesn't explain why the 2ndary index was not up to date in the 
first place but glad that fixed it for you.

 Query with WHERE statement delivers wrong results
 -

 Key: CASSANDRA-4390
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4390
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.1
 Environment: Linux version 2.6.32-5-amd64 (Debian 2.6.32-45) |cqlsh 
 2.2.0 | Cassandra 1.1.1 | CQL spec 2.0.0 | Thrift protocol 19.32.0]
Reporter: Stefan Häck
 Attachments: Cassandra_Query_Issue.png


 Data is written to cassandra via phpcassa ( 
 https://github.com/thobbs/phpcassa v1.0).
 Inspection the records via cqlsh,the query with a WHERE statement doesn't 
 deliver all records.
 https://issues.apache.org/jira/secure/attachment/12533818/Cassandra_Query_Issue.png
 I'am working with a 2 node cluster and the effect is the same on both nodes. 
 Furthermore a nodetool repair, nodetool rebuild has no positive effect. The 
 data type for this column is varint. 
 **
 DESCRIBE COLUMNFAMILY rm_advertisements
 CREATE TABLE rm_advertisements (
   KEY text PRIMARY KEY,
   css text,
   form text,
   custom_field2 text,
   vacancy_type text,
   custom_field3 text,
   active boolean,
   vacancy_responsibles text,
   job_site text,
   vacancy_email_notification text,
   custom_field4 text,
   vacancy_name text,
   startdate text,
   vacancy_id varint,
   custom_field5 text,
   html text,
   company_id varint,
   ctime text,
   title text,
   expires text,
   atime text,
   custom_field1 text,
   vacancy_language text,
   tags text,
   mtime text,
   mailapply boolean,
   vacancy_description text,
   vacancy_function text,
   shorthash text
 ) WITH
   comment='Advertisements' AND
   comparator=text AND
   read_repair_chance=1.00 AND
   gc_grace_seconds=864000 AND
   default_validation=text AND
   min_compaction_threshold=4 AND
   max_compaction_threshold=32 AND
   replicate_on_write='true' AND
   compaction_strategy_class='SizeTieredCompactionStrategy' AND
   compression_parameters:sstable_compression='SnappyCompressor';
 CREATE INDEX rm_advertisements_active ON rm_advertisements (active);
 CREATE INDEX rm_advertisements_job_site ON rm_advertisements (job_site);
 CREATE INDEX rm_advertisements_vacancy_id ON rm_advertisements (vacancy_id);
 CREATE INDEX rm_advertisements_company_id ON rm_advertisements (company_id);
 CREATE INDEX rm_advertisements_title ON rm_advertisements (title);
 CREATE INDEX rm_advertisements_expires ON rm_advertisements (expires);
 CREATE INDEX rm_advertisements_vacancy_language ON rm_advertisements 
 (vacancy_language);
 CREATE INDEX rm_advertisements_mailapply ON rm_advertisements (mailapply);
 CREATE INDEX rm_advertisements_shorthash ON rm_advertisements (shorthash);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4340) Cassandra upgrade to 1.1.1 resulted in slow query issue

2012-06-28 Thread Ivan Ganza (JIRA)


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

Ivan Ganza commented on CASSANDRA-4340:
---

We didn't use row caching on the Quotes CF prior to the upgrade and the 
response times were acceptable. We did try enabling row caching on the Quotes 
CF after the upgrade. Because Quotes has wide rows, the 
SerializingCacheProvider did not help much and resulted in instability. The 
ConcurrentLinkedHashmap provider does help, but the cache misses are still in 
the 2 second range. 

Normally, we query recent data in the Quotes CF. In fact, it is possible to 
truncate this CF daily because the older data in it is not useful. On past 
versions of Cassandra, the data for our column slices appears to come from 
memtables almost exclusively. On 1.1.1, we get great performance right up to 
the point in which the first sstable is written to disk. Then query performance 
(on cache misses if caching is enabled) degrades gradually throughout the day. 

We suspected an issue with the bloom filters, so we tried running nodetool 
upgradesstables, but it did not help query performance. 


 Cassandra upgrade to 1.1.1 resulted in slow query issue
 ---

 Key: CASSANDRA-4340
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4340
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
 Environment: Ubuntu Linux, Java 7, Hector 1.0-1
Reporter: Ivan Ganza
Assignee: Pavel Yaskevich
 Fix For: 1.1.2

 Attachments: CassandraIssue.java


 We have recently introduced Cassandra at the Globe and Mail here in Toronto, 
 Canada.  We are processing and storing the North American stock-market feed.  
 We have found it to work very quickly and things have been looking very good.
 Recently we upgraded to version 1.1.1 and then we have noticed some issues 
 occurring.
 I will try to describe it for you here.  Basically one operation that we very 
 often perform and is very critical is the ability to 'get the latest quote'.  
 This would return to you the latest Quote adjusted against exchange delay 
 rules.  With Cassandra version 1.0.3 we could get a Quote in around 2ms.  
 After update we are looking at time of at least 2-3 seconds.
 The way we query the quote is using a REVERSED SuperSliceQuery  with 
 start=now, end=00:00:00.000 (beginning of day) LIMITED to 1.
 Our investigation leads us to suspect that, since upgrade, Cassandra seems to 
 be reading the sstable from disk even when we request a small range of day 
 only 5 seconds back.  If you look at the output below you can see that the 
 query does NOT get slower as the lookback increases from 5  sec, 60 sec, 15 
 min, 60 min, and 24 hours.
 We also noticed that the query was very fast for the first five minutes of 
 trading, apparently until the first sstable was flushed to disk.  After that 
 we go into query times of 1-2 seconds or so.
 Query time[lookback=5]:[1711ms]
 Query time[lookback=60]:[1592ms]
 Query time[lookback=900]:[1520ms]
 Query time[lookback=3600]:[1294ms]
 Query time[lookback=86400]:[1391ms]
 We would really appreciate input or help on this.
 Cassandra version: 1.1.1
 Hector version: 1.0-1
 ---
 public void testCassandraIssue() {
 try {
   int[] seconds = new int[]{ 5, 60, 60 * 15, 60 * 60, 60 * 60 
 * 24};
   for(int sec : seconds) {
 DateTime start = new DateTime();
 SuperSliceQueryString, String, String, String 
 superSliceQuery = HFactory.createSuperSliceQuery(keyspaceOperator, 
 StringSerializer.get(), StringSerializer.get(), StringSerializer.get(), 
 StringSerializer.get());
 superSliceQuery.setKey(101390 + . + 
 testFormatter.print(start));
 superSliceQuery.setColumnFamily(Quotes);
 
 superSliceQuery.setRange(superKeyFormatter.print(start),
 
 superKeyFormatter.print(start.minusSeconds(sec)),
 true,
 1);
 long theStart = System.currentTimeMillis();
 QueryResultSuperSliceString, String, String 
 result = superSliceQuery.execute();
 long end = System.currentTimeMillis();
 System.out.println(Query time[lookback= + sec + 
 ]:[ + (end - theStart) + ms]);
   }
 } catch(Exception e) {
   e.printStackTrace();
   fail(e.getMessage());
 }
   }
 ---
 create column family Quotes
 with column_type = Super
 and  comparator = BytesType
 and subcomparator =

[jira] [Commented] (CASSANDRA-4384) HintedHandoff can begin before SS knows the hostID


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

Sam Overton commented on CASSANDRA-4384:


When a node first starts up without a hostId map, it may be asked to store a 
hint for a node which is down and it won't know the hostId of that node since 
it never saw it alive.

We should persist the hostIds to prevent both of these cases where we are 
missing required information when we first start up.



 HintedHandoff can begin before SS knows the hostID
 --

 Key: CASSANDRA-4384
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4384
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2
Reporter: Brandon Williams
Assignee: Brandon Williams
 Fix For: 1.2


 Since HH fires from the FD, SS won't quite have the hostId yet:
 {noformat}
  INFO 18:58:04,196 Started hinted handoff for host: null with IP: 
 /10.179.65.102
  INFO 18:58:04,197 Node /10.179.65.102 state jump to normal
 ERROR 18:58:04,197 Exception in thread Thread[HintedHandoff:1,1,main]
 java.lang.NullPointerException
 at org.apache.cassandra.utils.UUIDGen.decompose(UUIDGen.java:120)
 at 
 org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpointInternal(HintedHandOffManager.java:304)
 at 
 org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:250)
 at 
 org.apache.cassandra.db.HintedHandOffManager.access$400(HintedHandOffManager.java:87)
 at 
 org.apache.cassandra.db.HintedHandOffManager$4.runMayThrow(HintedHandOffManager.java:433)
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:26)
 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)
 {noformat}
 Simple solution seems to be getting the hostId from gossip instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3380) REST Layer


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

Jeremy Hanna commented on CASSANDRA-3380:
-

Brian: how much uptake have you seen of the rest based interface and other 
capabilities of virgil?  It's been some time and sounds like you've had some 
decent success with all of your efforts and I wondered if there's a point to 
circle back and unify things so that Cassandra core could benefit.  I'm just a 
contributor, but just trying to see if it's time to reconsider these things or 
if the separated out interface is fine as it is.

 REST Layer 
 ---

 Key: CASSANDRA-3380
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3380
 Project: Cassandra
  Issue Type: New Feature
 Environment: Unix / Max OS X
Reporter: Brian ONeill
 Attachments: trunk-3380.txt


 This is a native rest layer for Cassandra implementing 
 AbstractCassandraDaemon.
 It uses JAX-RS fueled by Apache CXF.
 Presently it supports the following operations JSON over HTTP:
  - Create keyspace
  - Drop keyspace
  - Create column family
  - Drop column family
  - Insert row
  - Fetch row
  - Delete row
  - Insert column
  - Delete column 
  - Fetch column
 The patch creates a new project in contrib/rest.  You can compile the project 
 using ant, which uses ivy to pull in dependencies.  To get setup, you can 
 also use the pom.xml file and m2eclipse to get it into Eclipse.
 Once compiled, simpy run bin/rest_cassandra and follow along in the 
 README.txt

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4389) HHOM.scheduleAllDeliveries still expects tokens as row keys

2012-06-28 Thread Eric Evans (JIRA)


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

Eric Evans updated CASSANDRA-4389:
--

Reviewer: urandom

 HHOM.scheduleAllDeliveries still expects tokens as row keys
 ---

 Key: CASSANDRA-4389
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4389
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2
Reporter: Sam Overton
Assignee: Sam Overton
Priority: Minor
 Attachments: 4389.patch


 scheduleAllDeliveries needs updating to expect hostIds instead of tokens in 
 the HINTS_CF

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4340) Cassandra upgrade to 1.1.1 resulted in slow query issue


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

Pavel Yaskevich commented on CASSANDRA-4340:


I did check the get_slice path and didn't found any significant difference 
between 1.0 and 1.1.1. I see that 'create column family' CLI statement in 
description still uses memtable_* options, have you tried making your memtables 
bigger to accomodate more updates (as result that would produce less SSTables)? 
How about the key cache, what is a hit rate? What compaction activity are you 
seeing (also interesting if memtable flush rate is different from 1.0)? It 
would be great if you could attach to one of the nodes with profiler (say 
YourKit) and profile what method is the most contended...

 Cassandra upgrade to 1.1.1 resulted in slow query issue
 ---

 Key: CASSANDRA-4340
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4340
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
 Environment: Ubuntu Linux, Java 7, Hector 1.0-1
Reporter: Ivan Ganza
Assignee: Pavel Yaskevich
 Fix For: 1.1.2

 Attachments: CassandraIssue.java


 We have recently introduced Cassandra at the Globe and Mail here in Toronto, 
 Canada.  We are processing and storing the North American stock-market feed.  
 We have found it to work very quickly and things have been looking very good.
 Recently we upgraded to version 1.1.1 and then we have noticed some issues 
 occurring.
 I will try to describe it for you here.  Basically one operation that we very 
 often perform and is very critical is the ability to 'get the latest quote'.  
 This would return to you the latest Quote adjusted against exchange delay 
 rules.  With Cassandra version 1.0.3 we could get a Quote in around 2ms.  
 After update we are looking at time of at least 2-3 seconds.
 The way we query the quote is using a REVERSED SuperSliceQuery  with 
 start=now, end=00:00:00.000 (beginning of day) LIMITED to 1.
 Our investigation leads us to suspect that, since upgrade, Cassandra seems to 
 be reading the sstable from disk even when we request a small range of day 
 only 5 seconds back.  If you look at the output below you can see that the 
 query does NOT get slower as the lookback increases from 5  sec, 60 sec, 15 
 min, 60 min, and 24 hours.
 We also noticed that the query was very fast for the first five minutes of 
 trading, apparently until the first sstable was flushed to disk.  After that 
 we go into query times of 1-2 seconds or so.
 Query time[lookback=5]:[1711ms]
 Query time[lookback=60]:[1592ms]
 Query time[lookback=900]:[1520ms]
 Query time[lookback=3600]:[1294ms]
 Query time[lookback=86400]:[1391ms]
 We would really appreciate input or help on this.
 Cassandra version: 1.1.1
 Hector version: 1.0-1
 ---
 public void testCassandraIssue() {
 try {
   int[] seconds = new int[]{ 5, 60, 60 * 15, 60 * 60, 60 * 60 
 * 24};
   for(int sec : seconds) {
 DateTime start = new DateTime();
 SuperSliceQueryString, String, String, String 
 superSliceQuery = HFactory.createSuperSliceQuery(keyspaceOperator, 
 StringSerializer.get(), StringSerializer.get(), StringSerializer.get(), 
 StringSerializer.get());
 superSliceQuery.setKey(101390 + . + 
 testFormatter.print(start));
 superSliceQuery.setColumnFamily(Quotes);
 
 superSliceQuery.setRange(superKeyFormatter.print(start),
 
 superKeyFormatter.print(start.minusSeconds(sec)),
 true,
 1);
 long theStart = System.currentTimeMillis();
 QueryResultSuperSliceString, String, String 
 result = superSliceQuery.execute();
 long end = System.currentTimeMillis();
 System.out.println(Query time[lookback= + sec + 
 ]:[ + (end - theStart) + ms]);
   }
 } catch(Exception e) {
   e.printStackTrace();
   fail(e.getMessage());
 }
   }
 ---
 create column family Quotes
 with column_type = Super
 and  comparator = BytesType
 and subcomparator = BytesType
 and keys_cached = 7000
 and rows_cached = 0
 and row_cache_save_period = 0
 and key_cache_save_period = 3600
 and memtable_throughput = 255
 and memtable_operations = 0.29
 AND compression_options={sstable_compression:SnappyCompressor, 
 chunk_length_kb:64};

--
This message is automatically generated by JIRA.
If you think it was sent

[jira] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal


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

Luís Ferreira commented on CASSANDRA-2231:
--

Hi,

I've patched a 0.7.9 version of cassandra with this patch plus the one on 
CASSANDRA-2355, and got no errors, but when running it I get:

{code}
Invalid access of stack red zone 0x100401fe8 rip=0x1010c8f5e
{code}

I create the column family as so:

{code}
CfDef base_columns_cf_definition = new CfDef();
base_columns_cf_definition.setName(BaseColumns_CF);
base_columns_cf_definition.setColumn_type(Standard);
base_columns_cf_definition.setComparator_type(CompositeType(BytesType,BytesType));
base_columns_cf_definition.setKeyspace(Table+this.getContainerid())
{code}

I would really like to have this feature, but I cannot upgrade to version 
0.8.1. What am I doing wrong?


 Add CompositeType comparer to the comparers provided in 
 org.apache.cassandra.db.marshal
 ---

 Key: CASSANDRA-2231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
 Project: Cassandra
  Issue Type: New Feature
  Components: Contrib
Reporter: Ed Anuff
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 0.8.1

 Attachments: 
 0001-Add-compositeType-and-DynamicCompositeType-v2.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v3.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v4.patch, 
 0001-Add-compositeType-and-DynamicCompositeType_0.7.patch, 
 CompositeType-and-DynamicCompositeType.patch, 
 edanuff-CassandraCompositeType-1e253c4.zip


 CompositeType is a custom comparer that makes it possible to create 
 comparable composite values out of the basic types that Cassandra currently 
 supports, such as Long, UUID, etc.  This is very useful in both the creation 
 of custom inverted indexes using columns in a skinny row, where each column 
 name is a composite value, and also when using Cassandra's built-in secondary 
 index support, where it can be used to encode the values in the columns that 
 Cassandra indexes.  One scenario for the usage of these is documented here: 
 http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
 contribution is attached and has been previously maintained on github here: 
 https://github.com/edanuff/CassandraCompositeType

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal


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

Sylvain Lebresne commented on CASSANDRA-2231:
-

{quote}
I've patched a 0.7.9 version of cassandra with this patch plus the one on 
CASSANDRA-2355, and got no errors, but when running it I get:
{noformat}
Invalid access of stack red zone 0x100401fe8 rip=0x1010c8f5e
{noformat}
{quote}

That really sound like a JVM bug, so I very much doubt the patch here has 
anything to do with that (since they don't use anything unsafe in particular). 
You could check if the JVM you are using is up to date, and preferably use a 
sun JVM (because that's what more tested).

 Add CompositeType comparer to the comparers provided in 
 org.apache.cassandra.db.marshal
 ---

 Key: CASSANDRA-2231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
 Project: Cassandra
  Issue Type: New Feature
  Components: Contrib
Reporter: Ed Anuff
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 0.8.1

 Attachments: 
 0001-Add-compositeType-and-DynamicCompositeType-v2.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v3.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v4.patch, 
 0001-Add-compositeType-and-DynamicCompositeType_0.7.patch, 
 CompositeType-and-DynamicCompositeType.patch, 
 edanuff-CassandraCompositeType-1e253c4.zip


 CompositeType is a custom comparer that makes it possible to create 
 comparable composite values out of the basic types that Cassandra currently 
 supports, such as Long, UUID, etc.  This is very useful in both the creation 
 of custom inverted indexes using columns in a skinny row, where each column 
 name is a composite value, and also when using Cassandra's built-in secondary 
 index support, where it can be used to encode the values in the columns that 
 Cassandra indexes.  One scenario for the usage of these is documented here: 
 http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
 contribution is attached and has been previously maintained on github here: 
 https://github.com/edanuff/CassandraCompositeType

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4321) stackoverflow building interval tree possible sstable corruptions


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

Sylvain Lebresne updated CASSANDRA-4321:


Attachment: (was: 0002-Scrub-detects-and-repair-outOfOrder-rows-v6.txt)

 stackoverflow building interval tree  possible sstable corruptions
 ---

 Key: CASSANDRA-4321
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4321
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
Reporter: Anton Winter
Assignee: Sylvain Lebresne
 Fix For: 1.1.2

 Attachments: ooyala-hastur-stacktrace.txt


 After upgrading to 1.1.1 (from 1.1.0) I have started experiencing 
 StackOverflowError's resulting in compaction backlog and failure to restart. 
 The ring currently consists of 6 DC's and 22 nodes using LCS  compression.  
 This issue was first noted on 2 nodes in one DC and then appears to have 
 spread to various other nodes in the other DC's.  
 When the first occurrence of this was found I restarted the instance but it 
 failed to start so I cleared its data and treated it as a replacement node 
 for the token it was previously responsible for.  This node successfully 
 streamed all the relevant data back but failed again a number of hours later 
 with the same StackOverflowError and again was unable to restart. 
 The initial stack overflow error on a running instance looks like this:
 ERROR [CompactionExecutor:314] 2012-06-07 09:59:43,017 
 AbstractCassandraDaemon.java (line 134) Exception in thread 
 Thread[CompactionExecutor:314,1,main]
 java.lang.StackOverflowError
 at java.util.Arrays.mergeSort(Arrays.java:1157)
 at java.util.Arrays.sort(Arrays.java:1092)
 at java.util.Collections.sort(Collections.java:134)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.findMinMedianMax(IntervalNode.java:114)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:49)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 [snip - this repeats until stack overflow.  Compactions stop from this point 
 onwards]
 I restarted this failing instance with DEBUG logging enabled and it throws 
 the following exception part way through startup:
 ERROR 11:37:51,046 Exception in thread Thread[OptionalTasks:1,5,main]
 java.lang.StackOverflowError
 at 
 org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:307)
 at 
 org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:276)
 at 
 org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:230)
 at 
 org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124)
 at 
 org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:228)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:45)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 [snip - this repeats until stack overflow]
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalTree.init(IntervalTree.java:39)
 at 
 org.apache.cassandra.db.DataTracker.buildIntervalTree(DataTracker.java:560)
 at 
 org.apache.cassandra.db.DataTracker$View.replace(DataTracker.java:617)
 at org.apache.cassandra.db.DataTracker.replace(DataTracker.java:320)
 at

[jira] [Updated] (CASSANDRA-4321) stackoverflow building interval tree possible sstable corruptions


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

Sylvain Lebresne updated CASSANDRA-4321:


Attachment: (was: 0003-Create-standalone-scrub-v6.txt)

 stackoverflow building interval tree  possible sstable corruptions
 ---

 Key: CASSANDRA-4321
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4321
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
Reporter: Anton Winter
Assignee: Sylvain Lebresne
 Fix For: 1.1.2

 Attachments: ooyala-hastur-stacktrace.txt


 After upgrading to 1.1.1 (from 1.1.0) I have started experiencing 
 StackOverflowError's resulting in compaction backlog and failure to restart. 
 The ring currently consists of 6 DC's and 22 nodes using LCS  compression.  
 This issue was first noted on 2 nodes in one DC and then appears to have 
 spread to various other nodes in the other DC's.  
 When the first occurrence of this was found I restarted the instance but it 
 failed to start so I cleared its data and treated it as a replacement node 
 for the token it was previously responsible for.  This node successfully 
 streamed all the relevant data back but failed again a number of hours later 
 with the same StackOverflowError and again was unable to restart. 
 The initial stack overflow error on a running instance looks like this:
 ERROR [CompactionExecutor:314] 2012-06-07 09:59:43,017 
 AbstractCassandraDaemon.java (line 134) Exception in thread 
 Thread[CompactionExecutor:314,1,main]
 java.lang.StackOverflowError
 at java.util.Arrays.mergeSort(Arrays.java:1157)
 at java.util.Arrays.sort(Arrays.java:1092)
 at java.util.Collections.sort(Collections.java:134)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.findMinMedianMax(IntervalNode.java:114)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:49)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 [snip - this repeats until stack overflow.  Compactions stop from this point 
 onwards]
 I restarted this failing instance with DEBUG logging enabled and it throws 
 the following exception part way through startup:
 ERROR 11:37:51,046 Exception in thread Thread[OptionalTasks:1,5,main]
 java.lang.StackOverflowError
 at 
 org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:307)
 at 
 org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:276)
 at 
 org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:230)
 at 
 org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124)
 at 
 org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:228)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:45)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 [snip - this repeats until stack overflow]
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalTree.init(IntervalTree.java:39)
 at 
 org.apache.cassandra.db.DataTracker.buildIntervalTree(DataTracker.java:560)
 at 
 org.apache.cassandra.db.DataTracker$View.replace(DataTracker.java:617)
 at org.apache.cassandra.db.DataTracker.replace(DataTracker.java:320)
 at

[jira] [Commented] (CASSANDRA-4340) Cassandra upgrade to 1.1.1 resulted in slow query issue

2012-06-28 Thread Ivan Ganza (JIRA)


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

Ivan Ganza commented on CASSANDRA-4340:
---

I was trying to duplicate our problem by fetching the same quote rapidly in 
succession and got the following error and stock trace. Could you add it to our 
Jira ticket? I will keep looking at this. Row caching was turned off.

java.lang.OutOfMemoryError: Java heap space
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.init(CompressedRandomAccessReader.java:66)
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:46)
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:41)
at 
org.apache.cassandra.io.util.CompressedSegmentedFile.getSegment(CompressedSegmentedFile.java:63)
at 
org.apache.cassandra.io.sstable.SSTableReader.getFileDataInput(SSTableReader.java:871)
at 
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:48)
at 
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:66)
at 
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:78)
at 
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at 
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:63)
at 
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1321)
at 
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1183)
at 
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1118)
at org.apache.cassandra.db.Table.getRow(Table.java:374)
at 
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at 
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:816)
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1250)
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)


 Cassandra upgrade to 1.1.1 resulted in slow query issue
 ---

 Key: CASSANDRA-4340
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4340
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
 Environment: Ubuntu Linux, Java 7, Hector 1.0-1
Reporter: Ivan Ganza
Assignee: Pavel Yaskevich
 Fix For: 1.1.2

 Attachments: CassandraIssue.java


 We have recently introduced Cassandra at the Globe and Mail here in Toronto, 
 Canada.  We are processing and storing the North American stock-market feed.  
 We have found it to work very quickly and things have been looking very good.
 Recently we upgraded to version 1.1.1 and then we have noticed some issues 
 occurring.
 I will try to describe it for you here.  Basically one operation that we very 
 often perform and is very critical is the ability to 'get the latest quote'.  
 This would return to you the latest Quote adjusted against exchange delay 
 rules.  With Cassandra version 1.0.3 we could get a Quote in around 2ms.  
 After update we are looking at time of at least 2-3 seconds.
 The way we query the quote is using a REVERSED SuperSliceQuery  with 
 start=now, end=00:00:00.000 (beginning of day) LIMITED to 1.
 Our investigation leads us to suspect that, since upgrade, Cassandra seems to 
 be reading the sstable from disk even when we request a small range of day 
 only 5 seconds back.  If you look at the output below you can see that the 
 query does NOT get slower as the lookback increases from 5  sec, 60 sec, 15 
 min, 60 min, and 24 hours.
 We also noticed that the query was very fast for the first five minutes of 
 trading, apparently until the first sstable was flushed to disk.  After that 
 we go into query times of 1-2 seconds or so.
 Query time[lookback=5]:[1711ms]
 Query time[lookback=60]:[1592ms]
 Query time[lookback=900]:[1520ms]
 Query time[lookback=3600]:[1294ms]
 Query time[lookback=86400]:[1391ms]
 We would really appreciate input or help on this.
 Cassandra version: 1.1.1
 Hector version: 1.0-1
 ---
 public void testCassandraIssue() {
 try {
   int[] seconds = new int[]{ 5, 60, 60 * 15, 60 * 60, 60 * 60 
 * 24};
   for(int sec : seconds) {
 DateTime start = new DateTime();

[jira] [Updated] (CASSANDRA-4321) stackoverflow building interval tree possible sstable corruptions


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

Sylvain Lebresne updated CASSANDRA-4321:


Attachment: (was: 0004-Add-manifest-integrity-check-v6.txt)

 stackoverflow building interval tree  possible sstable corruptions
 ---

 Key: CASSANDRA-4321
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4321
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
Reporter: Anton Winter
Assignee: Sylvain Lebresne
 Fix For: 1.1.2

 Attachments: ooyala-hastur-stacktrace.txt


 After upgrading to 1.1.1 (from 1.1.0) I have started experiencing 
 StackOverflowError's resulting in compaction backlog and failure to restart. 
 The ring currently consists of 6 DC's and 22 nodes using LCS  compression.  
 This issue was first noted on 2 nodes in one DC and then appears to have 
 spread to various other nodes in the other DC's.  
 When the first occurrence of this was found I restarted the instance but it 
 failed to start so I cleared its data and treated it as a replacement node 
 for the token it was previously responsible for.  This node successfully 
 streamed all the relevant data back but failed again a number of hours later 
 with the same StackOverflowError and again was unable to restart. 
 The initial stack overflow error on a running instance looks like this:
 ERROR [CompactionExecutor:314] 2012-06-07 09:59:43,017 
 AbstractCassandraDaemon.java (line 134) Exception in thread 
 Thread[CompactionExecutor:314,1,main]
 java.lang.StackOverflowError
 at java.util.Arrays.mergeSort(Arrays.java:1157)
 at java.util.Arrays.sort(Arrays.java:1092)
 at java.util.Collections.sort(Collections.java:134)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.findMinMedianMax(IntervalNode.java:114)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:49)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 [snip - this repeats until stack overflow.  Compactions stop from this point 
 onwards]
 I restarted this failing instance with DEBUG logging enabled and it throws 
 the following exception part way through startup:
 ERROR 11:37:51,046 Exception in thread Thread[OptionalTasks:1,5,main]
 java.lang.StackOverflowError
 at 
 org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:307)
 at 
 org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:276)
 at 
 org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:230)
 at 
 org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124)
 at 
 org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:228)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:45)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 [snip - this repeats until stack overflow]
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalTree.init(IntervalTree.java:39)
 at 
 org.apache.cassandra.db.DataTracker.buildIntervalTree(DataTracker.java:560)
 at 
 org.apache.cassandra.db.DataTracker$View.replace(DataTracker.java:617)
 at org.apache.cassandra.db.DataTracker.replace(DataTracker.java:320)
 at

[jira] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal


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

Luís Ferreira commented on CASSANDRA-2231:
--

Thanks for the quick reply.

I'm using a sun jvm and have used it a lot with cassandra without any problem. 
Actually, if I create CF that use the BytesType comparator only, it works. It 
just stops working when creating this particular CF.

I've using the binaries in the build directory after doing an ant release. Not 
sure if it is the correct way to compile everything.

I've also added 
https://github.com/edanuff/CassandraCompositeType/blob/master/src/main/java/comparators/Composite.java
 to org.apache.cassandra.db since I couldn't understand how to create an actual 
row key just with this patch. I don't think that has anything to do with the 
problem though, does it?

 Add CompositeType comparer to the comparers provided in 
 org.apache.cassandra.db.marshal
 ---

 Key: CASSANDRA-2231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
 Project: Cassandra
  Issue Type: New Feature
  Components: Contrib
Reporter: Ed Anuff
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 0.8.1

 Attachments: 
 0001-Add-compositeType-and-DynamicCompositeType-v2.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v3.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v4.patch, 
 0001-Add-compositeType-and-DynamicCompositeType_0.7.patch, 
 CompositeType-and-DynamicCompositeType.patch, 
 edanuff-CassandraCompositeType-1e253c4.zip


 CompositeType is a custom comparer that makes it possible to create 
 comparable composite values out of the basic types that Cassandra currently 
 supports, such as Long, UUID, etc.  This is very useful in both the creation 
 of custom inverted indexes using columns in a skinny row, where each column 
 name is a composite value, and also when using Cassandra's built-in secondary 
 index support, where it can be used to encode the values in the columns that 
 Cassandra indexes.  One scenario for the usage of these is documented here: 
 http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
 contribution is attached and has been previously maintained on github here: 
 https://github.com/edanuff/CassandraCompositeType

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4321) stackoverflow building interval tree possible sstable corruptions


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

Sylvain Lebresne updated CASSANDRA-4321:


Attachment: 0004-Add-manifest-integrity-check-v7.txt
0003-Create-standalone-scrub-v7.txt
0002-Scrub-detects-and-repair-outOfOrder-rows-v7.txt
0001-Fix-overlapping-computation-v7.txt

Alright, so I'm pretty sure I've found the root cause of all this. On top of 
the Range-Bound problem we were not correctly computing the set of overlapping 
sstable in L1 when compacting multiple L0 files. Citing the comment of the 
attached fix (where sstables = 'sstables in L0 to compact' and candidates = 
'sstable in L1'):
{noformat}
/*
 * Note that picking each sstable from candidates that overlap one of the 
sstable of sstables is not enough
 * because you could have the following situation:
 *   sstables = [ s1(a, c), s2(m, z) ]
 *   candidates = [ s3(e, g) ]
 * In that case, s2 overlaps none of s1 or s2, but if we compact s1 with s2, 
the resulting sstable will be
 * overlapping s3, so we must return s3.
 */
{noformat}

So I'm attaching a v7 of the patches with the fix for that in the first patch. 
The last patch (the integrity tests) was also breaking the offline scrub so 
that's fix in v7 too. Though I note that the integrity tests of the last patch 
is probably overkill and I didn't really intended to commit it (i.e. the 
integrity check that is in trunk is probably enough).

 stackoverflow building interval tree  possible sstable corruptions
 ---

 Key: CASSANDRA-4321
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4321
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
Reporter: Anton Winter
Assignee: Sylvain Lebresne
 Fix For: 1.1.2

 Attachments: 0001-Fix-overlapping-computation-v7.txt, 
 0002-Scrub-detects-and-repair-outOfOrder-rows-v7.txt, 
 0003-Create-standalone-scrub-v7.txt, 
 0004-Add-manifest-integrity-check-v7.txt, ooyala-hastur-stacktrace.txt


 After upgrading to 1.1.1 (from 1.1.0) I have started experiencing 
 StackOverflowError's resulting in compaction backlog and failure to restart. 
 The ring currently consists of 6 DC's and 22 nodes using LCS  compression.  
 This issue was first noted on 2 nodes in one DC and then appears to have 
 spread to various other nodes in the other DC's.  
 When the first occurrence of this was found I restarted the instance but it 
 failed to start so I cleared its data and treated it as a replacement node 
 for the token it was previously responsible for.  This node successfully 
 streamed all the relevant data back but failed again a number of hours later 
 with the same StackOverflowError and again was unable to restart. 
 The initial stack overflow error on a running instance looks like this:
 ERROR [CompactionExecutor:314] 2012-06-07 09:59:43,017 
 AbstractCassandraDaemon.java (line 134) Exception in thread 
 Thread[CompactionExecutor:314,1,main]
 java.lang.StackOverflowError
 at java.util.Arrays.mergeSort(Arrays.java:1157)
 at java.util.Arrays.sort(Arrays.java:1092)
 at java.util.Collections.sort(Collections.java:134)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.findMinMedianMax(IntervalNode.java:114)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:49)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 [snip - this repeats until stack overflow.  Compactions stop from this point 
 onwards]
 I restarted this failing instance with DEBUG logging enabled and it throws 
 the following exception part way through startup:
 ERROR 11:37:51,046 Exception in thread Thread[OptionalTasks:1,5,main]
 java.lang.StackOverflowError
 at 
 org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:307)
 at 
 org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:276)
 at 
 org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:230)
 at 
 org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124)
 at 
 org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:228)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:45)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 [snip - this repeats until stack

[jira] [Updated] (CASSANDRA-4357) Add Commitlog Versioning

2012-06-28 Thread Vijay (JIRA)


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

Vijay updated CASSANDRA-4357:
-

Attachment: 0002-Add-CommitLog-versioning-v2.patch
0001-Allow-Commit-log-to-skip-unknownCF-v2.patch

{quote}
Wouldn't it be simpler to use a single pattern with an optional group for the 
new version, than two patterns?
{quote}
Thought that was more readable, but fixed :)

{quote}
logic in getMessagingVersion could lead to errors if MS version bumps but 
someone forgets to bump CLD
{quote}
added assertion so the test cases fail hope this looks ok.

Done, Thanks!

 Add Commitlog Versioning
 

 Key: CASSANDRA-4357
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4357
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2
Reporter: Vijay
Assignee: Vijay
Priority: Minor
 Fix For: 1.2

 Attachments: 0001-Allow-Commit-log-to-skip-unknownCF-v2.patch, 
 0001-Allow-Commit-log-to-skip-unknownCF.patch, 0001-CASSANDRA-4357.patch, 
 0002-Add-CommitLog-versioning-v2.patch, 0002-Add-CommitLog-versioning.patch


 Currently when there are changes in protocol version in RowMutation it is not 
 handled in the Commit Logs.
 CASSANDRA-4139 adds changes which exposes this.
 It would be nice to reuse MessagingService.currentVersion to be the Commit 
 Log version (encoded in the name) instead of creating a separate one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4391) add CF level 'count based ttl' option

2012-06-28 Thread Dave Brosius (JIRA)

Dave Brosius created CASSANDRA-4391:
---

 Summary: add CF level 'count based ttl' option
 Key: CASSANDRA-4391
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4391
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2
Reporter: Dave Brosius
Priority: Minor
 Fix For: 1.2


It would be useful to have a column family level based ttl for columns based on 
column count. This would be both lazy and sloppy, in that the only guarantee 
you received was that the latest n columns would not be deleted. 

When a compaction occurs, only up to n of the latest columns would be added to 
the new sstable for any particular key.

So it is possible that old columns are removed out of order, but again, you can 
be sure that the latest n columns are preserved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal


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

Sylvain Lebresne commented on CASSANDRA-2231:
-

bq. I don't think that has anything to do with the problem though, does it?

Well, actually that might, the class you linked is not related to this patch 
(and is not compatible with it as far as I can tell).

 Add CompositeType comparer to the comparers provided in 
 org.apache.cassandra.db.marshal
 ---

 Key: CASSANDRA-2231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
 Project: Cassandra
  Issue Type: New Feature
  Components: Contrib
Reporter: Ed Anuff
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 0.8.1

 Attachments: 
 0001-Add-compositeType-and-DynamicCompositeType-v2.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v3.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v4.patch, 
 0001-Add-compositeType-and-DynamicCompositeType_0.7.patch, 
 CompositeType-and-DynamicCompositeType.patch, 
 edanuff-CassandraCompositeType-1e253c4.zip


 CompositeType is a custom comparer that makes it possible to create 
 comparable composite values out of the basic types that Cassandra currently 
 supports, such as Long, UUID, etc.  This is very useful in both the creation 
 of custom inverted indexes using columns in a skinny row, where each column 
 name is a composite value, and also when using Cassandra's built-in secondary 
 index support, where it can be used to encode the values in the columns that 
 Cassandra indexes.  One scenario for the usage of these is documented here: 
 http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
 contribution is attached and has been previously maintained on github here: 
 https://github.com/edanuff/CassandraCompositeType

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4384) HintedHandoff can begin before SS knows the hostID

2012-06-28 Thread Brandon Williams (JIRA)


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

Brandon Williams commented on CASSANDRA-4384:
-

I'm inclined to agree with Sam, since this is how the problem is solved with 
tokens.

 HintedHandoff can begin before SS knows the hostID
 --

 Key: CASSANDRA-4384
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4384
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2
Reporter: Brandon Williams
Assignee: Brandon Williams
 Fix For: 1.2


 Since HH fires from the FD, SS won't quite have the hostId yet:
 {noformat}
  INFO 18:58:04,196 Started hinted handoff for host: null with IP: 
 /10.179.65.102
  INFO 18:58:04,197 Node /10.179.65.102 state jump to normal
 ERROR 18:58:04,197 Exception in thread Thread[HintedHandoff:1,1,main]
 java.lang.NullPointerException
 at org.apache.cassandra.utils.UUIDGen.decompose(UUIDGen.java:120)
 at 
 org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpointInternal(HintedHandOffManager.java:304)
 at 
 org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:250)
 at 
 org.apache.cassandra.db.HintedHandOffManager.access$400(HintedHandOffManager.java:87)
 at 
 org.apache.cassandra.db.HintedHandOffManager$4.runMayThrow(HintedHandOffManager.java:433)
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:26)
 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)
 {noformat}
 Simple solution seems to be getting the hostId from gossip instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CASSANDRA-4391) add CF level 'count based ttl' option


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

Jonathan Ellis resolved CASSANDRA-4391.
---

   Resolution: Duplicate
Fix Version/s: (was: 1.2)

dupes CASSANDRA-3929

 add CF level 'count based ttl' option
 -

 Key: CASSANDRA-4391
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4391
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2
Reporter: Dave Brosius
Priority: Minor

 It would be useful to have a column family level based ttl for columns based 
 on column count. This would be both lazy and sloppy, in that the only 
 guarantee you received was that the latest n columns would not be deleted. 
 When a compaction occurs, only up to n of the latest columns would be added 
 to the new sstable for any particular key.
 So it is possible that old columns are removed out of order, but again, you 
 can be sure that the latest n columns are preserved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4384) HintedHandoff can begin before SS knows the hostID


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

Sylvain Lebresne commented on CASSANDRA-4384:
-

CASSANDRA-4351 is relevant (or in other words, I agree too since we wanted to 
persist them anyway for that issue).

 HintedHandoff can begin before SS knows the hostID
 --

 Key: CASSANDRA-4384
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4384
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2
Reporter: Brandon Williams
Assignee: Brandon Williams
 Fix For: 1.2


 Since HH fires from the FD, SS won't quite have the hostId yet:
 {noformat}
  INFO 18:58:04,196 Started hinted handoff for host: null with IP: 
 /10.179.65.102
  INFO 18:58:04,197 Node /10.179.65.102 state jump to normal
 ERROR 18:58:04,197 Exception in thread Thread[HintedHandoff:1,1,main]
 java.lang.NullPointerException
 at org.apache.cassandra.utils.UUIDGen.decompose(UUIDGen.java:120)
 at 
 org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpointInternal(HintedHandOffManager.java:304)
 at 
 org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:250)
 at 
 org.apache.cassandra.db.HintedHandOffManager.access$400(HintedHandOffManager.java:87)
 at 
 org.apache.cassandra.db.HintedHandOffManager$4.runMayThrow(HintedHandOffManager.java:433)
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:26)
 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)
 {noformat}
 Simple solution seems to be getting the hostId from gossip instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal


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

Luís Ferreira commented on CASSANDRA-2231:
--

Thanks, I'll give it try without including that class then.

But how do I create a composite key using just this patch then?

Sorry for asking all these questions here, but I couldn't find any tutorial or 
info on this.

 Add CompositeType comparer to the comparers provided in 
 org.apache.cassandra.db.marshal
 ---

 Key: CASSANDRA-2231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
 Project: Cassandra
  Issue Type: New Feature
  Components: Contrib
Reporter: Ed Anuff
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 0.8.1

 Attachments: 
 0001-Add-compositeType-and-DynamicCompositeType-v2.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v3.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v4.patch, 
 0001-Add-compositeType-and-DynamicCompositeType_0.7.patch, 
 CompositeType-and-DynamicCompositeType.patch, 
 edanuff-CassandraCompositeType-1e253c4.zip


 CompositeType is a custom comparer that makes it possible to create 
 comparable composite values out of the basic types that Cassandra currently 
 supports, such as Long, UUID, etc.  This is very useful in both the creation 
 of custom inverted indexes using columns in a skinny row, where each column 
 name is a composite value, and also when using Cassandra's built-in secondary 
 index support, where it can be used to encode the values in the columns that 
 Cassandra indexes.  One scenario for the usage of these is documented here: 
 http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
 contribution is attached and has been previously maintained on github here: 
 https://github.com/edanuff/CassandraCompositeType

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal


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

Sylvain Lebresne commented on CASSANDRA-2231:
-

http://www.datastax.com/dev/blog/introduction-to-composite-columns-part-1 might 
be a good start

 Add CompositeType comparer to the comparers provided in 
 org.apache.cassandra.db.marshal
 ---

 Key: CASSANDRA-2231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
 Project: Cassandra
  Issue Type: New Feature
  Components: Contrib
Reporter: Ed Anuff
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 0.8.1

 Attachments: 
 0001-Add-compositeType-and-DynamicCompositeType-v2.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v3.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v4.patch, 
 0001-Add-compositeType-and-DynamicCompositeType_0.7.patch, 
 CompositeType-and-DynamicCompositeType.patch, 
 edanuff-CassandraCompositeType-1e253c4.zip


 CompositeType is a custom comparer that makes it possible to create 
 comparable composite values out of the basic types that Cassandra currently 
 supports, such as Long, UUID, etc.  This is very useful in both the creation 
 of custom inverted indexes using columns in a skinny row, where each column 
 name is a composite value, and also when using Cassandra's built-in secondary 
 index support, where it can be used to encode the values in the columns that 
 Cassandra indexes.  One scenario for the usage of these is documented here: 
 http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
 contribution is attached and has been previously maintained on github here: 
 https://github.com/edanuff/CassandraCompositeType

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4392) Create a tool that will convert a commit log into a series of readable CQL statements

Jeremy Hanna created CASSANDRA-4392:
---

 Summary: Create a tool that will convert a commit log into a 
series of readable CQL statements
 Key: CASSANDRA-4392
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4392
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Jeremy Hanna


To enable a case of point in time recovery not currently handled by cassandra, 
it would be great to have a way to convert a commit log into a series of 
readable CQL statements.

Currently one is able to do recovery up to current sstables, or with 
CASSANDRA-3690, additionally apply the current commit logs in their entirety.  
The one missing case is to say that I want to recover to a point in time before 
I did stupid/damaging operation X.  That needs visibility into the commit logs.

I thought the simplest way to do this would be to have a tool that converts 
commit logs into readable CQL statements so they could be selectively applied.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal


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

Luís Ferreira commented on CASSANDRA-2231:
--

Thanks, but this tutorial uses a Composite class that I can't find in the 
patch. That was the thing I couldn't understand.

{code}
Composite start = compositeFrom(startArg, Composite.ComponentEquality.EQUAL);
Composite end = compositeFrom(startArg, 
Composite.ComponentEquality.GREATER_THAN_EQUAL);
start.addComponent(1,CA,Composite.ComponentEquality.EQUAL);
end.addComponent(1,CA,Composite.ComponentEquality.GREATER_THAN_EQUAL);
{code}

 Add CompositeType comparer to the comparers provided in 
 org.apache.cassandra.db.marshal
 ---

 Key: CASSANDRA-2231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
 Project: Cassandra
  Issue Type: New Feature
  Components: Contrib
Reporter: Ed Anuff
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 0.8.1

 Attachments: 
 0001-Add-compositeType-and-DynamicCompositeType-v2.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v3.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v4.patch, 
 0001-Add-compositeType-and-DynamicCompositeType_0.7.patch, 
 CompositeType-and-DynamicCompositeType.patch, 
 edanuff-CassandraCompositeType-1e253c4.zip


 CompositeType is a custom comparer that makes it possible to create 
 comparable composite values out of the basic types that Cassandra currently 
 supports, such as Long, UUID, etc.  This is very useful in both the creation 
 of custom inverted indexes using columns in a skinny row, where each column 
 name is a composite value, and also when using Cassandra's built-in secondary 
 index support, where it can be used to encode the values in the columns that 
 Cassandra indexes.  One scenario for the usage of these is documented here: 
 http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
 contribution is attached and has been previously maintained on github here: 
 https://github.com/edanuff/CassandraCompositeType

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4392) Create a tool that will convert a commit log into a series of readable CQL statements

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

Jeremy Hanna commented on CASSANDRA-4392:
-

Since this is going to apply to several nodes, it might be nice to have a way
to aggregate the CQL statements as well and then apply them in bulk at the
cluster again.

It would seem that some information is lost after it gets to the commitlog,
however. So the consistency level that something is written at is probably not
available. The CQL statement might do USING ALL so that it errs on the side of
make it apply to everything. Or make that configurable.

Create a tool that will convert a commit log into a series of readable CQL
statements
-

Key: CASSANDRA-4392
URL: https://issues.apache.org/jira/browse/CASSANDRA-4392
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Jeremy Hanna

To enable a case of point in time recovery not currently handled by
cassandra, it would be great to have a way to convert a commit log into a
series of readable CQL statements.
Currently one is able to do recovery up to current sstables, or with
CASSANDRA-3690, additionally apply the current commit logs in their entirety.
The one missing case is to say that I want to recover to a point in time
before I did stupid/damaging operation X. That needs visibility into the
commit logs.
I thought the simplest way to do this would be to have a tool that converts
commit logs into readable CQL statements so they could be selectively applied.

[jira] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal


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

Jonathan Ellis commented on CASSANDRA-2231:
---

This is a sign that you should use an official release supporting composites 
instead of trying to hack it into 0.7.9... Composite types have evolved over 
many tickets and patchsets, this was just the first.

 Add CompositeType comparer to the comparers provided in 
 org.apache.cassandra.db.marshal
 ---

 Key: CASSANDRA-2231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
 Project: Cassandra
  Issue Type: New Feature
  Components: Contrib
Reporter: Ed Anuff
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 0.8.1

 Attachments: 
 0001-Add-compositeType-and-DynamicCompositeType-v2.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v3.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v4.patch, 
 0001-Add-compositeType-and-DynamicCompositeType_0.7.patch, 
 CompositeType-and-DynamicCompositeType.patch, 
 edanuff-CassandraCompositeType-1e253c4.zip


 CompositeType is a custom comparer that makes it possible to create 
 comparable composite values out of the basic types that Cassandra currently 
 supports, such as Long, UUID, etc.  This is very useful in both the creation 
 of custom inverted indexes using columns in a skinny row, where each column 
 name is a composite value, and also when using Cassandra's built-in secondary 
 index support, where it can be used to encode the values in the columns that 
 Cassandra indexes.  One scenario for the usage of these is documented here: 
 http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
 contribution is attached and has been previously maintained on github here: 
 https://github.com/edanuff/CassandraCompositeType

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CASSANDRA-4392) Create a tool that will convert a commit log into a series of readable CQL statements


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

Jonathan Ellis resolved CASSANDRA-4392.
---

Resolution: Duplicate

see restore_point_in_time from conf/commitlog_archiving.properties

 Create a tool that will convert a commit log into a series of readable CQL 
 statements
 -

 Key: CASSANDRA-4392
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4392
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Jeremy Hanna

 To enable a case of point in time recovery not currently handled by 
 cassandra, it would be great to have a way to convert a commit log into a 
 series of readable CQL statements.
 Currently one is able to do recovery up to current sstables, or with 
 CASSANDRA-3690, additionally apply the current commit logs in their entirety. 
  The one missing case is to say that I want to recover to a point in time 
 before I did stupid/damaging operation X.  That needs visibility into the 
 commit logs.
 I thought the simplest way to do this would be to have a tool that converts 
 commit logs into readable CQL statements so they could be selectively applied.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4392) Create a tool that will convert a commit log into a series of readable CQL statements

2012-06-28 Thread Vijay (JIRA)


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

Vijay commented on CASSANDRA-4392:
--

Hi Jonathan, I think the request was to skip a particular statement while 
restoring from backup
Example: restore but skip all: delete * from CF where ...

 Create a tool that will convert a commit log into a series of readable CQL 
 statements
 -

 Key: CASSANDRA-4392
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4392
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Jeremy Hanna

 To enable a case of point in time recovery not currently handled by 
 cassandra, it would be great to have a way to convert a commit log into a 
 series of readable CQL statements.
 Currently one is able to do recovery up to current sstables, or with 
 CASSANDRA-3690, additionally apply the current commit logs in their entirety. 
  The one missing case is to say that I want to recover to a point in time 
 before I did stupid/damaging operation X.  That needs visibility into the 
 commit logs.
 I thought the simplest way to do this would be to have a tool that converts 
 commit logs into readable CQL statements so they could be selectively applied.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4321) stackoverflow building interval tree possible sstable corruptions


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

Jonathan Ellis updated CASSANDRA-4321:
--

Attachment: cleanup.txt

Nice work, I think you nailed it!

+1 from me, and agreed that I'd rather backport the limited sanity check from 
trunk than use 0004 here.

Also attached a cleanup patch (applies after 0001) to add javadoc, improve 
parameter names, and simplify overlapping by making union explicit when 
desired.

 stackoverflow building interval tree  possible sstable corruptions
 ---

 Key: CASSANDRA-4321
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4321
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
Reporter: Anton Winter
Assignee: Sylvain Lebresne
 Fix For: 1.1.2

 Attachments: 0001-Fix-overlapping-computation-v7.txt, 
 0002-Scrub-detects-and-repair-outOfOrder-rows-v7.txt, 
 0003-Create-standalone-scrub-v7.txt, 
 0004-Add-manifest-integrity-check-v7.txt, cleanup.txt, 
 ooyala-hastur-stacktrace.txt


 After upgrading to 1.1.1 (from 1.1.0) I have started experiencing 
 StackOverflowError's resulting in compaction backlog and failure to restart. 
 The ring currently consists of 6 DC's and 22 nodes using LCS  compression.  
 This issue was first noted on 2 nodes in one DC and then appears to have 
 spread to various other nodes in the other DC's.  
 When the first occurrence of this was found I restarted the instance but it 
 failed to start so I cleared its data and treated it as a replacement node 
 for the token it was previously responsible for.  This node successfully 
 streamed all the relevant data back but failed again a number of hours later 
 with the same StackOverflowError and again was unable to restart. 
 The initial stack overflow error on a running instance looks like this:
 ERROR [CompactionExecutor:314] 2012-06-07 09:59:43,017 
 AbstractCassandraDaemon.java (line 134) Exception in thread 
 Thread[CompactionExecutor:314,1,main]
 java.lang.StackOverflowError
 at java.util.Arrays.mergeSort(Arrays.java:1157)
 at java.util.Arrays.sort(Arrays.java:1092)
 at java.util.Collections.sort(Collections.java:134)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.findMinMedianMax(IntervalNode.java:114)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:49)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 [snip - this repeats until stack overflow.  Compactions stop from this point 
 onwards]
 I restarted this failing instance with DEBUG logging enabled and it throws 
 the following exception part way through startup:
 ERROR 11:37:51,046 Exception in thread Thread[OptionalTasks:1,5,main]
 java.lang.StackOverflowError
 at 
 org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:307)
 at 
 org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:276)
 at 
 org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:230)
 at 
 org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124)
 at 
 org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:228)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:45)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 [snip - this repeats until stack overflow]
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at 
 org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
 at

[jira] [Updated] (CASSANDRA-3047) implementations of IPartitioner.describeOwnership() are not DC aware


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

David Alves updated CASSANDRA-3047:
---

Attachment: 3047.patch

corrected some bugs in NodeCmd output.

 implementations of IPartitioner.describeOwnership() are not DC aware
 

 Key: CASSANDRA-3047
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3047
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Aaron Morton
Assignee: David Alves
Priority: Trivial
 Fix For: 1.1.2

 Attachments: 3047.patch, 3047.patch, CASSANDRA-3047.patch, 
 CASSANDRA-3047.patch, CASSANDRA-3047.patch, CASSANDRA-3047.patch


 see http://www.mail-archive.com/user@cassandra.apache.org/msg16375.html
 When a cluster the multiple rings approach to tokens the output from nodetool 
 ring is incorrect.
 When it uses the interleaved token approach (e.g. dc1, dc2, dc1, dc2) it will 
 be correct. 
 It's a bit hacky but could we special case (RP) tokens that are off by 1 and 
 calculate the ownership per dc ? I guess another approach would be to add 
 some parameters so the partitioner can be told about the token assignment 
 strategy.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4393) Reduce default BF size

Jonathan Ellis created CASSANDRA-4393:
-

 Summary: Reduce default BF size
 Key: CASSANDRA-4393
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4393
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 1.2


With improvements like leveled compaction and CASSANDRA-2503 it's no longer 
worth throwing quite so much memory at BF to avoid false positives.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4303) Compressed bloomfilters


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

Jonathan Ellis commented on CASSANDRA-4303:
---

bq. Would simply reducing the FP default be a Good Enough solution?

Created CASSANDRA-4393 to do this in the meantime.

 Compressed bloomfilters
 ---

 Key: CASSANDRA-4303
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4303
 Project: Cassandra
  Issue Type: Improvement
Reporter: Brandon Williams
 Fix For: 1.2


 Very commonly, people encountering an OOM need to increase their bloom filter 
 false positive ratio to reduce memory pressure, since BFs tend to be the 
 largest shareholder.  It would make sense if we could alleviate the memory 
 pressure from BFs with compression while maintaining the FP ratio (at the 
 cost of a bit of cpu) that some users have come to expect.  One possible 
 implementation is at http://code.google.com/p/javaewah/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (CASSANDRA-4392) Create a tool that will convert a commit log into a series of readable CQL statements


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

Jeremy Hanna reopened CASSANDRA-4392:
-


I didn't know about that particular property but like Vijay said, it doesn't 
completely cover what this would provide - the ability to not only limit the 
time, but also selectively skip mutations.

 Create a tool that will convert a commit log into a series of readable CQL 
 statements
 -

 Key: CASSANDRA-4392
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4392
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Jeremy Hanna

 To enable a case of point in time recovery not currently handled by 
 cassandra, it would be great to have a way to convert a commit log into a 
 series of readable CQL statements.
 Currently one is able to do recovery up to current sstables, or with 
 CASSANDRA-3690, additionally apply the current commit logs in their entirety. 
  The one missing case is to say that I want to recover to a point in time 
 before I did stupid/damaging operation X.  That needs visibility into the 
 commit logs.
 I thought the simplest way to do this would be to have a tool that converts 
 commit logs into readable CQL statements so they could be selectively applied.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal


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

Luís Ferreira commented on CASSANDRA-2231:
--

I've compiled it with just this patch now and I get:

{code}
Unable to find abstract-type class 
'org.apache.cassandra.db.marshal.CompositeType(BytesType,BytesType)'
{code}

I check the jar and it is there, I'm using the binaries that I got from doing 
ant release, am I doing this right?

 Add CompositeType comparer to the comparers provided in 
 org.apache.cassandra.db.marshal
 ---

 Key: CASSANDRA-2231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
 Project: Cassandra
  Issue Type: New Feature
  Components: Contrib
Reporter: Ed Anuff
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 0.8.1

 Attachments: 
 0001-Add-compositeType-and-DynamicCompositeType-v2.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v3.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v4.patch, 
 0001-Add-compositeType-and-DynamicCompositeType_0.7.patch, 
 CompositeType-and-DynamicCompositeType.patch, 
 edanuff-CassandraCompositeType-1e253c4.zip


 CompositeType is a custom comparer that makes it possible to create 
 comparable composite values out of the basic types that Cassandra currently 
 supports, such as Long, UUID, etc.  This is very useful in both the creation 
 of custom inverted indexes using columns in a skinny row, where each column 
 name is a composite value, and also when using Cassandra's built-in secondary 
 index support, where it can be used to encode the values in the columns that 
 Cassandra indexes.  One scenario for the usage of these is documented here: 
 http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
 contribution is attached and has been previously maintained on github here: 
 https://github.com/edanuff/CassandraCompositeType

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4340) Cassandra upgrade to 1.1.1 resulted in slow query issue


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

Pavel Yaskevich commented on CASSANDRA-4340:


This rings the bell that you need to add more capacity to your ring as you are 
overloading this one with the data (or the rows are too big), did the load on 
the ring change as well after upgrade?

 Cassandra upgrade to 1.1.1 resulted in slow query issue
 ---

 Key: CASSANDRA-4340
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4340
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
 Environment: Ubuntu Linux, Java 7, Hector 1.0-1
Reporter: Ivan Ganza
Assignee: Pavel Yaskevich
 Fix For: 1.1.2

 Attachments: CassandraIssue.java


 We have recently introduced Cassandra at the Globe and Mail here in Toronto, 
 Canada.  We are processing and storing the North American stock-market feed.  
 We have found it to work very quickly and things have been looking very good.
 Recently we upgraded to version 1.1.1 and then we have noticed some issues 
 occurring.
 I will try to describe it for you here.  Basically one operation that we very 
 often perform and is very critical is the ability to 'get the latest quote'.  
 This would return to you the latest Quote adjusted against exchange delay 
 rules.  With Cassandra version 1.0.3 we could get a Quote in around 2ms.  
 After update we are looking at time of at least 2-3 seconds.
 The way we query the quote is using a REVERSED SuperSliceQuery  with 
 start=now, end=00:00:00.000 (beginning of day) LIMITED to 1.
 Our investigation leads us to suspect that, since upgrade, Cassandra seems to 
 be reading the sstable from disk even when we request a small range of day 
 only 5 seconds back.  If you look at the output below you can see that the 
 query does NOT get slower as the lookback increases from 5  sec, 60 sec, 15 
 min, 60 min, and 24 hours.
 We also noticed that the query was very fast for the first five minutes of 
 trading, apparently until the first sstable was flushed to disk.  After that 
 we go into query times of 1-2 seconds or so.
 Query time[lookback=5]:[1711ms]
 Query time[lookback=60]:[1592ms]
 Query time[lookback=900]:[1520ms]
 Query time[lookback=3600]:[1294ms]
 Query time[lookback=86400]:[1391ms]
 We would really appreciate input or help on this.
 Cassandra version: 1.1.1
 Hector version: 1.0-1
 ---
 public void testCassandraIssue() {
 try {
   int[] seconds = new int[]{ 5, 60, 60 * 15, 60 * 60, 60 * 60 
 * 24};
   for(int sec : seconds) {
 DateTime start = new DateTime();
 SuperSliceQueryString, String, String, String 
 superSliceQuery = HFactory.createSuperSliceQuery(keyspaceOperator, 
 StringSerializer.get(), StringSerializer.get(), StringSerializer.get(), 
 StringSerializer.get());
 superSliceQuery.setKey(101390 + . + 
 testFormatter.print(start));
 superSliceQuery.setColumnFamily(Quotes);
 
 superSliceQuery.setRange(superKeyFormatter.print(start),
 
 superKeyFormatter.print(start.minusSeconds(sec)),
 true,
 1);
 long theStart = System.currentTimeMillis();
 QueryResultSuperSliceString, String, String 
 result = superSliceQuery.execute();
 long end = System.currentTimeMillis();
 System.out.println(Query time[lookback= + sec + 
 ]:[ + (end - theStart) + ms]);
   }
 } catch(Exception e) {
   e.printStackTrace();
   fail(e.getMessage());
 }
   }
 ---
 create column family Quotes
 with column_type = Super
 and  comparator = BytesType
 and subcomparator = BytesType
 and keys_cached = 7000
 and rows_cached = 0
 and row_cache_save_period = 0
 and key_cache_save_period = 3600
 and memtable_throughput = 255
 and memtable_operations = 0.29
 AND compression_options={sstable_compression:SnappyCompressor, 
 chunk_length_kb:64};

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4393) Reduce default BF size


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

Jonathan Ellis updated CASSANDRA-4393:
--

Attachment: 4393.txt

attached.

(to avoid messing with pre-upgrade CF definitions, I've moved the default code 
out of CFM.init.  CreateColumnFamilyStatement already checks the default, so 
that just left CassandraServer to update.)

 Reduce default BF size
 --

 Key: CASSANDRA-4393
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4393
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 1.2

 Attachments: 4393.txt


 With improvements like leveled compaction and CASSANDRA-2503 it's no longer 
 worth throwing quite so much memory at BF to avoid false positives.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4357) Add Commitlog Versioning


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

Jonathan Ellis updated CASSANDRA-4357:
--

Attachment: (was: 0002-Add-CommitLog-versioning-v3.patch)

 Add Commitlog Versioning
 

 Key: CASSANDRA-4357
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4357
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2
Reporter: Vijay
Assignee: Vijay
Priority: Minor
 Fix For: 1.2

 Attachments: 0001-Allow-Commit-log-to-skip-unknownCF-v2.patch, 
 0001-Allow-Commit-log-to-skip-unknownCF.patch, 0001-CASSANDRA-4357.patch, 
 0002-Add-CommitLog-versioning-v2.patch, 0002-Add-CommitLog-versioning.patch


 Currently when there are changes in protocol version in RowMutation it is not 
 handled in the Commit Logs.
 CASSANDRA-4139 adds changes which exposes this.
 It would be nice to reuse MessagingService.currentVersion to be the Commit 
 Log version (encoded in the name) instead of creating a separate one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4357) Add Commitlog Versioning


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

Jonathan Ellis updated CASSANDRA-4357:
--

Attachment: 0002-Add-CommitLog-versioning-v3.patch

that still allows someone to try to reply a 1.3 commitlog against a 1.2 cluster 
when downgrading, though.

v3 attached of 0002 to address this.

 Add Commitlog Versioning
 

 Key: CASSANDRA-4357
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4357
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2
Reporter: Vijay
Assignee: Vijay
Priority: Minor
 Fix For: 1.2

 Attachments: 0001-Allow-Commit-log-to-skip-unknownCF-v2.patch, 
 0001-Allow-Commit-log-to-skip-unknownCF.patch, 0001-CASSANDRA-4357.patch, 
 0002-Add-CommitLog-versioning-v2.patch, 0002-Add-CommitLog-versioning.patch


 Currently when there are changes in protocol version in RowMutation it is not 
 handled in the Commit Logs.
 CASSANDRA-4139 adds changes which exposes this.
 It would be nice to reuse MessagingService.currentVersion to be the Commit 
 Log version (encoded in the name) instead of creating a separate one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4357) Add Commitlog Versioning


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

Jonathan Ellis updated CASSANDRA-4357:
--

Attachment: 0002-Add-CommitLog-versioning-v3.patch

 Add Commitlog Versioning
 

 Key: CASSANDRA-4357
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4357
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2
Reporter: Vijay
Assignee: Vijay
Priority: Minor
 Fix For: 1.2

 Attachments: 0001-Allow-Commit-log-to-skip-unknownCF-v2.patch, 
 0001-Allow-Commit-log-to-skip-unknownCF.patch, 0001-CASSANDRA-4357.patch, 
 0002-Add-CommitLog-versioning-v2.patch, 
 0002-Add-CommitLog-versioning-v3.patch, 0002-Add-CommitLog-versioning.patch


 Currently when there are changes in protocol version in RowMutation it is not 
 handled in the Commit Logs.
 CASSANDRA-4139 adds changes which exposes this.
 It would be nice to reuse MessagingService.currentVersion to be the Commit 
 Log version (encoded in the name) instead of creating a separate one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4340) Cassandra upgrade to 1.1.1 resulted in slow query issue


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

Pavel Yaskevich commented on CASSANDRA-4340:


Also can you try to repo this effect on the single separate machine running 
1.1.1 and query some toy dataset or maybe even a single super row?

 Cassandra upgrade to 1.1.1 resulted in slow query issue
 ---

 Key: CASSANDRA-4340
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4340
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.1
 Environment: Ubuntu Linux, Java 7, Hector 1.0-1
Reporter: Ivan Ganza
Assignee: Pavel Yaskevich
 Fix For: 1.1.2

 Attachments: CassandraIssue.java


 We have recently introduced Cassandra at the Globe and Mail here in Toronto, 
 Canada.  We are processing and storing the North American stock-market feed.  
 We have found it to work very quickly and things have been looking very good.
 Recently we upgraded to version 1.1.1 and then we have noticed some issues 
 occurring.
 I will try to describe it for you here.  Basically one operation that we very 
 often perform and is very critical is the ability to 'get the latest quote'.  
 This would return to you the latest Quote adjusted against exchange delay 
 rules.  With Cassandra version 1.0.3 we could get a Quote in around 2ms.  
 After update we are looking at time of at least 2-3 seconds.
 The way we query the quote is using a REVERSED SuperSliceQuery  with 
 start=now, end=00:00:00.000 (beginning of day) LIMITED to 1.
 Our investigation leads us to suspect that, since upgrade, Cassandra seems to 
 be reading the sstable from disk even when we request a small range of day 
 only 5 seconds back.  If you look at the output below you can see that the 
 query does NOT get slower as the lookback increases from 5  sec, 60 sec, 15 
 min, 60 min, and 24 hours.
 We also noticed that the query was very fast for the first five minutes of 
 trading, apparently until the first sstable was flushed to disk.  After that 
 we go into query times of 1-2 seconds or so.
 Query time[lookback=5]:[1711ms]
 Query time[lookback=60]:[1592ms]
 Query time[lookback=900]:[1520ms]
 Query time[lookback=3600]:[1294ms]
 Query time[lookback=86400]:[1391ms]
 We would really appreciate input or help on this.
 Cassandra version: 1.1.1
 Hector version: 1.0-1
 ---
 public void testCassandraIssue() {
 try {
   int[] seconds = new int[]{ 5, 60, 60 * 15, 60 * 60, 60 * 60 
 * 24};
   for(int sec : seconds) {
 DateTime start = new DateTime();
 SuperSliceQueryString, String, String, String 
 superSliceQuery = HFactory.createSuperSliceQuery(keyspaceOperator, 
 StringSerializer.get(), StringSerializer.get(), StringSerializer.get(), 
 StringSerializer.get());
 superSliceQuery.setKey(101390 + . + 
 testFormatter.print(start));
 superSliceQuery.setColumnFamily(Quotes);
 
 superSliceQuery.setRange(superKeyFormatter.print(start),
 
 superKeyFormatter.print(start.minusSeconds(sec)),
 true,
 1);
 long theStart = System.currentTimeMillis();
 QueryResultSuperSliceString, String, String 
 result = superSliceQuery.execute();
 long end = System.currentTimeMillis();
 System.out.println(Query time[lookback= + sec + 
 ]:[ + (end - theStart) + ms]);
   }
 } catch(Exception e) {
   e.printStackTrace();
   fail(e.getMessage());
 }
   }
 ---
 create column family Quotes
 with column_type = Super
 and  comparator = BytesType
 and subcomparator = BytesType
 and keys_cached = 7000
 and rows_cached = 0
 and row_cache_save_period = 0
 and key_cache_save_period = 3600
 and memtable_throughput = 255
 and memtable_operations = 0.29
 AND compression_options={sstable_compression:SnappyCompressor, 
 chunk_length_kb:64};

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4357) Add Commitlog Versioning


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

Jonathan Ellis updated CASSANDRA-4357:
--

Attachment: (was: 0002-Add-CommitLog-versioning-v3.patch)

 Add Commitlog Versioning
 

 Key: CASSANDRA-4357
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4357
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2
Reporter: Vijay
Assignee: Vijay
Priority: Minor
 Fix For: 1.2

 Attachments: 0001-Allow-Commit-log-to-skip-unknownCF-v2.patch, 
 0001-Allow-Commit-log-to-skip-unknownCF.patch, 0001-CASSANDRA-4357.patch, 
 0002-Add-CommitLog-versioning-v2.patch, 
 0002-Add-CommitLog-versioning-v3.patch, 0002-Add-CommitLog-versioning.patch


 Currently when there are changes in protocol version in RowMutation it is not 
 handled in the Commit Logs.
 CASSANDRA-4139 adds changes which exposes this.
 It would be nice to reuse MessagingService.currentVersion to be the Commit 
 Log version (encoded in the name) instead of creating a separate one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4357) Add Commitlog Versioning


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

Jonathan Ellis updated CASSANDRA-4357:
--

Attachment: 0002-Add-CommitLog-versioning-v3.patch

v3 attached that actually includes CLD.java

 Add Commitlog Versioning
 

 Key: CASSANDRA-4357
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4357
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2
Reporter: Vijay
Assignee: Vijay
Priority: Minor
 Fix For: 1.2

 Attachments: 0001-Allow-Commit-log-to-skip-unknownCF-v2.patch, 
 0001-Allow-Commit-log-to-skip-unknownCF.patch, 0001-CASSANDRA-4357.patch, 
 0002-Add-CommitLog-versioning-v2.patch, 
 0002-Add-CommitLog-versioning-v3.patch, 0002-Add-CommitLog-versioning.patch


 Currently when there are changes in protocol version in RowMutation it is not 
 handled in the Commit Logs.
 CASSANDRA-4139 adds changes which exposes this.
 It would be nice to reuse MessagingService.currentVersion to be the Commit 
 Log version (encoded in the name) instead of creating a separate one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4009) Increase usage of Metrics and flesh out o.a.c.metrics

2012-06-28 Thread Yuki Morishita (JIRA)


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

Yuki Morishita updated CASSANDRA-4009:
--

Attachment: 4009.txt

My first attempt attached. Basically, I extracted what it seems like 'Metrics' 
from current MBeans and re-organized them under o.a.c.metrics package. I 
uploaded list of metrics here(still wip, tho): https://gist.github.com/3013075

Patch adds new metric classes, but I still did not completely replace old ones, 
nor mark as deprecated. I will do this if  new metric classes seem OK.

What bothers me right now is that I extracted endpoint states from 
FailureDetector#getAllEndpointStates to EndpointStateMetrics, but I don't think 
we are going to need it.

If anything seems missing/not needed, please let me know.

 Increase usage of Metrics and flesh out o.a.c.metrics
 -

 Key: CASSANDRA-4009
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4009
 Project: Cassandra
  Issue Type: Improvement
Reporter: Brandon Williams
Assignee: Yuki Morishita
Priority: Minor
 Fix For: 1.2

 Attachments: 4009.txt


 With CASSANDRA-3671 we have begun using the Metrics packages to expose stats 
 in a new JMX structure, intended to be more user-friendly (for example, you 
 don't need to know what a StorageProxy is or does.)  This ticket serves as a 
 parent for subtasks to finish fleshing out the rest of the enhanced metrics.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

git commit: lookup hints by ID, not token

2012-06-28 Thread eevans

Updated Branches:
  refs/heads/trunk 0c7833bd3 - 7cb3b7395


lookup hints by ID, not token

Patch by Sam Overton; reviewed by eevans for CASSANDRA-4389


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

Branch: refs/heads/trunk
Commit: 7cb3b73950565a400de45e4c9a87557ddb272074
Parents: 0c7833b
Author: Eric Evans eev...@apache.org
Authored: Thu Jun 28 16:18:47 2012 -0500
Committer: Eric Evans eev...@apache.org
Committed: Thu Jun 28 16:18:47 2012 -0500

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7cb3b739/src/java/org/apache/cassandra/db/HintedHandOffManager.java
--
diff --git a/src/java/org/apache/cassandra/db/HintedHandOffManager.java 
b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
index 9152dd6..e880e43 100644
--- a/src/java/org/apache/cassandra/db/HintedHandOffManager.java
+++ b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
@@ -404,8 +404,8 @@ public class HintedHandOffManager implements 
HintedHandOffManagerMBean
 ListRow rows = hintStore.getRangeSlice(null, range, 
Integer.MAX_VALUE, filter, null);
 for (Row row : rows)
 {
-Token? token = 
StorageService.getPartitioner().getTokenFactory().fromByteArray(row.key.key);
-InetAddress target = 
StorageService.instance.getTokenMetadata().getEndpoint(token);
+UUID hostId = UUIDGen.getUUID(row.key.key);
+InetAddress target = 
StorageService.instance.getTokenMetadata().getEndpointForHostId(hostId);
 // token may have since been removed (in which case we have just 
read back a tombstone)
 if (target != null)
 scheduleHintDelivery(target);

[1/2] git commit: Fix License headers and add assert which was missed.

2012-06-28 Thread vijay

Updated Branches:
  refs/heads/trunk 7cb3b7395 - a4add9573


Fix License headers and add assert which was missed.

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

Branch: refs/heads/trunk
Commit: a4add95732163ffe9b15f49ffd250379872d47e4
Parents: 5799897
Author: Vijay Parthasarathy vijay2...@gmail.com
Authored: Thu Jun 28 14:45:21 2012 -0700
Committer: Vijay Parthasarathy vijay2...@gmail.com
Committed: Thu Jun 28 14:45:21 2012 -0700

--
 .../cassandra/db/commitlog/CommitLogArchiver.java  |2 +-
 .../db/commitlog/CommitLogDescriptor.java  |3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4add957/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
index b8c8dfb..b109db5 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
@@ -1,4 +1,3 @@
-package org.apache.cassandra.db.commitlog;
 /*
  * 
  * Licensed to the Apache Software Foundation (ASF) under one
@@ -19,6 +18,7 @@ package org.apache.cassandra.db.commitlog;
  * under the License.
  * 
  */
+package org.apache.cassandra.db.commitlog;
 
 import java.io.File;
 import java.io.IOException;

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4add957/src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java
--
diff --git 
a/src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java
index 1d67f5c..b31c1e4 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java
@@ -1,4 +1,3 @@
-package org.apache.cassandra.db.commitlog;
 /*
  * 
  * Licensed to the Apache Software Foundation (ASF) under one
@@ -19,6 +18,7 @@ package org.apache.cassandra.db.commitlog;
  * under the License.
  * 
  */
+package org.apache.cassandra.db.commitlog;
 
 import java.util.regex.Matcher;
 import java.util.regex.Pattern;
@@ -75,6 +75,7 @@ public class CommitLogDescriptor
 
 public int getMessagingVersion()
 {
+assert MessagingService.current_version == MessagingService.VERSION_12;
 switch (version)
 {
 case LEGACY_VERSION:

[2/2] git commit: Add Commitlog Versioning patch by Vijay; reviewed by jbellis for CASSANDRA-4357

2012-06-28 Thread vijay

Add Commitlog Versioning
patch by Vijay; reviewed by jbellis for CASSANDRA-4357


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

Branch: refs/heads/trunk
Commit: 57998976f0024776bab6b2301f2436ea60e38fe0
Parents: 7cb3b73
Author: Vijay Parthasarathy vijay2...@gmail.com
Authored: Thu Jun 28 14:35:37 2012 -0700
Committer: Vijay Parthasarathy vijay2...@gmail.com
Committed: Thu Jun 28 14:37:15 2012 -0700

--
 src/java/org/apache/cassandra/config/Schema.java   |6 +-
 .../apache/cassandra/db/commitlog/CommitLog.java   |2 +-
 .../cassandra/db/commitlog/CommitLogAllocator.java |4 +-
 .../cassandra/db/commitlog/CommitLogArchiver.java  |7 +-
 .../db/commitlog/CommitLogDescriptor.java  |  102 +++
 .../cassandra/db/commitlog/CommitLogReplayer.java  |   11 +-
 .../cassandra/db/commitlog/CommitLogSegment.java   |   42 +--
 .../org/apache/cassandra/db/CommitLogTest.java |   24 -
 8 files changed, 144 insertions(+), 54 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/57998976/src/java/org/apache/cassandra/config/Schema.java
--
diff --git a/src/java/org/apache/cassandra/config/Schema.java 
b/src/java/org/apache/cassandra/config/Schema.java
index 7d52d2e..c36ee77 100644
--- a/src/java/org/apache/cassandra/config/Schema.java
+++ b/src/java/org/apache/cassandra/config/Schema.java
@@ -20,7 +20,6 @@ package org.apache.cassandra.config;
 import java.nio.ByteBuffer;
 import java.security.MessageDigest;
 import java.util.*;
-import java.util.concurrent.atomic.AtomicInteger;
 import java.util.concurrent.locks.ReadWriteLock;
 import java.util.concurrent.locks.ReentrantReadWriteLock;
 
@@ -34,6 +33,7 @@ import org.apache.cassandra.db.ColumnFamilyType;
 import org.apache.cassandra.db.Row;
 import org.apache.cassandra.db.SystemTable;
 import org.apache.cassandra.db.Table;
+import org.apache.cassandra.db.UnknownColumnFamilyException;
 import org.apache.cassandra.db.marshal.AbstractType;
 import org.apache.cassandra.io.sstable.Descriptor;
 import org.apache.cassandra.utils.Pair;
@@ -347,12 +347,12 @@ public class Schema
 oldCfIdMap.put(oldId, newId);
 }
 
-public UUID convertOldCfId(Integer oldCfId)
+public UUID convertOldCfId(Integer oldCfId) throws 
UnknownColumnFamilyException
 {
 UUID cfId = oldCfIdMap.get(oldCfId);
 
 if (cfId == null)
-throw new IllegalArgumentException(ColumnFamily identified by old 
 + oldCfId +  was not found.);
+throw new UnknownColumnFamilyException(ColumnFamily identified by 
old  + oldCfId +  was not found., null);
 
 return cfId;
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/57998976/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
index 6649ae4..e339cbc 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
@@ -112,7 +112,7 @@ public class CommitLog implements CommitLogMBean
 // we used to try to avoid instantiating commitlog (thus 
creating an empty segment ready for writes)
 // until after recover was finished.  this turns out to be 
fragile; it is less error-prone to go
 // ahead and allow writes before recover(), and just skip 
active segments when we do.
-return CommitLogSegment.possibleCommitLogFile(name)  
!instance.allocator.manages(name);
+return CommitLogDescriptor.isValid(name)  
!instance.allocator.manages(name);
 }
 });
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/57998976/src/java/org/apache/cassandra/db/commitlog/CommitLogAllocator.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLogAllocator.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLogAllocator.java
index e402a4a..dff4093 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogAllocator.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogAllocator.java
@@ -39,6 +39,7 @@ import org.apache.cassandra.config.Schema;
 import org.apache.cassandra.db.ColumnFamilyStore;
 import org.apache.cassandra.db.Table;
 import org.apache.cassandra.io.util.FileUtils;
+import org.apache.cassandra.net.MessagingService;
 import

[jira] [Commented] (CASSANDRA-3881) reduce computational complexity of processing topology changes


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

Jonathan Ellis commented on CASSANDRA-3881:
---

bq. the places where tokenMetadata needs to be cloned look arbitrary and it's 
much less obvious what the convention is for other people looking at this

What if we just added an assert ({{assert tokenMetadata != 
StorageService.tokenMetadata}}) to enforce this requirement?

Granted that we are choosing lesser evils here, but I like that better than 
trying to reason about synchronized(Topology) mixed with locks mixed with 
synchronized(bootstrapTokens).

 reduce computational complexity of processing topology changes
 --

 Key: CASSANDRA-3881
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3881
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Peter Schuller
Assignee: Sam Overton
  Labels: vnodes

 This constitutes follow-up work from CASSANDRA-3831 where a partial 
 improvement was committed, but the fundamental issue was not fixed. The 
 maximum practical cluster size was significantly improved, but further work 
 is expected to be necessary as cluster sizes grow.
 _Edit0: Appended patch information._
 h3. Patches
 ||Compare||Raw diff||Description||
 |[00_snitch_topology|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology]|[00_snitch_topology.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology.diff]|Adds
  some functionality to TokenMetadata to track which endpoints and racks exist 
 in a DC.|
 |[01_calc_natural_endpoints|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints]|[01_calc_natural_endpoints.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints.diff]|Rewritten
  O(logN) implementation of calculateNaturalEndpoints using the topology 
 information from the tokenMetadata.|
 
 _Note: These are branches managed with TopGit. If you are applying the patch 
 output manually, you will either need to filter the TopGit metadata files 
 (i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}), 
 or remove them afterward ({{rm .topmsg .topdeps}})._

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4193) cql delete does not delete


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

Jonathan Ellis commented on CASSANDRA-4193:
---

+1

nit: comment above cfDef.isComposite  builder.componentCount() != 0 needs 
to be updated

 cql delete does not delete 
 ---

 Key: CASSANDRA-4193
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4193
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Jackson Chung
Assignee: Sylvain Lebresne
  Labels: cql3
 Fix For: 1.1.2

 Attachments: 4193.txt


 tested in 1.1 and trunk branch on a single node:
 {panel}
 cqlsh:test create table testcf_old ( username varchar , id int , name 
 varchar , stuff varchar, primary key(username,id,name)) with compact storage;
 cqlsh:test insert into testcf_old ( username , id , name , stuff ) values 
 ('abc', 2, 'rst', 'some other bunch of craps');
 cqlsh:test select * from testcf_old;
  username | id | name | stuff
 --++--+---
   abc |  2 |  rst | some other bunch of craps
   abc |  4 |  xyz |  a bunch of craps
 cqlsh:test delete from testcf_old where username = 'abc' and id =2;
 cqlsh:test select * from testcf_old;
  username | id | name | stuff
 --++--+---
   abc |  2 |  rst | some other bunch of craps
   abc |  4 |  xyz |  a bunch of craps
 {panel}
 same also when not using compact:
 {panel}
 cqlsh:test create table testcf ( username varchar , id int , name varchar , 
 stuff varchar, primary key(username,id));
 cqlsh:test select * from testcf;
  username | id | name  | stuff
 --++---+--
   abc |  2 | some other bunch of craps |  rst
   abc |  4 |   xyz | a bunch of craps
 cqlsh:test delete from testcf where username = 'abc' and id =2;
 cqlsh:test select * from testcf;
  username | id | name  | stuff
 --++---+--
   abc |  2 | some other bunch of craps |  rst
   abc |  4 |   xyz | a bunch of craps
 {panel}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3881) reduce computational complexity of processing topology changes


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

Jonathan Ellis commented on CASSANDRA-3881:
---

Pushed this to https://github.com/jbellis/cassandra/tree/3881-clone-tmd with 
some extra synchronization cleanup

 reduce computational complexity of processing topology changes
 --

 Key: CASSANDRA-3881
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3881
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Peter Schuller
Assignee: Sam Overton
  Labels: vnodes

 This constitutes follow-up work from CASSANDRA-3831 where a partial 
 improvement was committed, but the fundamental issue was not fixed. The 
 maximum practical cluster size was significantly improved, but further work 
 is expected to be necessary as cluster sizes grow.
 _Edit0: Appended patch information._
 h3. Patches
 ||Compare||Raw diff||Description||
 |[00_snitch_topology|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology]|[00_snitch_topology.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology.diff]|Adds
  some functionality to TokenMetadata to track which endpoints and racks exist 
 in a DC.|
 |[01_calc_natural_endpoints|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints]|[01_calc_natural_endpoints.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints.diff]|Rewritten
  O(logN) implementation of calculateNaturalEndpoints using the topology 
 information from the tokenMetadata.|
 
 _Note: These are branches managed with TopGit. If you are applying the patch 
 output manually, you will either need to filter the TopGit metadata files 
 (i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}), 
 or remove them afterward ({{rm .topmsg .topdeps}})._

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3881) reduce computational complexity of processing topology changes


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

Jonathan Ellis commented on CASSANDRA-3881:
---

More general assert instead (against TM.getTopology) pushed to 
https://github.com/jbellis/cassandra/tree/3881-clone-tmd-2

 reduce computational complexity of processing topology changes
 --

 Key: CASSANDRA-3881
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3881
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Peter Schuller
Assignee: Sam Overton
  Labels: vnodes

 This constitutes follow-up work from CASSANDRA-3831 where a partial 
 improvement was committed, but the fundamental issue was not fixed. The 
 maximum practical cluster size was significantly improved, but further work 
 is expected to be necessary as cluster sizes grow.
 _Edit0: Appended patch information._
 h3. Patches
 ||Compare||Raw diff||Description||
 |[00_snitch_topology|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology]|[00_snitch_topology.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology.diff]|Adds
  some functionality to TokenMetadata to track which endpoints and racks exist 
 in a DC.|
 |[01_calc_natural_endpoints|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints]|[01_calc_natural_endpoints.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints.diff]|Rewritten
  O(logN) implementation of calculateNaturalEndpoints using the topology 
 information from the tokenMetadata.|
 
 _Note: These are branches managed with TopGit. If you are applying the patch 
 output manually, you will either need to filter the TopGit metadata files 
 (i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}), 
 or remove them afterward ({{rm .topmsg .topdeps}})._

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-3633) update stress to support prepared statements