date:20111114

2011-11-14 Thread T Jake Luciani (Issue Comment Edited) (JIRA)

Author: slebresne
Date: Mon Nov 14 14:31:42 2011
New Revision: 1201726

URL: http://svn.apache.org/viewvc?rev=1201726view=rev
Log:
Use (Guava inspired) faster bytes comparison
patch by slebresne; reviewed by jbellis for CASSANDRA-3434

Modified:
cassandra/trunk/CHANGES.txt
cassandra/trunk/src/java/org/apache/cassandra/utils/ByteBufferUtil.java
cassandra/trunk/src/java/org/apache/cassandra/utils/FBUtilities.java

cassandra/trunk/test/unit/org/apache/cassandra/db/marshal/ReversedTypeTest.java
cassandra/trunk/test/unit/org/apache/cassandra/dht/RangeTest.java

Modified: cassandra/trunk/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1201726r1=1201725r2=1201726view=diff
==
--- cassandra/trunk/CHANGES.txt (original)
+++ cassandra/trunk/CHANGES.txt Mon Nov 14 14:31:42 2011
@@ -5,6 +5,7 @@
  * replace compactionlock use in schema migration by checking CFS.isValid
(CASSANDRA-3116)
  * recognize that SELECT first ... * isn't really SELECT * (CASSANDRA-3445)
+ * Use faster bytes comparison (CASSANDRA-3434)
 
 
 1.0.3

Modified: 
cassandra/trunk/src/java/org/apache/cassandra/utils/ByteBufferUtil.java
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/utils/ByteBufferUtil.java?rev=1201726r1=1201725r2=1201726view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/utils/ByteBufferUtil.java 
(original)
+++ cassandra/trunk/src/java/org/apache/cassandra/utils/ByteBufferUtil.java Mon 
Nov 14 14:31:42 2011
@@ -80,23 +80,25 @@ public class ByteBufferUtil
 {
 assert o1 != null;
 assert o2 != null;
+if (o1 == o2)
+return 0;
 
 if (o1.hasArray()  o2.hasArray())
 { 
 return FBUtilities.compareUnsigned(o1.array(), o2.array(), 
o1.position() + o1.arrayOffset(),
 o2.position() + o2.arrayOffset(), o1.remaining(), 
o2.remaining());
 }
-
-int minLength = Math.min(o1.remaining(), o2.remaining());
-for (int x = 0, i = o1.position(), j = o2.position(); x  minLength; 
x++, i++, j++)
-{
-if (o1.get(i) == o2.get(j))
-continue;
-// compare non-equal bytes as unsigned
-return (o1.get(i)  0xFF)  (o2.get(j)  0xFF) ? -1 : 1;
-}
 
-return (o1.remaining() == o2.remaining()) ? 0 : ((o1.remaining()  
o2.remaining()) ? -1 : 1);
+int end1 = o1.position() + o1.remaining();
+int end2 = o2.position() + o2.remaining();
+for (int i = o1.position(), j = o2.position(); i  end1  j  end2; 
i++, j++)
+{
+int a = (o1.get(i)  0xff);
+int b = (o2.get(j)  0xff);
+if (a != b)
+return a - b;
+}
+return o1.remaining() - o2.remaining();
 }
 
 public static int compare(byte[] o1, ByteBuffer o2)

Modified: cassandra/trunk/src/java/org/apache/cassandra/utils/FBUtilities.java
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/utils/FBUtilities.java?rev=1201726r1=1201725r2=1201726view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/utils/FBUtilities.java 
(original)
+++ cassandra/trunk/src/java/org/apache/cassandra/utils/FBUtilities.java Mon 
Nov 14 14:31:42 2011
@@ -288,22 +288,7 @@ public class FBUtilities
 
 public static int compareUnsigned(byte[] bytes1, byte[] bytes2, int 
offset1, int offset2, int len1, int len2)
 {
-if (bytes1 == null)
-{
-return bytes2 == null ? 0 : -1;
-}
-if (bytes2 == null) return 1;
-
-int minLength = Math.min(len1, len2);
-for (int x = 0, i = offset1, j = offset2; x  minLength; x++, i++, j++)
-{
-if (bytes1[i] == bytes2[j])
-continue;
-// compare non-equal bytes as unsigned
-return (bytes1[i]  0xFF)  (bytes2[j]  0xFF) ? -1 : 1;
-}
-if (len1 == len2) return 0;
-else return (len1  len2) ? -1 : 1;
+return FastByteComparisons.compareTo(bytes1, offset1, len1, bytes2, 
offset2, len2);
 }
   
 /**

Modified: 
cassandra/trunk/test/unit/org/apache/cassandra/db/marshal/ReversedTypeTest.java
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/test/unit/org/apache/cassandra/db/marshal/ReversedTypeTest.java?rev=1201726r1=1201725r2=1201726view=diff
==
--- 
cassandra/trunk/test/unit/org/apache/cassandra/db/marshal/ReversedTypeTest.java 
(original)
+++ 
cassandra/trunk/test/unit/org/apache/cassandra/db/marshal/ReversedTypeTest.java 
Mon Nov 14 14:31:42 2011
@@ -30,11 +30,11 @@ public class ReversedTypeTest
 {
 ReversedTypeLong t =

[jira] [Resolved] (CASSANDRA-3434) Explore using Guava (or guava inspired) faster bytes comparison

2011-11-14 Thread Sylvain Lebresne (Resolved) (JIRA)


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

Sylvain Lebresne resolved CASSANDRA-3434.
-

   Resolution: Fixed
Fix Version/s: 1.1
 Reviewer: jbellis
 Assignee: Sylvain Lebresne

Committed

 Explore using Guava (or guava inspired) faster bytes comparison
 ---

 Key: CASSANDRA-3434
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3434
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 1.1

 Attachments: 3434.patch


 Guava uses un.misc.Unsafe to do a faster byte arrays comparison (on long at a 
 time) as noted in HADOOP-7761.
 We should probably look into it.

--
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-3434) Explore using Guava (or guava inspired) faster bytes comparison

2011-11-14 Thread Hudson (Commented) (JIRA)


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

Hudson commented on CASSANDRA-3434:
---

Integrated in Cassandra #1206 (See 
[https://builds.apache.org/job/Cassandra/1206/])
Use (Guava inspired) faster bytes comparison
patch by slebresne; reviewed by jbellis for CASSANDRA-3434

slebresne : 
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1201726
Files : 
* /cassandra/trunk/CHANGES.txt
* /cassandra/trunk/src/java/org/apache/cassandra/utils/ByteBufferUtil.java
* /cassandra/trunk/src/java/org/apache/cassandra/utils/FBUtilities.java
* 
/cassandra/trunk/test/unit/org/apache/cassandra/db/marshal/ReversedTypeTest.java
* /cassandra/trunk/test/unit/org/apache/cassandra/dht/RangeTest.java


 Explore using Guava (or guava inspired) faster bytes comparison
 ---

 Key: CASSANDRA-3434
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3434
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 1.1

 Attachments: 3434.patch


 Guava uses un.misc.Unsafe to do a faster byte arrays comparison (on long at a 
 time) as noted in HADOOP-7761.
 We should probably look into it.

--
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-3490) Error while creating many column families: ConfigurationException: Previous version mismatch. cannot apply.

2011-11-14 Thread Created

Error while creating many column families: ConfigurationException: Previous 
version mismatch. cannot apply.
-

 Key: CASSANDRA-3490
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3490
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.0.2
Reporter: Nicolas Lalevée


Maybe a duplicate/reopen of CASSANDRA-1384

I have a cluster of 4 cassandra nodes 1.0.2. Via the API (I'm using Hector), I 
create about 130 column families. On the client side I am hit with:
{noformat}
[junit-coverage] 
me.prettyprint.hector.api.exceptions.HCassandraInternalException: Cassandra 
encountered an internal error processing this request: TApplicationError type: 
6 message:Internal error processing system_add_column_family
[junit-coverage]at 
me.prettyprint.cassandra.service.ExceptionsTranslatorImpl.translate(ExceptionsTranslatorImpl.java:31)
 ~[hector-core-1.0-1.jar:na]
[junit-coverage]at 
me.prettyprint.cassandra.service.ThriftCluster$4.execute(ThriftCluster.java:100)
 ~[hector-core-1.0-1.jar:na]
[junit-coverage]at 
me.prettyprint.cassandra.service.ThriftCluster$4.execute(ThriftCluster.java:89) 
~[hector-core-1.0-1.jar:na]
[junit-coverage]at 
me.prettyprint.cassandra.service.Operation.executeAndSetResult(Operation.java:101)
 ~[hector-core-1.0-1.jar:na]
[junit-coverage]at 
me.prettyprint.cassandra.connection.HConnectionManager.operateWithFailover(HConnectionManager.java:233)
 ~[hector-core-1.0-1.jar:na]
[junit-coverage]at 
me.prettyprint.cassandra.service.ThriftCluster.addColumnFamily(ThriftCluster.java:104)
 ~[hector-core-1.0-1.jar:na]
[junit-coverage]. [my application code] ..
{noformat}

On the server side, I can see these line in many nodes:
{noformat}
ERROR 15:47:04,833 Internal error processing system_add_column_family
java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
org.apache.cassandra.config.ConfigurationException: Previous version mismatch. 
cannot apply.
at 
org.apache.cassandra.thrift.CassandraServer.applyMigrationOnStage(CassandraServer.java:898)
at 
org.apache.cassandra.thrift.CassandraServer.system_add_column_family(CassandraServer.java:914)
at 
org.apache.cassandra.thrift.Cassandra$Processor$system_add_column_family.process(Cassandra.java:3832)
at 
org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
at 
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
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)
Caused by: java.util.concurrent.ExecutionException: 
org.apache.cassandra.config.ConfigurationException: Previous version mismatch. 
cannot apply.
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at 
org.apache.cassandra.thrift.CassandraServer.applyMigrationOnStage(CassandraServer.java:890)
... 7 more
Caused by: org.apache.cassandra.config.ConfigurationException: Previous version 
mismatch. cannot apply.
at org.apache.cassandra.db.migration.Migration.apply(Migration.java:100)
at 
org.apache.cassandra.thrift.CassandraServer$2.call(CassandraServer.java:883)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
... 3 more
ERROR 15:47:04,834 Fatal exception in thread Thread[MigrationStage:1,5,main] 
org.apache.cassandra.config.ConfigurationException: Previous version mismatch. 
cannot apply.
at org.apache.cassandra.db.migration.Migration.apply(Migration.java:100)
at 
org.apache.cassandra.thrift.CassandraServer$2.call(CassandraServer.java:883)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
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}


--
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-1391) Allow Concurrent Schema Migrations

2011-11-14 Thread Pavel Yaskevich (Commented) (JIRA)


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

Pavel Yaskevich commented on CASSANDRA-1391:


It seems like what we really want from migrations is schema state before any 
given migration and actual modifications migration makes like add keyspace 
ks with attributes = ..., update cf with attributes =  

As all of the migrations are user initiated we can easily calculate what 
modifications migration makes and propagate only them keeping TimeUUID as ID of 
the migration to identify apply order. As it's okay for us to require full 
cluster update before accepting schema modifications it makes merge a trivial 
task where modifications should be applied one-by-one on some initial state 
of the schema (that also allows as to remove Avro overhead from migrations). 
Abandoning Avro would make things less fragile because there would be no need 
to modify CFMetaData or any other classes to support new (or deleted) 
attributes.

 Allow Concurrent Schema Migrations
 --

 Key: CASSANDRA-1391
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.7.0
Reporter: Stu Hood
Assignee: Pavel Yaskevich
 Fix For: 1.1

 Attachments: CASSANDRA-1391.patch


 CASSANDRA-1292 fixed multiple migrations started from the same node to 
 properly queue themselves, but it is still possible for migrations initiated 
 on different nodes to conflict and leave the cluster in a bad state. Since 
 the system_add/drop/rename methods are accessible directly from the client 
 API, they should be completely safe for concurrent use.
 It should be possible to allow for most types of concurrent migrations by 
 converting the UUID schema ID into a VersionVectorClock (as provided by 
 CASSANDRA-580).

--
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-1391) Allow Concurrent Schema Migrations

2011-11-14 Thread T Jake Luciani (Commented) (JIRA)


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

T Jake Luciani commented on CASSANDRA-1391:
---

My moving to CF based migration logic it would be very useful to have the logic 
abstracted so it can be used for other use cases.

Migrations give you the following:

  * RF = N where N is the size of the ring.
  * All changes are pushed to new nodes when they join the ring.
  * previously sent data is available locally on startup



 Allow Concurrent Schema Migrations
 --

 Key: CASSANDRA-1391
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.7.0
Reporter: Stu Hood
Assignee: Pavel Yaskevich
 Fix For: 1.1

 Attachments: CASSANDRA-1391.patch


 CASSANDRA-1292 fixed multiple migrations started from the same node to 
 properly queue themselves, but it is still possible for migrations initiated 
 on different nodes to conflict and leave the cluster in a bad state. Since 
 the system_add/drop/rename methods are accessible directly from the client 
 API, they should be completely safe for concurrent use.
 It should be possible to allow for most types of concurrent migrations by 
 converting the UUID schema ID into a VersionVectorClock (as provided by 
 CASSANDRA-580).

--
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] [Issue Comment Edited] (CASSANDRA-1391) Allow Concurrent Schema Migrations


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

T Jake Luciani edited comment on CASSANDRA-1391 at 11/14/11 5:05 PM:
-

By moving to CF based migration logic it would be very useful to have the logic 
abstracted from schemas so it can be used for other use cases.

Migrations give you the following:

  * RF = N where N is the size of the ring.
  * All changes are pushed to new nodes when they join the ring.
  * previously sent data is available locally on startup



  was (Author: tjake):
My moving to CF based migration logic it would be very useful to have the 
logic abstracted so it can be used for other use cases.

Migrations give you the following:

  * RF = N where N is the size of the ring.
  * All changes are pushed to new nodes when they join the ring.
  * previously sent data is available locally on startup


  
 Allow Concurrent Schema Migrations
 --

 Key: CASSANDRA-1391
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.7.0
Reporter: Stu Hood
Assignee: Pavel Yaskevich
 Fix For: 1.1

 Attachments: CASSANDRA-1391.patch


 CASSANDRA-1292 fixed multiple migrations started from the same node to 
 properly queue themselves, but it is still possible for migrations initiated 
 on different nodes to conflict and leave the cluster in a bad state. Since 
 the system_add/drop/rename methods are accessible directly from the client 
 API, they should be completely safe for concurrent use.
 It should be possible to allow for most types of concurrent migrations by 
 converting the UUID schema ID into a VersionVectorClock (as provided by 
 CASSANDRA-580).

--
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-3490) Error while creating many column families: ConfigurationException: Previous version mismatch. cannot apply.

2011-11-14 Thread Jonathan Ellis (Resolved) (JIRA)


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

Jonathan Ellis resolved CASSANDRA-3490.
---

Resolution: Not A Problem

creating multiple CFs simultaneously is not supported prior to CASSANDRA-1391.  
See wiki.apache.org/cassandra/FAQ#schema_disagreement for how to unwedge things.

 Error while creating many column families: ConfigurationException: Previous 
 version mismatch. cannot apply.
 -

 Key: CASSANDRA-3490
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3490
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.0.2
Reporter: Nicolas Lalevée

 Maybe a duplicate/reopen of CASSANDRA-1384
 I have a cluster of 4 cassandra nodes 1.0.2. Via the API (I'm using Hector), 
 I create about 130 column families. On the client side I am hit with:
 {noformat}
 [junit-coverage] 
 me.prettyprint.hector.api.exceptions.HCassandraInternalException: Cassandra 
 encountered an internal error processing this request: TApplicationError 
 type: 6 message:Internal error processing system_add_column_family
 [junit-coverage]  at 
 me.prettyprint.cassandra.service.ExceptionsTranslatorImpl.translate(ExceptionsTranslatorImpl.java:31)
  ~[hector-core-1.0-1.jar:na]
 [junit-coverage]  at 
 me.prettyprint.cassandra.service.ThriftCluster$4.execute(ThriftCluster.java:100)
  ~[hector-core-1.0-1.jar:na]
 [junit-coverage]  at 
 me.prettyprint.cassandra.service.ThriftCluster$4.execute(ThriftCluster.java:89)
  ~[hector-core-1.0-1.jar:na]
 [junit-coverage]  at 
 me.prettyprint.cassandra.service.Operation.executeAndSetResult(Operation.java:101)
  ~[hector-core-1.0-1.jar:na]
 [junit-coverage]  at 
 me.prettyprint.cassandra.connection.HConnectionManager.operateWithFailover(HConnectionManager.java:233)
  ~[hector-core-1.0-1.jar:na]
 [junit-coverage]  at 
 me.prettyprint.cassandra.service.ThriftCluster.addColumnFamily(ThriftCluster.java:104)
  ~[hector-core-1.0-1.jar:na]
 [junit-coverage]  . [my application code] ..
 {noformat}
 On the server side, I can see these line in many nodes:
 {noformat}
 ERROR 15:47:04,833 Internal error processing system_add_column_family
 java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
 org.apache.cassandra.config.ConfigurationException: Previous version 
 mismatch. cannot apply.
 at 
 org.apache.cassandra.thrift.CassandraServer.applyMigrationOnStage(CassandraServer.java:898)
 at 
 org.apache.cassandra.thrift.CassandraServer.system_add_column_family(CassandraServer.java:914)
 at 
 org.apache.cassandra.thrift.Cassandra$Processor$system_add_column_family.process(Cassandra.java:3832)
 at 
 org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
 at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
 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)
 Caused by: java.util.concurrent.ExecutionException: 
 org.apache.cassandra.config.ConfigurationException: Previous version 
 mismatch. cannot apply.
 at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
 at java.util.concurrent.FutureTask.get(FutureTask.java:83)
 at 
 org.apache.cassandra.thrift.CassandraServer.applyMigrationOnStage(CassandraServer.java:890)
 ... 7 more
 Caused by: org.apache.cassandra.config.ConfigurationException: Previous 
 version mismatch. cannot apply.
 at 
 org.apache.cassandra.db.migration.Migration.apply(Migration.java:100)
 at 
 org.apache.cassandra.thrift.CassandraServer$2.call(CassandraServer.java:883)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 ... 3 more
 ERROR 15:47:04,834 Fatal exception in thread Thread[MigrationStage:1,5,main] 
 org.apache.cassandra.config.ConfigurationException: Previous version 
 mismatch. cannot apply.
 at 
 org.apache.cassandra.db.migration.Migration.apply(Migration.java:100)
 at 
 org.apache.cassandra.thrift.CassandraServer$2.call(CassandraServer.java:883)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 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)

[jira] [Commented] (CASSANDRA-3490) Error while creating many column families: ConfigurationException: Previous version mismatch. cannot apply.

2011-11-14 Thread Commented


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

Nicolas Lalevée commented on CASSANDRA-3490:


I am effectively hit by some concurrency issue, I had this issue with 0.8. I 
didn't know that this error message was about schema disagreement.
Thanks for the quick reply.

 Error while creating many column families: ConfigurationException: Previous 
 version mismatch. cannot apply.
 -

 Key: CASSANDRA-3490
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3490
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.0.2
Reporter: Nicolas Lalevée

 Maybe a duplicate/reopen of CASSANDRA-1384
 I have a cluster of 4 cassandra nodes 1.0.2. Via the API (I'm using Hector), 
 I create about 130 column families. On the client side I am hit with:
 {noformat}
 [junit-coverage] 
 me.prettyprint.hector.api.exceptions.HCassandraInternalException: Cassandra 
 encountered an internal error processing this request: TApplicationError 
 type: 6 message:Internal error processing system_add_column_family
 [junit-coverage]  at 
 me.prettyprint.cassandra.service.ExceptionsTranslatorImpl.translate(ExceptionsTranslatorImpl.java:31)
  ~[hector-core-1.0-1.jar:na]
 [junit-coverage]  at 
 me.prettyprint.cassandra.service.ThriftCluster$4.execute(ThriftCluster.java:100)
  ~[hector-core-1.0-1.jar:na]
 [junit-coverage]  at 
 me.prettyprint.cassandra.service.ThriftCluster$4.execute(ThriftCluster.java:89)
  ~[hector-core-1.0-1.jar:na]
 [junit-coverage]  at 
 me.prettyprint.cassandra.service.Operation.executeAndSetResult(Operation.java:101)
  ~[hector-core-1.0-1.jar:na]
 [junit-coverage]  at 
 me.prettyprint.cassandra.connection.HConnectionManager.operateWithFailover(HConnectionManager.java:233)
  ~[hector-core-1.0-1.jar:na]
 [junit-coverage]  at 
 me.prettyprint.cassandra.service.ThriftCluster.addColumnFamily(ThriftCluster.java:104)
  ~[hector-core-1.0-1.jar:na]
 [junit-coverage]  . [my application code] ..
 {noformat}
 On the server side, I can see these line in many nodes:
 {noformat}
 ERROR 15:47:04,833 Internal error processing system_add_column_family
 java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
 org.apache.cassandra.config.ConfigurationException: Previous version 
 mismatch. cannot apply.
 at 
 org.apache.cassandra.thrift.CassandraServer.applyMigrationOnStage(CassandraServer.java:898)
 at 
 org.apache.cassandra.thrift.CassandraServer.system_add_column_family(CassandraServer.java:914)
 at 
 org.apache.cassandra.thrift.Cassandra$Processor$system_add_column_family.process(Cassandra.java:3832)
 at 
 org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
 at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
 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)
 Caused by: java.util.concurrent.ExecutionException: 
 org.apache.cassandra.config.ConfigurationException: Previous version 
 mismatch. cannot apply.
 at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
 at java.util.concurrent.FutureTask.get(FutureTask.java:83)
 at 
 org.apache.cassandra.thrift.CassandraServer.applyMigrationOnStage(CassandraServer.java:890)
 ... 7 more
 Caused by: org.apache.cassandra.config.ConfigurationException: Previous 
 version mismatch. cannot apply.
 at 
 org.apache.cassandra.db.migration.Migration.apply(Migration.java:100)
 at 
 org.apache.cassandra.thrift.CassandraServer$2.call(CassandraServer.java:883)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 ... 3 more
 ERROR 15:47:04,834 Fatal exception in thread Thread[MigrationStage:1,5,main] 
 org.apache.cassandra.config.ConfigurationException: Previous version 
 mismatch. cannot apply.
 at 
 org.apache.cassandra.db.migration.Migration.apply(Migration.java:100)
 at 
 org.apache.cassandra.thrift.CassandraServer$2.call(CassandraServer.java:883)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at

[jira] [Commented] (CASSANDRA-1391) Allow Concurrent Schema Migrations

2011-11-14 Thread Jonathan Ellis (Commented) (JIRA)


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

Jonathan Ellis commented on CASSANDRA-1391:
---

It seems to make sense eventually.  But for this ticket let's stick with 
LocalPartitioner and the existing schema replication.

 Allow Concurrent Schema Migrations
 --

 Key: CASSANDRA-1391
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.7.0
Reporter: Stu Hood
Assignee: Pavel Yaskevich
 Fix For: 1.1

 Attachments: CASSANDRA-1391.patch


 CASSANDRA-1292 fixed multiple migrations started from the same node to 
 properly queue themselves, but it is still possible for migrations initiated 
 on different nodes to conflict and leave the cluster in a bad state. Since 
 the system_add/drop/rename methods are accessible directly from the client 
 API, they should be completely safe for concurrent use.
 It should be possible to allow for most types of concurrent migrations by 
 converting the UUID schema ID into a VersionVectorClock (as provided by 
 CASSANDRA-580).

--
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-3491) Recursion bug in CollationController

2011-11-14 Thread T Jake Luciani (Created) (JIRA)

Recursion bug in CollationController


 Key: CASSANDRA-3491
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3491
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: T Jake Luciani
 Fix For: 1.0.4


The following stack trace seems to indicate a recursion bug in 
CollationController

Where the stats collection mutation is itself having stats collected on and so 
fourth

http://pastebin.com/raw.php?i=35Rt7ryB

--
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-1391) Allow Concurrent Schema Migrations

2011-11-14 Thread Pavel Yaskevich (Commented) (JIRA)


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

Pavel Yaskevich commented on CASSANDRA-1391:


Than we need to preserve an order of the migrations that we accept from remote 
nodes otherwise we don't have sufficient information to apply modifications or 
am I missing something? Can you please brigly describe the process how you see 
it?

 Allow Concurrent Schema Migrations
 --

 Key: CASSANDRA-1391
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.7.0
Reporter: Stu Hood
Assignee: Pavel Yaskevich
 Fix For: 1.1

 Attachments: CASSANDRA-1391.patch


 CASSANDRA-1292 fixed multiple migrations started from the same node to 
 properly queue themselves, but it is still possible for migrations initiated 
 on different nodes to conflict and leave the cluster in a bad state. Since 
 the system_add/drop/rename methods are accessible directly from the client 
 API, they should be completely safe for concurrent use.
 It should be possible to allow for most types of concurrent migrations by 
 converting the UUID schema ID into a VersionVectorClock (as provided by 
 CASSANDRA-580).

--
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-3491) Recursion bug in CollationController

2011-11-14 Thread Mck SembWever (Issue Comment Edited) (JIRA)


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

Jonathan Ellis updated CASSANDRA-3491:
--

Attachment: 3491.txt

Patch to revert CASSANDRA-2503.  Clearly putting that in 1.0.x was a mistake 
(mine).

 Recursion bug in CollationController
 

 Key: CASSANDRA-3491
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3491
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: T Jake Luciani
 Fix For: 1.0.4

 Attachments: 3491.txt


 The following stack trace seems to indicate a recursion bug in 
 CollationController
 Where the stats collection mutation is itself having stats collected on and 
 so fourth
 http://pastebin.com/raw.php?i=35Rt7ryB

--
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-3427) CompressionMetadata is not shared across threads, we create a new one for each read

2011-11-14 Thread Mck SembWever (Commented) (JIRA)

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

Mck SembWever commented on CASSANDRA-3427:
--

version: 1.0.2 snapshot (pretty close to release date).
w/o compression: that would require a full compact/scrub. that takes close to
24hrs :-(
patch: i attach that and hopefully have output soon. a heap dump can be done at
the same time...

CompressionMetadata is not shared across threads, we create a new one for
each read
---

Attachments: 0001-debugging.patch, 3427.patch, 3427_v2.patch,
CASSANDRA-3427.patch, jmx_jvm_memory-month.png, jmx_jvm_memory-week.png

[jira] [Issue Comment Edited] (CASSANDRA-3427) CompressionMetadata is not shared across threads, we create a new one for each read

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

Mck SembWever edited comment on CASSANDRA-3427 at 11/14/11 6:33 PM:

version: 1.0.2 snapshot (pretty close to release date) + CASSANDRA-3197.
w/o compression: that would require a full compact/scrub. that takes close to
24hrs :-(
patch: i attach that and hopefully have output soon. a heap dump can be done at
the same time...

was (Author: michaelsembwever):
version: 1.0.2 snapshot (pretty close to release date).
w/o compression: that would require a full compact/scrub. that takes close to
24hrs :-(
patch: i attach that and hopefully have output soon. a heap dump can be done at
the same time...

CompressionMetadata is not shared across threads, we create a new one for
each read
---

Attachments: 0001-debugging.patch, 3427.patch, 3427_v2.patch,
CASSANDRA-3427.patch, jmx_jvm_memory-month.png, jmx_jvm_memory-week.png

[jira] [Commented] (CASSANDRA-3427) CompressionMetadata is not shared across threads, we create a new one for each read

2011-11-14 Thread Mck SembWever (Commented) (JIRA)


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

Mck SembWever commented on CASSANDRA-3427:
--

startup log with debug{noformat}INFO  48:34,688 DatabaseDescriptor: Loading 
settings from file:/iad/finn/countstatistics/conf/cassandra-prod.yaml
INFO  48:34,782 DatabaseDescriptor: DiskAccessMode 'auto' determined to be 
mmap, indexAccessMode is mmap
INFO  48:34,792 DatabaseDescriptor: Global memtable threshold is enabled at 
512MB
INFO  48:34,890 AbstractCassandraDaemon: JVM vendor/version: Java HotSpot(TM) 
64-Bit Server VM/1.6.0_24
INFO  48:34,891 AbstractCassandraDaemon: Heap size: 760414208/8506048512
INFO  48:34,891 AbstractCassandraDaemon: Classpath: 
/iad/finn/countstatistics/jar/countstatistics.jar:/iad/common/apps/cassandra/lib/jamm-0.2.5.jar
INFO  48:37,158 CLibrary: JNA mlockall successful
INFO  48:37,879 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/Versions-h-42 (256 bytes)
INFO  48:37,879 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/Versions-h-41 (256 bytes)
INFO  48:37,879 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/Versions-h-40 (256 bytes)
INFO  48:37,959 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/IndexInfo-h-3 (223 bytes)
INFO  48:38,001 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/Schema-h-15 (34257 bytes)
INFO  48:38,045 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/Migrations-h-15 (78524 bytes)
INFO  48:38,096 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/LocationInfo-h-150 (80 bytes)
INFO  48:38,096 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/LocationInfo-h-149 (628 bytes)
INFO  48:38,096 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/LocationInfo-h-151 (163 bytes)
INFO  48:38,192 DatabaseDescriptor: Loading schema version 
1940c630-0be4-11e1--d1695892b1ff
INFO  51:35,136 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191473
 (38646535 bytes)
INFO  51:35,136 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-190467
 (2284524668 bytes)
INFO  51:35,136 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191469
 (254927460 bytes)
INFO  51:35,136 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191475
 (30477008 bytes)
INFO  51:35,136 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-114136
 (156044360682 bytes)
INFO  51:35,137 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191294
 (4585008988 bytes)
INFO  51:35,137 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-190415
 (15857295280 bytes)
INFO  51:35,137 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-183183
 (196289440978 bytes)
INFO  51:35,137 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191472
 (1346076 bytes)
INFO  51:35,137 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-190736
 (4626053255 bytes)
INFO  51:35,137 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191435
 (1188223188 bytes)
INFO  51:35,187 CompressionMetadata: Allocating chunks index for 5745 chunks 
for uncompressed size of 1470519 
(/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191472-CompressionInfo.db)
INFO  51:35,421 CompressionMetadata: Allocating chunks index for 129646 chunks 
for uncompressed size of 33189311 
(/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191475-CompressionInfo.db)
INFO  51:35,544 CompressionMetadata: Allocating chunks index for 165602 chunks 
for uncompressed size of 42393918

[jira] [Commented] (CASSANDRA-3418) Counter decrements require a space around the minus sign but not around the plus sign

2011-11-14 Thread paul cannon (Commented) (JIRA)


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

paul cannon commented on CASSANDRA-3418:


This doesn't do the right thing when minusing a negative value, like:

{noformat}
UPDATE validation_cf_counter SET test = test - -1 WHERE id='test_key';
{noformat}

It subtracts 1, instead of adding 1.

 Counter decrements require a space around the minus sign but not around the 
 plus sign
 -

 Key: CASSANDRA-3418
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3418
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Kelley Reynolds
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 1.0.3

 Attachments: CASSANDRA-3418.patch


 UPDATE validation_cf_counter SET test=test+1 WHERE id='test_key' = Success
 UPDATE validation_cf_counter SET test=test + 1 WHERE id='test_key' = Success
 UPDATE validation_cf_counter SET test=test - 1 WHERE id='test_key' = Success
 UPDATE validation_cf_counter SET test=test-1 WHERE id='test_key' = Failure 
 (line 1:38 no viable alternative at input 'test')

--
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] [Issue Comment Edited] (CASSANDRA-3427) CompressionMetadata is not shared across threads, we create a new one for each read

2011-11-14 Thread Mck SembWever (Issue Comment Edited) (JIRA)


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

Mck SembWever edited comment on CASSANDRA-3427 at 11/14/11 8:13 PM:


startup log with debug (off 1.0.2 release){noformat}INFO  48:34,688 
DatabaseDescriptor: Loading settings from 
file:/iad/finn/countstatistics/conf/cassandra-prod.yaml
INFO  48:34,782 DatabaseDescriptor: DiskAccessMode 'auto' determined to be 
mmap, indexAccessMode is mmap
INFO  48:34,792 DatabaseDescriptor: Global memtable threshold is enabled at 
512MB
INFO  48:34,890 AbstractCassandraDaemon: JVM vendor/version: Java HotSpot(TM) 
64-Bit Server VM/1.6.0_24
INFO  48:34,891 AbstractCassandraDaemon: Heap size: 760414208/8506048512
INFO  48:34,891 AbstractCassandraDaemon: Classpath: 
/iad/finn/countstatistics/jar/countstatistics.jar:/iad/common/apps/cassandra/lib/jamm-0.2.5.jar
INFO  48:37,158 CLibrary: JNA mlockall successful
INFO  48:37,879 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/Versions-h-42 (256 bytes)
INFO  48:37,879 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/Versions-h-41 (256 bytes)
INFO  48:37,879 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/Versions-h-40 (256 bytes)
INFO  48:37,959 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/IndexInfo-h-3 (223 bytes)
INFO  48:38,001 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/Schema-h-15 (34257 bytes)
INFO  48:38,045 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/Migrations-h-15 (78524 bytes)
INFO  48:38,096 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/LocationInfo-h-150 (80 bytes)
INFO  48:38,096 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/LocationInfo-h-149 (628 bytes)
INFO  48:38,096 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/system/LocationInfo-h-151 (163 bytes)
INFO  48:38,192 DatabaseDescriptor: Loading schema version 
1940c630-0be4-11e1--d1695892b1ff
INFO  51:35,136 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191473
 (38646535 bytes)
INFO  51:35,136 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-190467
 (2284524668 bytes)
INFO  51:35,136 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191469
 (254927460 bytes)
INFO  51:35,136 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191475
 (30477008 bytes)
INFO  51:35,136 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-114136
 (156044360682 bytes)
INFO  51:35,137 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191294
 (4585008988 bytes)
INFO  51:35,137 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-190415
 (15857295280 bytes)
INFO  51:35,137 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-183183
 (196289440978 bytes)
INFO  51:35,137 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191472
 (1346076 bytes)
INFO  51:35,137 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-190736
 (4626053255 bytes)
INFO  51:35,137 SSTableReader: Opening 
/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191435
 (1188223188 bytes)
INFO  51:35,187 CompressionMetadata: Allocating chunks index for 5745 chunks 
for uncompressed size of 1470519 
(/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191472-CompressionInfo.db)
INFO  51:35,421 CompressionMetadata: Allocating chunks index for 129646 chunks 
for uncompressed size of 33189311 
(/iad/finn/countstatistics/cassandra-data/countstatisticsCount/thrift_no_finntech_countstats_count_Count_neg8589045746818385983-h-191475-CompressionInfo.db)
INFO  51:35,544 CompressionMetadata: Allocating chunks index for 165602 chunks 
for uncompressed size of 42393918

[jira] [Commented] (CASSANDRA-3418) Counter decrements require a space around the minus sign but not around the plus sign

2011-11-14 Thread Jonathan Ellis (Commented) (JIRA)


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

Jonathan Ellis commented on CASSANDRA-3418:
---

bq. It's not related to QueryProcessor tho

But that's the simplest way to add CQL tests I would think?  Open to other 
ideas.

 Counter decrements require a space around the minus sign but not around the 
 plus sign
 -

 Key: CASSANDRA-3418
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3418
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Kelley Reynolds
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 1.0.3

 Attachments: CASSANDRA-3418.patch


 UPDATE validation_cf_counter SET test=test+1 WHERE id='test_key' = Success
 UPDATE validation_cf_counter SET test=test + 1 WHERE id='test_key' = Success
 UPDATE validation_cf_counter SET test=test - 1 WHERE id='test_key' = Success
 UPDATE validation_cf_counter SET test=test-1 WHERE id='test_key' = Failure 
 (line 1:38 no viable alternative at input 'test')

--
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-3492) Compression option chunk_length is not converted into KB as it should

2011-11-14 Thread Sylvain Lebresne (Created) (JIRA)

Compression option chunk_length is not converted into KB as it should
-

 Key: CASSANDRA-3492
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3492
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Critical
 Fix For: 1.0.3
 Attachments: 0001-Fix-chunk-length-option.patch



--
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] [Issue Comment Edited] (CASSANDRA-1391) Allow Concurrent Schema Migrations

2011-11-14 Thread Jonathan Ellis (Issue Comment Edited) (JIRA)


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

Jonathan Ellis edited comment on CASSANDRA-1391 at 11/14/11 8:58 PM:
-

For example, suppose we have two clients C1 and C2, and two nodes A and B.  
They have a columnfamily that includes the following options:

{noformat}
ColumnFamily1: {
  'default_validation_class': 'bytes',
  'comment': 'an example',
  'row_cache_size': 0
}
{noformat}

Next, C1 and C2 update ColumnFamily1 with M1 and M2 as follows:

{noformat}
M1 = ColumnFamily1: {'d_v_c': 'ascii', 'comment': 'foo'} @ T1}}
M2 = ColumnFamily1: {'d_v_c': 'utf8', 'row_cache_size': 100} @ T0  T1
{noformat}

(Note that we have a conflict on default_validation_class.)

Node A receives M1 first, while node B receives M2 first.

*Node A:*
{noformat}
(applies M1)
ColumnFamily1: {
  'default_validation_class': 'ascii',
  'comment': 'foo',
  'row_cache_size': 0
}

(applies M2)
ColumnFamily1: {
  'default_validation_class': 'ascii', // M2.dvc has no effect since T0  T1
  'comment': 'foo',
  'row_cache_size': 100
}
{noformat}

*Node B:*
{noformat}
(applies M2)
ColumnFamily1: {
  'default_validation_class': 'utf8',
  'comment': 'an example',
  'row_cache_size': 100
}

(applies M1)
ColumnFamily1: {
  'default_validation_class': 'ascii',
  'comment': 'foo',
  'row_cache_size': 100
}
{noformat}

Because timestamp-based conflict resolution is commutative, all nodes end with 
the same schema no matter what order they get the updates in.

  was (Author: jbellis):
For example, suppose we have two clients C1 and C2, and two nodes A and B.  
They have a columnfamily that includes the following options:

{noformat}
ColumnFamily1: {
  'default_validation_class': 'bytes',
  'comment': 'an example',
  'row_cache_size': 0
}
{noformat}

Next, C1 and C2 update ColumnFamily1 with M1 and M2 as follows:

{noformat}
M1 = ColumnFamily1: {'d_v_c': 'ascii', 'comment': 'foo'} @ T1}}
M2 = ColumnFamily1: {'d_v_c': 'utf8', 'row_cache_size': 100} @ T0  T1
{noformat}

(Note that we have a conflict on default_validation_class.)

Node A receives M1 first, while node B receives M2 first.

*Node A:*
{noformat}
(applies M1)
ColumnFamily1: {
  'default_validation_class': 'ascii',
  'comment': 'foo',
  'row_cache_size': 0
}

(applies M2)
ColumnFamily1: {
  'default_validation_class': 'ascii', // M2.dvc has no effect since T0  T1
  'comment': 'foo',
  'row_cache_size': 100
}
{noformat}

*Node B:*
{noformat}
ColumnFamily1: {
  'default_validation_class': 'utf8',
  'comment': 'an example',
  'row_cache_size': 100
}

(applies M1)
ColumnFamily1: {
  'default_validation_class': 'ascii',
  'comment': 'foo',
  'row_cache_size': 100
}
{noformat}

Because timestamp-based conflict resolution is commutative, all nodes end with 
the same schema no matter what order they get the updates in.
  
 Allow Concurrent Schema Migrations
 --

 Key: CASSANDRA-1391
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.7.0
Reporter: Stu Hood
Assignee: Pavel Yaskevich
 Fix For: 1.1

 Attachments: CASSANDRA-1391.patch


 CASSANDRA-1292 fixed multiple migrations started from the same node to 
 properly queue themselves, but it is still possible for migrations initiated 
 on different nodes to conflict and leave the cluster in a bad state. Since 
 the system_add/drop/rename methods are accessible directly from the client 
 API, they should be completely safe for concurrent use.
 It should be possible to allow for most types of concurrent migrations by 
 converting the UUID schema ID into a VersionVectorClock (as provided by 
 CASSANDRA-580).

--
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-3492) Compression option chunk_length is not converted into KB as it should

2011-11-14 Thread Sylvain Lebresne (Updated) (JIRA)


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

Sylvain Lebresne updated CASSANDRA-3492:


Attachment: 0001-Fix-chunk-length-option.patch

Oups

 Compression option chunk_length is not converted into KB as it should
 -

 Key: CASSANDRA-3492
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3492
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Critical
 Fix For: 1.0.3

 Attachments: 0001-Fix-chunk-length-option.patch




--
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-3427) CompressionMetadata is not shared across threads, we create a new one for each read

2011-11-14 Thread Sylvain Lebresne (Commented) (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-3427:
-

That's the stupidest bug ever. It happens we interpret the chunk_length_in_kb 
not in kb but in bytes.
Anyway, I've created CASSANDRA-3492 to address this.
Turns out if you don't update the chunk_length you're fine because the default 
is ok, but I guess hitting this issue initially has put you in the wrong spot :(

 CompressionMetadata is not shared across threads, we create a new one for 
 each read
 ---

 Key: CASSANDRA-3427
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3427
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
  Labels: compression
 Fix For: 1.0.2

 Attachments: 0001-debugging.patch, 3427.patch, 3427_v2.patch, 
 CASSANDRA-3427.patch, jmx_jvm_memory-month.png, jmx_jvm_memory-week.png


 The CompressionMetada holds the compressed block offsets in memory. Without 
 being absolutely huge, this is still of non-negligible size as soon as you 
 have a bit of data in the DB. Reallocating this for each read is a very bad 
 idea.
 Note that this only affect range queries, since normal queries uses 
 CompressedSegmentedFile that does reuse a unique CompressionMetadata instance.
 ( Background: http://thread.gmane.org/gmane.comp.db.cassandra.user/21362 )

--
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-3491) Recursion bug in CollationController

2011-11-14 Thread Sylvain Lebresne (Commented) (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-3491:
-

+1

 Recursion bug in CollationController
 

 Key: CASSANDRA-3491
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3491
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: T Jake Luciani
Assignee: Jonathan Ellis
 Fix For: 1.0.4

 Attachments: 3491.txt


 The following stack trace seems to indicate a recursion bug in 
 CollationController
 Where the stats collection mutation is itself having stats collected on and 
 so fourth
 http://pastebin.com/raw.php?i=35Rt7ryB

--
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-3493) cqlsh complains when you try to do UPDATE with counter columns

2011-11-14 Thread paul cannon (Created) (JIRA)

cqlsh complains when you try to do UPDATE with counter columns
--

 Key: CASSANDRA-3493
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3493
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor


trying to do a counter column UPDATE in cqlsh causes an Invalid syntax error:

{noformat}
cqlsh:foo update brongo SET boo = boo+1 where key='hi';
Invalid syntax at line 1, char 28
  update brongo SET boo = boo+1 where key='hi';
 ^
{noformat}

This is cause cqlsh's lexer doesn't know that + and - are valid operators in 
CQL. Don't worry, I'm not trying to make cqlsh be able to parse all CQL with 
exactness- it tries, in order to provide the best tab completion, but when it 
fails to parse it can still pass on CQL text to the server. This case is 
different because it's the lexer that can't understand the operators, before we 
even get to the parser. We do need a working and correct lexer, along with at 
least minimal parsing capability, in order to reliably split up statements, 
tell when the user is changing the keyspace, or SELECTing on a columnfamily 
with ASSUMEd types.

Also, the parser should be tweaked in a manner similar to CASSANDRA-3418.

--
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-3492) Compression option chunk_length is not converted into KB as it should

2011-11-14 Thread Pavel Yaskevich (Commented) (JIRA)


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

Pavel Yaskevich commented on CASSANDRA-3492:


+1

 Compression option chunk_length is not converted into KB as it should
 -

 Key: CASSANDRA-3492
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3492
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Critical
  Labels: compression
 Fix For: 1.0.3

 Attachments: 0001-Fix-chunk-length-option.patch




--
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-1391) Allow Concurrent Schema Migrations

2011-11-14 Thread Jonathan Ellis (Commented) (JIRA)


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

Jonathan Ellis commented on CASSANDRA-1391:
---

I'm enthusiastic about this approach for several reasons:

- ultimately we end up with simpler code with less special cases, although the 
migration (*cough*) from Avro-based schema will be a pain initially
- gets rid of Avro dependency!
- fixes CASSANDRA-2477 (SELECT * FROM keyspaces)


 Allow Concurrent Schema Migrations
 --

 Key: CASSANDRA-1391
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.7.0
Reporter: Stu Hood
Assignee: Pavel Yaskevich
 Fix For: 1.1

 Attachments: CASSANDRA-1391.patch


 CASSANDRA-1292 fixed multiple migrations started from the same node to 
 properly queue themselves, but it is still possible for migrations initiated 
 on different nodes to conflict and leave the cluster in a bad state. Since 
 the system_add/drop/rename methods are accessible directly from the client 
 API, they should be completely safe for concurrent use.
 It should be possible to allow for most types of concurrent migrations by 
 converting the UUID schema ID into a VersionVectorClock (as provided by 
 CASSANDRA-580).

--
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

svn commit: r1201913 - in /cassandra/branches/cassandra-1.0: CHANGES.txt src/java/org/apache/cassandra/db/CollationController.java

Author: jbellis
Date: Mon Nov 14 21:30:04 2011
New Revision: 1201913

URL: http://svn.apache.org/viewvc?rev=1201913view=rev
Log:
revert #2503
patch by jbellis; reviewed by slebresne for CASSANDRA-3491

Modified:
cassandra/branches/cassandra-1.0/CHANGES.txt

cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/db/CollationController.java

Modified: cassandra/branches/cassandra-1.0/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/CHANGES.txt?rev=1201913r1=1201912r2=1201913view=diff
==
--- cassandra/branches/cassandra-1.0/CHANGES.txt (original)
+++ cassandra/branches/cassandra-1.0/CHANGES.txt Mon Nov 14 21:30:04 2011
@@ -1,3 +1,7 @@
+1.0.4
+ * revert name-based query defragmentation aka CASSANDRA-2503 (CASSANDRA-3491)
+
+
 1.0.3
  * fix invalidate-related test failures (CASSANDRA-3437)
  * add next-gen cqlsh to bin/ (CASSANDRA-3188, 3131)

Modified: 
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/db/CollationController.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/db/CollationController.java?rev=1201913r1=1201912r2=1201913view=diff
==
--- 
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/db/CollationController.java
 (original)
+++ 
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/db/CollationController.java
 Mon Nov 14 21:30:04 2011
@@ -150,22 +150,7 @@ public class CollationController
 };
 ColumnFamily returnCF = container.cloneMeShallow();
 filter.collateColumns(returnCF, 
Collections.singletonList(toCollate), cfs.metadata.comparator, gcBefore);
-
-// hoist up the requested data into a more recent sstable
-if (sstablesIterated = cfs.getMinimumCompactionThreshold()  
cfs.getCompactionStrategy() instanceof SizeTieredCompactionStrategy)
-{
-RowMutation rm = new RowMutation(cfs.table.name, new 
Row(filter.key, returnCF.cloneMe()));
-try
-{
-rm.applyUnsafe(); // skipping commitlog is fine since 
we're just de-fragmenting existing data
-}
-catch (IOException e)
-{
-// log and allow the result to be returned
-logger.error(Error re-writing read results, e);
-}
-}
-
+
 // Caller is responsible for final removeDeletedCF.  This is 
important for cacheRow to work correctly:
 return returnCF;
 }

[jira] [Commented] (CASSANDRA-3493) cqlsh complains when you try to do UPDATE with counter columns

2011-11-14 Thread Jonathan Ellis (Commented) (JIRA)


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

Jonathan Ellis commented on CASSANDRA-3493:
---

+1

 cqlsh complains when you try to do UPDATE with counter columns
 --

 Key: CASSANDRA-3493
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3493
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
 Attachments: 3493.patch.txt


 trying to do a counter column UPDATE in cqlsh causes an Invalid syntax 
 error:
 {noformat}
 cqlsh:foo update brongo SET boo = boo+1 where key='hi';
 Invalid syntax at line 1, char 28
   update brongo SET boo = boo+1 where key='hi';
  ^
 {noformat}
 This is cause cqlsh's lexer doesn't know that + and - are valid operators in 
 CQL. Don't worry, I'm not trying to make cqlsh be able to parse all CQL with 
 exactness- it tries, in order to provide the best tab completion, but when it 
 fails to parse it can still pass on CQL text to the server. This case is 
 different because it's the lexer that can't understand the operators, before 
 we even get to the parser. We do need a working and correct lexer, along with 
 at least minimal parsing capability, in order to reliably split up 
 statements, tell when the user is changing the keyspace, or SELECTing on a 
 columnfamily with ASSUMEd types.
 Also, the parser should be tweaked in a manner similar to CASSANDRA-3418.

--
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-3491) Recursion bug in CollationController


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

Jonathan Ellis updated CASSANDRA-3491:
--

Affects Version/s: (was: 1.0.0)
   1.0.2

 Recursion bug in CollationController
 

 Key: CASSANDRA-3491
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3491
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.2
Reporter: T Jake Luciani
Assignee: Jonathan Ellis
 Fix For: 1.0.3

 Attachments: 3491.txt


 The following stack trace seems to indicate a recursion bug in 
 CollationController
 Where the stats collection mutation is itself having stats collected on and 
 so fourth
 http://pastebin.com/raw.php?i=35Rt7ryB

--
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

svn commit: r1201915 - in /cassandra/branches/cassandra-1.0/pylib/cqlshlib: cqlhandling.py pylexotron.py

Author: jbellis
Date: Mon Nov 14 21:31:30 2011
New Revision: 1201915

URL: http://svn.apache.org/viewvc?rev=1201915view=rev
Log:
update cqlsh lexer to handle counter increments
patch by Paul Cannon; reviewed by jbellis for CASSANDRA-3493

Modified:
cassandra/branches/cassandra-1.0/pylib/cqlshlib/cqlhandling.py
cassandra/branches/cassandra-1.0/pylib/cqlshlib/pylexotron.py

Modified: cassandra/branches/cassandra-1.0/pylib/cqlshlib/cqlhandling.py
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/pylib/cqlshlib/cqlhandling.py?rev=1201915r1=1201914r2=1201915view=diff
==
--- cassandra/branches/cassandra-1.0/pylib/cqlshlib/cqlhandling.py (original)
+++ cassandra/branches/cassandra-1.0/pylib/cqlshlib/cqlhandling.py Mon Nov 14 
21:31:30 2011
@@ -189,7 +189,7 @@ JUNK ::= /([ \t\r\f\v]+|(--|[/][/])[^\n\
 star ::=  * ;
 range ::= .. ;
 endtoken ::=  ; ;
-op ::=/[=,().]/ ;
+op ::=/[-+=,().]/ ;
 cmp ::=   /[]=?/ ;
 
 unclosedString  ::= /'([^']|'')*/ ;
@@ -267,7 +267,7 @@ syntax_rules += r'''
 selectWhereClause ::= relation (AND relation)*
   | keyname=colname IN ( term (, term)* )
   ;
-relation ::= [rel_lhs]=colname (= |  |  | = | =) term
+relation ::= [rel_lhs]=colname (= |  |  | = | =) colname
  ;
 whatToSelect ::= colname=colname (, colname=colname)*
  | (FIRST integer)? REVERSED? (rangestart=colname .. 
rangeend=colname
@@ -358,8 +358,8 @@ syntax_rules += r'''
 SET assignment ( , assignment )*
 WHERE updateWhereClause
 ;
-assignment ::= updatecol=colname = update_rhs=term
- ( counterop=( + | - ) term )?
+assignment ::= updatecol=colname = update_rhs=colname
+ ( counterop=( + | -? ) integer 
)?
;
 updateWhereClause ::= updatefiltercol=colname = term
   | updatefilterkey=colname filter_in=IN ( term ( 
, term )* )

Modified: cassandra/branches/cassandra-1.0/pylib/cqlshlib/pylexotron.py
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/pylib/cqlshlib/pylexotron.py?rev=1201915r1=1201914r2=1201915view=diff
==
--- cassandra/branches/cassandra-1.0/pylib/cqlshlib/pylexotron.py (original)
+++ cassandra/branches/cassandra-1.0/pylib/cqlshlib/pylexotron.py Mon Nov 14 
21:31:30 2011
@@ -88,6 +88,10 @@ class ParseContext:
 return self.__class__(self.ruleset, self.bindings, self.matched,
   self.remainder, newname)
 
+def __repr__(self):
+return '%s matched=%r remainder=%r prodname=%r' % 
(self.__class__.__name__, self.matched, self.remainder,
+ 
self.productionname)
+
 class matcher:
 def __init__(self, arg):
 self.arg = arg

svn commit: r1201917 - /cassandra/branches/cassandra-1.0/CHANGES.txt

Author: jbellis
Date: Mon Nov 14 21:32:24 2011
New Revision: 1201917

URL: http://svn.apache.org/viewvc?rev=1201917view=rev
Log:
update CHANGES

Modified:
cassandra/branches/cassandra-1.0/CHANGES.txt

Modified: cassandra/branches/cassandra-1.0/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/CHANGES.txt?rev=1201917r1=1201916r2=1201917view=diff
==
--- cassandra/branches/cassandra-1.0/CHANGES.txt (original)
+++ cassandra/branches/cassandra-1.0/CHANGES.txt Mon Nov 14 21:32:24 2011
@@ -1,10 +1,7 @@
-1.0.4
- * revert name-based query defragmentation aka CASSANDRA-2503 (CASSANDRA-3491)
-
-
 1.0.3
+ * revert name-based query defragmentation aka CASSANDRA-2503 (CASSANDRA-3491)
  * fix invalidate-related test failures (CASSANDRA-3437)
- * add next-gen cqlsh to bin/ (CASSANDRA-3188, 3131)
+ * add next-gen cqlsh to bin/ (CASSANDRA-3188, 3131, 3493)
  * (CQL) fix handling of rows with no columns (CASSANDRA-3424, 3473)
  * fix querying supercolumns by name returning only a subset of
subcolumns or old subcolumn versions (CASSANDRA-3446)

[jira] [Updated] (CASSANDRA-3493) cqlsh complains when you try to do UPDATE with counter columns

2011-11-14 Thread Mck SembWever (Issue Comment Edited) (JIRA)


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

Jonathan Ellis updated CASSANDRA-3493:
--

Affects Version/s: 1.0.3

 cqlsh complains when you try to do UPDATE with counter columns
 --

 Key: CASSANDRA-3493
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3493
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.0.3
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
 Fix For: 1.0.3

 Attachments: 3493.patch.txt


 trying to do a counter column UPDATE in cqlsh causes an Invalid syntax 
 error:
 {noformat}
 cqlsh:foo update brongo SET boo = boo+1 where key='hi';
 Invalid syntax at line 1, char 28
   update brongo SET boo = boo+1 where key='hi';
  ^
 {noformat}
 This is cause cqlsh's lexer doesn't know that + and - are valid operators in 
 CQL. Don't worry, I'm not trying to make cqlsh be able to parse all CQL with 
 exactness- it tries, in order to provide the best tab completion, but when it 
 fails to parse it can still pass on CQL text to the server. This case is 
 different because it's the lexer that can't understand the operators, before 
 we even get to the parser. We do need a working and correct lexer, along with 
 at least minimal parsing capability, in order to reliably split up 
 statements, tell when the user is changing the keyspace, or SELECTing on a 
 columnfamily with ASSUMEd types.
 Also, the parser should be tweaked in a manner similar to CASSANDRA-3418.

--
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-3492) Compression option chunk_length is not converted into KB as it should

2011-11-14 Thread Mck SembWever (Commented) (JIRA)


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

Mck SembWever commented on CASSANDRA-3492:
--

Does this involve a `nodetool compact/scrub` to repair existing sstables?

 Compression option chunk_length is not converted into KB as it should
 -

 Key: CASSANDRA-3492
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3492
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Critical
  Labels: compression
 Fix For: 1.0.3

 Attachments: 0001-Fix-chunk-length-option.patch




--
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] [Issue Comment Edited] (CASSANDRA-3492) Compression option chunk_length is not converted into KB as it should


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

Mck SembWever edited comment on CASSANDRA-3492 at 11/14/11 10:40 PM:
-

Does this involve a `nodetool compact/scrub` to repair existing sstables?
(the answer is yes).

  was (Author: michaelsembwever):
Does this involve a `nodetool compact/scrub` to repair existing sstables?
  
 Compression option chunk_length is not converted into KB as it should
 -

 Key: CASSANDRA-3492
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3492
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Critical
  Labels: compression
 Fix For: 1.0.3

 Attachments: 0001-Fix-chunk-length-option.patch




--
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

svn commit: r1201955 - in /cassandra/branches/cassandra-1.0/src: java/org/apache/cassandra/cli/CliClient.java resources/org/apache/cassandra/cli/CliHelp.yaml

Author: jbellis
Date: Mon Nov 14 22:50:50 2011
New Revision: 1201955

URL: http://svn.apache.org/viewvc?rev=1201955view=rev
Log:
move cli version into Welcome message
patch by Radim Kolar; reviewed by jbellis for CASSANDRA-3471

Modified:

cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/cli/CliClient.java

cassandra/branches/cassandra-1.0/src/resources/org/apache/cassandra/cli/CliHelp.yaml

Modified: 
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/cli/CliClient.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/cli/CliClient.java?rev=1201955r1=1201954r2=1201955view=diff
==
--- 
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/cli/CliClient.java
 (original)
+++ 
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/cli/CliClient.java
 Mon Nov 14 22:50:50 2011
@@ -188,8 +188,8 @@ public class CliClient
 
 public void printBanner()
 {
+sessionState.out.println(Welcome to Cassandra CLI version  + 
FBUtilities.getReleaseVersionString() + \n);
 sessionState.out.println(getHelp().banner);
-sessionState.out.println(Cassandra CLI version  + 
FBUtilities.getReleaseVersionString());
 }
 
 // Execute a CLI Statement 

Modified: 
cassandra/branches/cassandra-1.0/src/resources/org/apache/cassandra/cli/CliHelp.yaml
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/src/resources/org/apache/cassandra/cli/CliHelp.yaml?rev=1201955r1=1201954r2=1201955view=diff
==
--- 
cassandra/branches/cassandra-1.0/src/resources/org/apache/cassandra/cli/CliHelp.yaml
 (original)
+++ 
cassandra/branches/cassandra-1.0/src/resources/org/apache/cassandra/cli/CliHelp.yaml
 Mon Nov 14 22:50:50 2011
@@ -18,8 +18,6 @@
 # Help file for online commands in Yaml.
 
 banner: |
-Welcome to the Cassandra CLI.
-
 Type 'help;' or '?' for help.
 Type 'quit;' or 'exit;' to quit.

[jira] [Updated] (CASSANDRA-3471) Less verbose cassandra-cli startup


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

Jonathan Ellis updated CASSANDRA-3471:
--

Affects Version/s: (was: 1.0.2)

 Less verbose cassandra-cli startup
 --

 Key: CASSANDRA-3471
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3471
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Radim Kolar
Assignee: Radim Kolar
Priority: Trivial
 Fix For: 1.0.3

 Attachments: cassandra-cli.txt


 Move version number to welcome message, save 1 line on terminal.
 fbsd8:~ cassandra-cli
 Welcome to the Cassandra CLI */1.0.2*
 Type 'help;' or '?' for help.
 Type 'quit;' or 'exit;' to quit.
 -Cassandra CLI version 1.0.2-
 [default@unknown]

--
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-3488) Secondary indexes still around 3 months after deleting them

2011-11-14 Thread Jeremy Hanna (Commented) (JIRA)

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

Jeremy Hanna commented on CASSANDRA-3488:
-

The builds of secondary indexes have continued for a third day. Talking with
Brandon in IRC, he suggested I stop cassandra, move the index files to another
directory, and restart those nodes. I've done that and the secondary index
builds haven't come back yet. However, the last time they started after doing
a repair. Once things have settled with compactions, I'm going to try another
repair for each of the nodes. Things look hopeful for now that this is a
workaround.

Still, sounds like there is a bug in repair or something wrt bootstrapping a
node.

Secondary indexes still around 3 months after deleting them
---

Key: CASSANDRA-3488
URL: https://issues.apache.org/jira/browse/CASSANDRA-3488
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8.4
Reporter: Jeremy Hanna
Labels: secondary_index

We had an issue where we lost the data directories of two nodes. So we
re-bootstrapped those two nodes into the cluster and did the repair. During
the repair, secondary indexes were built as evidenced both in compactionstats
and in the filesystem. The problem is, we haven't had secondary indexes on
any of our column families for about 3 months now. The history there is that
we were on 0.7.6, deleted the secondary indexes on that version, and upgraded
to 0.8.4 a bit later. It bootstrapped and repaired last night and this
morning, but it's been a good 10 hours today of almost exclusively rebuilding
secondary indexes that shouldn't be there.

[jira] [Commented] (CASSANDRA-2967) Only bind JMX to the same IP address that is being used in Cassandra

2011-11-14 Thread Yuki Morishita (Commented) (JIRA)


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

Yuki Morishita commented on CASSANDRA-2967:
---

Few comments on the patch:

* If you leave -Dcom.sun.management.jmxremote.port=$JMX_PORT inside 
cassandra-env.sh, JVM still expose jmx to all interfaces.
* Applied patch to 1.0, removed above option from env.sh, and accessed jmx via 
nodetool, I get following error. Am I missing something?

{code}
# Inside patched cassandra.yaml, I set the following
jmx_listen_address: 127.0.0.2
jmx_registry_port: 7200
jmx_server_port: 7100

$ bin/nodetool -h 127.0.0.2 -p 7100 ring
Error connection to remote JMX agent!
java.io.IOException: Failed to retrieve RMIServer stub: 
javax.naming.CommunicationException [Root exception is 
java.rmi.NoSuchObjectException: no such object in table]
at 
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:340)
at 
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248)
at org.apache.cassandra.tools.NodeProbe.connect(NodeProbe.java:143)
at org.apache.cassandra.tools.NodeProbe.init(NodeProbe.java:113)
at org.apache.cassandra.tools.NodeCmd.main(NodeCmd.java:585)
Caused by: javax.naming.CommunicationException [Root exception is 
java.rmi.NoSuchObjectException: no such object in table]
at 
com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:101)
at 
com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:185)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at 
javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1888)
at 
javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1858)
at 
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257)
... 4 more
Caused by: java.rmi.NoSuchObjectException: no such object in table
at 
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
at 
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:359)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at 
com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:97)
... 9 more
{code}

 Only bind JMX to the same IP address that is being used in Cassandra
 

 Key: CASSANDRA-2967
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2967
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 0.8.2
Reporter: Joaquin Casares
Assignee: Alex Araujo
Priority: Minor
  Labels: lhf
 Attachments: cassandra-0.8-2967.txt, cassandra-1.0-2967-v2.txt, 
 cassandra-1.0-2967-v3.txt


 The setup is 5 nodes in each data center are all running on one physical test 
 machine and even though the repair was run against the correct IP the wrong 
 JMX port was used. As a result, instead of repairing all 5 nodes I was 
 repairing the same node 5 times.
 It would be nice if Cassandra's JMX would bind to only the IP address on 
 which its thrift/RPC services are listening on instead of binding to all IP's 
 on the box.

--
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

svn commit: r1202074 - /cassandra/trunk/src/java/org/apache/cassandra/utils/FastByteComparisons.java

Author: slebresne
Date: Tue Nov 15 07:15:58 2011
New Revision: 1202074

URL: http://svn.apache.org/viewvc?rev=1202074view=rev
Log:
Add missing file from previous commit

Added:
cassandra/trunk/src/java/org/apache/cassandra/utils/FastByteComparisons.java

Added: 
cassandra/trunk/src/java/org/apache/cassandra/utils/FastByteComparisons.java
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/utils/FastByteComparisons.java?rev=1202074view=auto
==
--- 
cassandra/trunk/src/java/org/apache/cassandra/utils/FastByteComparisons.java 
(added)
+++ 
cassandra/trunk/src/java/org/apache/cassandra/utils/FastByteComparisons.java 
Tue Nov 15 07:15:58 2011
@@ -0,0 +1,234 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.cassandra.utils;
+
+import java.lang.reflect.Field;
+import java.nio.ByteOrder;
+import java.security.AccessController;
+import java.security.PrivilegedAction;
+
+import sun.misc.Unsafe;
+
+import com.google.common.primitives.Longs;
+import com.google.common.primitives.UnsignedBytes;
+
+/**
+ * Utility code to do optimized byte-array comparison.
+ * This is borrowed and slightly modified from Guava's {@link UnsignedBytes}
+ * class to be able to compare arrays that start at non-zero offsets.
+ */
+abstract class FastByteComparisons {
+
+  /**
+   * Lexicographically compare two byte arrays.
+   */
+  public static int compareTo(byte[] b1, int s1, int l1, byte[] b2, int s2, 
int l2) {
+return LexicographicalComparerHolder.BEST_COMPARER.compareTo(
+b1, s1, l1, b2, s2, l2);
+  }
+
+  private interface ComparerT {
+abstract public int compareTo(T buffer1, int offset1, int length1,
+T buffer2, int offset2, int length2);
+  }
+
+  private static Comparerbyte[] lexicographicalComparerJavaImpl() {
+return LexicographicalComparerHolder.PureJavaComparer.INSTANCE;
+  }
+
+
+  /**
+   * Provides a lexicographical comparer implementation; either a Java
+   * implementation or a faster implementation based on {@link Unsafe}.
+   *
+   * pUses reflection to gracefully fall back to the Java implementation if
+   * {@code Unsafe} isn't available.
+   */
+  private static class LexicographicalComparerHolder {
+static final String UNSAFE_COMPARER_NAME =
+LexicographicalComparerHolder.class.getName() + $UnsafeComparer;
+
+static final Comparerbyte[] BEST_COMPARER = getBestComparer();
+/**
+ * Returns the Unsafe-using Comparer, or falls back to the pure-Java
+ * implementation if unable to do so.
+ */
+static Comparerbyte[] getBestComparer() {
+  try {
+Class? theClass = Class.forName(UNSAFE_COMPARER_NAME);
+
+// yes, UnsafeComparer does implement Comparerbyte[]
+@SuppressWarnings(unchecked)
+Comparerbyte[] comparer =
+  (Comparerbyte[]) theClass.getEnumConstants()[0];
+return comparer;
+  } catch (Throwable t) { // ensure we really catch *everything*
+return lexicographicalComparerJavaImpl();
+  }
+}
+
+private enum PureJavaComparer implements Comparerbyte[] {
+  INSTANCE;
+
+  @Override
+  public int compareTo(byte[] buffer1, int offset1, int length1,
+  byte[] buffer2, int offset2, int length2) {
+// Short circuit equal case
+if (buffer1 == buffer2 
+offset1 == offset2 
+length1 == length2) {
+  return 0;
+}
+int end1 = offset1 + length1;
+int end2 = offset2 + length2;
+for (int i = offset1, j = offset2; i  end1  j  end2; i++, j++) {
+  int a = (buffer1[i]  0xff);
+  int b = (buffer2[j]  0xff);
+  if (a != b) {
+return a - b;
+  }
+}
+return length1 - length2;
+  }
+}
+
+@SuppressWarnings(unused) // used via reflection
+private enum UnsafeComparer implements Comparerbyte[] {
+  INSTANCE;
+
+  static final Unsafe theUnsafe;
+
+  /** The offset to the first element in a byte array. */
+  static final int BYTE_ARRAY_BASE_OFFSET;
+
+  static {
+theUnsafe = (Unsafe) AccessController.doPrivileged(

svn commit: r1202080 - in /cassandra/branches/cassandra-1.0: CHANGES.txt src/java/org/apache/cassandra/io/compress/CompressionParameters.java

Author: slebresne
Date: Tue Nov 15 07:39:12 2011
New Revision: 1202080

URL: http://svn.apache.org/viewvc?rev=1202080view=rev
Log:
Fix bad handling of the chunk_length_kb compression option
patch by slebresne; reviewed by xedin for CASSANDRA-3492

Modified:
cassandra/branches/cassandra-1.0/CHANGES.txt

cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/io/compress/CompressionParameters.java

Modified: cassandra/branches/cassandra-1.0/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/CHANGES.txt?rev=1202080r1=1202079r2=1202080view=diff
==
--- cassandra/branches/cassandra-1.0/CHANGES.txt (original)
+++ cassandra/branches/cassandra-1.0/CHANGES.txt Tue Nov 15 07:39:12 2011
@@ -14,6 +14,7 @@
  * Fix race introduced by CASSANDRA-2503 (CASSANDRA-3482)
  * Fix incomplete deletion of delivered hints (CASSANDRA-3466)
  * Avoid reschuling compactions when no compaction was executed 
(CASSANDRA-3483)
+ * fix handling of the chunk_length_kb compression options (CASSANDRA-3492)
 Merged from 0.8:
  * Make counter shard merging thread safe (CASSANDRA-3178)
  * fix updating CF row_cache_provider (CASSANDRA-3414)

Modified: 
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/io/compress/CompressionParameters.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/io/compress/CompressionParameters.java?rev=1202080r1=1202079r2=1202080view=diff
==
--- 
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/io/compress/CompressionParameters.java
 (original)
+++ 
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/io/compress/CompressionParameters.java
 Tue Nov 15 07:39:12 2011
@@ -137,6 +137,9 @@ public class CompressionParameters
 return compressionOptions;
 }
 
+/**
+ * Parse the chunk length (in KB) and returns it as bytes.
+ */
 private static Integer parseChunkLength(String chLength) throws 
ConfigurationException
 {
 if (chLength == null)
@@ -144,7 +147,7 @@ public class CompressionParameters
 
 try
 {
-return Integer.parseInt(chLength);
+return 1024 * Integer.parseInt(chLength);
 }
 catch (NumberFormatException e)
 {

svn commit: r1202082 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/io/compress/