[jira] [Updated] (CASSANDRA-5051) Allow automatic cleanup after gc_grace

2013-03-13 Thread Vijay (JIRA)

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

Vijay updated CASSANDRA-5051:
-

Attachment: 0004-5051-additional-test-v4.patch

0004 Adds additional test cases to test the senario where compaction happens 
during range movement.

> Allow automatic cleanup after gc_grace
> --
>
> Key: CASSANDRA-5051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5051
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Core
>Reporter: Brandon Williams
>Assignee: Vijay
>  Labels: vnodes
> Fix For: 2.0
>
> Attachments: 0001-5051-v4.patch, 0001-5051-with-test-fixes.patch, 
> 0001-CASSANDRA-5051.patch, 0002-5051-remove-upgradesstable.patch, 
> 0002-5051-remove-upgradesstable-v4.patch, 0004-5051-additional-test-v4.patch, 
> 5051-v2.txt
>
>
> When using vnodes, after adding a new node you have to run cleanup on all the 
> machines, because you don't know which are affected and chances are it was 
> most if not all of them.  As an alternative to this intensive process, we 
> could allow cleanup during compaction if the data is older than gc_grace (or 
> perhaps some other time period since people tend to use gc_grace hacks to get 
> rid of tombstones.)

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


[Cassandra Wiki] Trivial Update of "RichardO9" by RichardO9

2013-03-13 Thread Apache Wiki
Dear Wiki user,

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

The "RichardO9" page has been changed by RichardO9:
http://wiki.apache.org/cassandra/RichardO9

New page:
College or university gently away from with appreciation for the past, Gu 
university or college, through the counselor as well as the lessons of their 
really difficult analysis, Relating to proficiently done specialized courses,, 
and additionally establish a good practice of truly serious research plus 
job!<>
. May well hard-working, good and additionally follow the theory ov associated 
with dependability in addition to integrity, that bravery towards challenge 
independently and also build their own individual prospective;<>
Earn a healthy people, the job determination, for you to very own target to 
perform those items you desire seriously to pressure;<>
Have a good pfvs temperament, prepared to speak to families, currently in 
organizations, are usually objectively point conversation with normal folks, 
powerful organization management proficiency together with a nature about 
synergy individuals, be capable of actively socialize to succeed in company 
aims;<>
Be a master at understanding, homework and additionally pragmatism, 
assiduously, own thorough attraction hpy as well as loaded information, good 
capacity adjust, dr to make sure you include in to a fresh particular field 
with a time frame, to adapt to her and your pet to carry out;<>
<>
Also visit my weblog - [[http://www.pingcheapbeatsbydre.com|dr dre beats]]


[jira] [Resolved] (CASSANDRA-5334) Don't announce migrations to pre-1.2 nodes

2013-03-13 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko resolved CASSANDRA-5334.
--

Resolution: Fixed

Committed, thanks.

> Don't announce migrations to pre-1.2 nodes
> --
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Aleksey Yeschenko
> Fix For: 1.2.3
>
> Attachments: 5334-extra.txt, 5334.patch, 5334-v2.txt, 
> cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


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

2013-03-13 Thread aleksey
Updated Branches:
  refs/heads/trunk fd1f5fd08 -> 346ac0c64


Merge branch 'cassandra-1.2' into trunk


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

Branch: refs/heads/trunk
Commit: 346ac0c64a85c459f7ec368a8024595ee2b4909b
Parents: fd1f5fd 8eca4ad
Author: Aleksey Yeschenko 
Authored: Thu Mar 14 03:10:55 2013 +0300
Committer: Aleksey Yeschenko 
Committed: Thu Mar 14 03:10:55 2013 +0300

--
 .../cassandra/db/MigrationRequestVerbHandler.java  |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/346ac0c6/src/java/org/apache/cassandra/db/MigrationRequestVerbHandler.java
--
diff --cc src/java/org/apache/cassandra/db/MigrationRequestVerbHandler.java
index e3152ad,1992c01..5a6625f
--- a/src/java/org/apache/cassandra/db/MigrationRequestVerbHandler.java
+++ b/src/java/org/apache/cassandra/db/MigrationRequestVerbHandler.java
@@@ -36,11 -37,19 +37,19 @@@ public class MigrationRequestVerbHandle
  {
  private static final Logger logger = 
LoggerFactory.getLogger(MigrationRequestVerbHandler.class);
  
 -public void doVerb(MessageIn message, String id)
 +public void doVerb(MessageIn message, int id)
  {
  logger.debug("Received migration request from {}.", message.from);
+ 
+ if (message.version < MessagingService.VERSION_12)
+ logger.debug("Returning empty response to the migration request 
from {} (version < 1.2).", message.from);
+ 
+ Collection schema = message.version < 
MessagingService.VERSION_12
+  ? Collections.EMPTY_SET
+  : SystemTable.serializeSchema();
+ 
  MessageOut> response = new 
MessageOut>(MessagingService.Verb.INTERNAL_RESPONSE,
-   
 SystemTable.serializeSchema(),
+   
 schema,

 MigrationManager.MigrationsSerializer.instance);
  MessagingService.instance().sendReply(response, id, message.from);
  }



[1/2] git commit: Return empty schema to pre-1.2 nodes' migration requests

2013-03-13 Thread aleksey
Return empty schema to pre-1.2 nodes' migration requests


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

Branch: refs/heads/trunk
Commit: 8eca4ad01a595c747ca6012f202ae836b76723c3
Parents: bb63238
Author: Aleksey Yeschenko 
Authored: Thu Mar 14 03:08:42 2013 +0300
Committer: Aleksey Yeschenko 
Committed: Thu Mar 14 03:08:42 2013 +0300

--
 .../cassandra/db/MigrationRequestVerbHandler.java  |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8eca4ad0/src/java/org/apache/cassandra/db/MigrationRequestVerbHandler.java
--
diff --git a/src/java/org/apache/cassandra/db/MigrationRequestVerbHandler.java 
b/src/java/org/apache/cassandra/db/MigrationRequestVerbHandler.java
index 97fd641..1992c01 100644
--- a/src/java/org/apache/cassandra/db/MigrationRequestVerbHandler.java
+++ b/src/java/org/apache/cassandra/db/MigrationRequestVerbHandler.java
@@ -18,6 +18,7 @@
 package org.apache.cassandra.db;
 
 import java.util.Collection;
+import java.util.Collections;
 
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
@@ -39,8 +40,16 @@ public class MigrationRequestVerbHandler implements 
IVerbHandler
 public void doVerb(MessageIn message, String id)
 {
 logger.debug("Received migration request from {}.", message.from);
+
+if (message.version < MessagingService.VERSION_12)
+logger.debug("Returning empty response to the migration request 
from {} (version < 1.2).", message.from);
+
+Collection schema = message.version < 
MessagingService.VERSION_12
+ ? Collections.EMPTY_SET
+ : SystemTable.serializeSchema();
+
 MessageOut> response = new 
MessageOut>(MessagingService.Verb.INTERNAL_RESPONSE,
-   
SystemTable.serializeSchema(),
+   
schema,

MigrationManager.MigrationsSerializer.instance);
 MessagingService.instance().sendReply(response, id, message.from);
 }



git commit: Return empty schema to pre-1.2 nodes' migration requests

2013-03-13 Thread aleksey
Updated Branches:
  refs/heads/cassandra-1.2 bb6323874 -> 8eca4ad01


Return empty schema to pre-1.2 nodes' migration requests


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

Branch: refs/heads/cassandra-1.2
Commit: 8eca4ad01a595c747ca6012f202ae836b76723c3
Parents: bb63238
Author: Aleksey Yeschenko 
Authored: Thu Mar 14 03:08:42 2013 +0300
Committer: Aleksey Yeschenko 
Committed: Thu Mar 14 03:08:42 2013 +0300

--
 .../cassandra/db/MigrationRequestVerbHandler.java  |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8eca4ad0/src/java/org/apache/cassandra/db/MigrationRequestVerbHandler.java
--
diff --git a/src/java/org/apache/cassandra/db/MigrationRequestVerbHandler.java 
b/src/java/org/apache/cassandra/db/MigrationRequestVerbHandler.java
index 97fd641..1992c01 100644
--- a/src/java/org/apache/cassandra/db/MigrationRequestVerbHandler.java
+++ b/src/java/org/apache/cassandra/db/MigrationRequestVerbHandler.java
@@ -18,6 +18,7 @@
 package org.apache.cassandra.db;
 
 import java.util.Collection;
+import java.util.Collections;
 
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
@@ -39,8 +40,16 @@ public class MigrationRequestVerbHandler implements 
IVerbHandler
 public void doVerb(MessageIn message, String id)
 {
 logger.debug("Received migration request from {}.", message.from);
+
+if (message.version < MessagingService.VERSION_12)
+logger.debug("Returning empty response to the migration request 
from {} (version < 1.2).", message.from);
+
+Collection schema = message.version < 
MessagingService.VERSION_12
+ ? Collections.EMPTY_SET
+ : SystemTable.serializeSchema();
+
 MessageOut> response = new 
MessageOut>(MessagingService.Verb.INTERNAL_RESPONSE,
-   
SystemTable.serializeSchema(),
+   
schema,

MigrationManager.MigrationsSerializer.instance);
 MessagingService.instance().sendReply(response, id, message.from);
 }



[jira] [Commented] (CASSANDRA-5334) Don't announce migrations to pre-1.2 nodes

2013-03-13 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601850#comment-13601850
 ] 

Jonathan Ellis commented on CASSANDRA-5334:
---

+1

> Don't announce migrations to pre-1.2 nodes
> --
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Aleksey Yeschenko
> Fix For: 1.2.3
>
> Attachments: 5334-extra.txt, 5334.patch, 5334-v2.txt, 
> cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Commented] (CASSANDRA-5321) Fix the dtest for upgrading a cluster

2013-03-13 Thread Ryan McGuire (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601791#comment-13601791
 ] 

Ryan McGuire commented on CASSANDRA-5321:
-

[upgrade_through_versions_test|https://github.com/riptano/cassandra-dtest/blob/master/upgrade_through_versions_test.py]
 now works, testing a 1.1 -> 1.2 migration as well as mixed-version testing.

> Fix the dtest for upgrading a cluster
> -
>
> Key: CASSANDRA-5321
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5321
> Project: Cassandra
>  Issue Type: Test
>Reporter: Ryan McGuire
>Assignee: Ryan McGuire
>
> Fix the upgrade test, have it perform a 1.1->1.2 upgrade (and forget 
> everything else), and perhaps do some things that would be valid when the 
> cluster is still mixed.

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


[jira] [Resolved] (CASSANDRA-5321) Fix the dtest for upgrading a cluster

2013-03-13 Thread Ryan McGuire (JIRA)

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

Ryan McGuire resolved CASSANDRA-5321.
-

Resolution: Fixed

> Fix the dtest for upgrading a cluster
> -
>
> Key: CASSANDRA-5321
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5321
> Project: Cassandra
>  Issue Type: Test
>Reporter: Ryan McGuire
>Assignee: Ryan McGuire
>
> Fix the upgrade test, have it perform a 1.1->1.2 upgrade (and forget 
> everything else), and perhaps do some things that would be valid when the 
> cluster is still mixed.

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


[Cassandra Wiki] Trivial Update of "GroverBar" by GroverBar

2013-03-13 Thread Apache Wiki
Dear Wiki user,

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

The "GroverBar" page has been changed by GroverBar:
http://wiki.apache.org/cassandra/GroverBar

New page:
With the help of competent understanding, u potent firm foundation, a potent 
apply opportunity, to get advanced their unique sights in neuro-scientific 
skilled.<>
<>
vygtrj Our honesty, lovely, diligent along with pragmatic, potent variety and 
additionally group opportunity, a feeling of cbpkjqouxy obligations in addition 
to a sense of the legal, really enjoy your b group, public-spirited 
undertakings, kn to adhere to all the standard connected with in general 
circumstances, ought to be prepared undergo the collective pastimes, include 
the anc motivation<>
<>
My web site [[http://www.dressesd.com|bridesmaids dresses]]


[jira] [Commented] (CASSANDRA-5334) Don't announce migrations to pre-1.2 nodes

2013-03-13 Thread Ryan McGuire (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601780#comment-13601780
 ] 

Ryan McGuire commented on CASSANDRA-5334:
-

Great, 5334-extra seems to clear up the intermittent failures. At least, I ran 
my dtest 10 times before and it failed half the time, and now I ran it 10 times 
with no failures.

> Don't announce migrations to pre-1.2 nodes
> --
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Aleksey Yeschenko
> Fix For: 1.2.3
>
> Attachments: 5334-extra.txt, 5334.patch, 5334-v2.txt, 
> cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[Cassandra Wiki] Trivial Update of "ConcettaD" by ConcettaD

2013-03-13 Thread Apache Wiki
Dear Wiki user,

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

The "ConcettaD" page has been changed by ConcettaD:
http://wiki.apache.org/cassandra/ConcettaD

New page:
Using experienced information, z robust firm foundation, c potent apply 
opportunity, to get in advance their unique opinions in the field of 
competent.<>
eqaldd Individuals honesty, cheerful, diligent as well as realistic, robust 
variety and also working together skill, feeling of atzjlpseso job as well as a 
sense the law, absolutely adore the actual n collective, public-spirited 
undertakings, ud to stick to any rationale for entire problem, should be able 
to undergo all the collective needs, hold the onr motivation<>
<>
Review my web blog ... [[http://www.ee.mut.ac.th/headphonesbeats.html|cheap 
beats headphones]]


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

2013-03-13 Thread aleksey
Updated Branches:
  refs/heads/trunk cfbcd98e0 -> fd1f5fd08


Merge branch 'cassandra-1.2' into trunk


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

Branch: refs/heads/trunk
Commit: fd1f5fd081e47612ea42305a4e9cdb94957a4c8c
Parents: cfbcd98 bb63238
Author: Aleksey Yeschenko 
Authored: Thu Mar 14 02:02:13 2013 +0300
Committer: Aleksey Yeschenko 
Committed: Thu Mar 14 02:02:13 2013 +0300

--

--




[3/4] git commit: Merge branch 'cassandra-1.1' into cassandra-1.2

2013-03-13 Thread aleksey
Merge branch 'cassandra-1.1' into cassandra-1.2


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

Branch: refs/heads/trunk
Commit: bb63238749171ebb4a6631f28c93246f3fd31743
Parents: 7cb8cf1 3346771
Author: Aleksey Yeschenko 
Authored: Thu Mar 14 01:58:16 2013 +0300
Committer: Aleksey Yeschenko 
Committed: Thu Mar 14 01:58:16 2013 +0300

--

--




[2/4] git commit: Don't request migrations from 1.2+ nodes

2013-03-13 Thread aleksey
Don't request migrations from 1.2+ nodes


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

Branch: refs/heads/trunk
Commit: 3346771a03fa334f2375fc585694bb768bb7b0d8
Parents: ba06e41
Author: Aleksey Yeschenko 
Authored: Thu Mar 14 01:54:00 2013 +0300
Committer: Aleksey Yeschenko 
Committed: Thu Mar 14 01:54:00 2013 +0300

--
 .../org/apache/cassandra/net/MessagingService.java |1 +
 .../apache/cassandra/service/MigrationManager.java |4 
 2 files changed, 5 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3346771a/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java 
b/src/java/org/apache/cassandra/net/MessagingService.java
index b605575..bfc97ba 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -70,6 +70,7 @@ public final class MessagingService implements 
MessagingServiceMBean
 public static final int VERSION_10  = 3;
 public static final int VERSION_11  = 4;
 public static final int VERSION_117 = 5;
+public static final int VERSION_12  = 6;
 
 public static final int version_ = VERSION_117;
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3346771a/src/java/org/apache/cassandra/service/MigrationManager.java
--
diff --git a/src/java/org/apache/cassandra/service/MigrationManager.java 
b/src/java/org/apache/cassandra/service/MigrationManager.java
index 49e0c93..bb9149f 100644
--- a/src/java/org/apache/cassandra/service/MigrationManager.java
+++ b/src/java/org/apache/cassandra/service/MigrationManager.java
@@ -110,6 +110,10 @@ public class MigrationManager implements 
IEndpointStateChangeSubscriber
 if (Gossiper.instance.getVersion(endpoint) < 
MessagingService.VERSION_117)
 return;
 
+// Don't request migrations from nodes with versions that are >= 1.2
+if (Gossiper.instance.getVersion(endpoint) >= 
MessagingService.VERSION_12)
+return;
+
 if (Schema.instance.getVersion().equals(theirVersion))
 return;
 



[1/4] git commit: add tmp flag to Descriptor hashcode patch by Boris Yen; reviewed by jbellis for CASSANDRA-4021

2013-03-13 Thread aleksey
add tmp flag to Descriptor hashcode
patch by Boris Yen; reviewed by jbellis for CASSANDRA-4021


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

Branch: refs/heads/trunk
Commit: ba06e4128b4cc66edb3e8e3ea02ce5cb5eae211c
Parents: a8c1043
Author: Jonathan Ellis 
Authored: Mon Mar 11 18:13:57 2013 -0500
Committer: Jonathan Ellis 
Committed: Mon Mar 11 18:13:57 2013 -0500

--
 CHANGES.txt|1 +
 .../apache/cassandra/io/sstable/Descriptor.java|4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ba06e412/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 72e6288..da81b66 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 1.1.11
+ * add tmp flag to Descriptor hashcode (CASSANDRA-4021)
  * fix logging of "Found table data in data directories" when only system 
tables
are present (CASSANDRA-5289)
  * cli: Add JMX authentication support (CASSANDRA-5080)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ba06e412/src/java/org/apache/cassandra/io/sstable/Descriptor.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/Descriptor.java 
b/src/java/org/apache/cassandra/io/sstable/Descriptor.java
index f4663b7..d2a9f46 100644
--- a/src/java/org/apache/cassandra/io/sstable/Descriptor.java
+++ b/src/java/org/apache/cassandra/io/sstable/Descriptor.java
@@ -100,7 +100,7 @@ public class Descriptor
 this.cfname = cfname;
 this.generation = generation;
 temporary = temp;
-hashCode = Objects.hashCode(directory, generation, ksname, cfname);
+hashCode = Objects.hashCode(directory, generation, ksname, cfname, 
temp);
 
 hasStringsInBloomFilter = version.compareTo("c") < 0;
 hasIntRowSize = version.compareTo("d") < 0;
@@ -266,7 +266,7 @@ public class Descriptor
 if (!(o instanceof Descriptor))
 return false;
 Descriptor that = (Descriptor)o;
-return that.directory.equals(this.directory) && that.generation == 
this.generation && that.ksname.equals(this.ksname) && 
that.cfname.equals(this.cfname);
+return that.directory.equals(this.directory) && that.generation == 
this.generation && that.ksname.equals(this.ksname) && 
that.cfname.equals(this.cfname) && that.temporary == this.temporary;
 }
 
 @Override



[2/3] git commit: Don't request migrations from 1.2+ nodes

2013-03-13 Thread aleksey
Don't request migrations from 1.2+ nodes


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

Branch: refs/heads/cassandra-1.2
Commit: 3346771a03fa334f2375fc585694bb768bb7b0d8
Parents: ba06e41
Author: Aleksey Yeschenko 
Authored: Thu Mar 14 01:54:00 2013 +0300
Committer: Aleksey Yeschenko 
Committed: Thu Mar 14 01:54:00 2013 +0300

--
 .../org/apache/cassandra/net/MessagingService.java |1 +
 .../apache/cassandra/service/MigrationManager.java |4 
 2 files changed, 5 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3346771a/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java 
b/src/java/org/apache/cassandra/net/MessagingService.java
index b605575..bfc97ba 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -70,6 +70,7 @@ public final class MessagingService implements 
MessagingServiceMBean
 public static final int VERSION_10  = 3;
 public static final int VERSION_11  = 4;
 public static final int VERSION_117 = 5;
+public static final int VERSION_12  = 6;
 
 public static final int version_ = VERSION_117;
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3346771a/src/java/org/apache/cassandra/service/MigrationManager.java
--
diff --git a/src/java/org/apache/cassandra/service/MigrationManager.java 
b/src/java/org/apache/cassandra/service/MigrationManager.java
index 49e0c93..bb9149f 100644
--- a/src/java/org/apache/cassandra/service/MigrationManager.java
+++ b/src/java/org/apache/cassandra/service/MigrationManager.java
@@ -110,6 +110,10 @@ public class MigrationManager implements 
IEndpointStateChangeSubscriber
 if (Gossiper.instance.getVersion(endpoint) < 
MessagingService.VERSION_117)
 return;
 
+// Don't request migrations from nodes with versions that are >= 1.2
+if (Gossiper.instance.getVersion(endpoint) >= 
MessagingService.VERSION_12)
+return;
+
 if (Schema.instance.getVersion().equals(theirVersion))
 return;
 



[1/3] git commit: add tmp flag to Descriptor hashcode patch by Boris Yen; reviewed by jbellis for CASSANDRA-4021

2013-03-13 Thread aleksey
add tmp flag to Descriptor hashcode
patch by Boris Yen; reviewed by jbellis for CASSANDRA-4021


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

Branch: refs/heads/cassandra-1.2
Commit: ba06e4128b4cc66edb3e8e3ea02ce5cb5eae211c
Parents: a8c1043
Author: Jonathan Ellis 
Authored: Mon Mar 11 18:13:57 2013 -0500
Committer: Jonathan Ellis 
Committed: Mon Mar 11 18:13:57 2013 -0500

--
 CHANGES.txt|1 +
 .../apache/cassandra/io/sstable/Descriptor.java|4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ba06e412/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 72e6288..da81b66 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 1.1.11
+ * add tmp flag to Descriptor hashcode (CASSANDRA-4021)
  * fix logging of "Found table data in data directories" when only system 
tables
are present (CASSANDRA-5289)
  * cli: Add JMX authentication support (CASSANDRA-5080)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ba06e412/src/java/org/apache/cassandra/io/sstable/Descriptor.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/Descriptor.java 
b/src/java/org/apache/cassandra/io/sstable/Descriptor.java
index f4663b7..d2a9f46 100644
--- a/src/java/org/apache/cassandra/io/sstable/Descriptor.java
+++ b/src/java/org/apache/cassandra/io/sstable/Descriptor.java
@@ -100,7 +100,7 @@ public class Descriptor
 this.cfname = cfname;
 this.generation = generation;
 temporary = temp;
-hashCode = Objects.hashCode(directory, generation, ksname, cfname);
+hashCode = Objects.hashCode(directory, generation, ksname, cfname, 
temp);
 
 hasStringsInBloomFilter = version.compareTo("c") < 0;
 hasIntRowSize = version.compareTo("d") < 0;
@@ -266,7 +266,7 @@ public class Descriptor
 if (!(o instanceof Descriptor))
 return false;
 Descriptor that = (Descriptor)o;
-return that.directory.equals(this.directory) && that.generation == 
this.generation && that.ksname.equals(this.ksname) && 
that.cfname.equals(this.cfname);
+return that.directory.equals(this.directory) && that.generation == 
this.generation && that.ksname.equals(this.ksname) && 
that.cfname.equals(this.cfname) && that.temporary == this.temporary;
 }
 
 @Override



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

2013-03-13 Thread aleksey
Updated Branches:
  refs/heads/cassandra-1.2 7cb8cf1df -> bb6323874


Merge branch 'cassandra-1.1' into cassandra-1.2


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

Branch: refs/heads/cassandra-1.2
Commit: bb63238749171ebb4a6631f28c93246f3fd31743
Parents: 7cb8cf1 3346771
Author: Aleksey Yeschenko 
Authored: Thu Mar 14 01:58:16 2013 +0300
Committer: Aleksey Yeschenko 
Committed: Thu Mar 14 01:58:16 2013 +0300

--

--




git commit: Don't request migrations from 1.2+ nodes

2013-03-13 Thread aleksey
Updated Branches:
  refs/heads/cassandra-1.1 ba06e4128 -> 3346771a0


Don't request migrations from 1.2+ nodes


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

Branch: refs/heads/cassandra-1.1
Commit: 3346771a03fa334f2375fc585694bb768bb7b0d8
Parents: ba06e41
Author: Aleksey Yeschenko 
Authored: Thu Mar 14 01:54:00 2013 +0300
Committer: Aleksey Yeschenko 
Committed: Thu Mar 14 01:54:00 2013 +0300

--
 .../org/apache/cassandra/net/MessagingService.java |1 +
 .../apache/cassandra/service/MigrationManager.java |4 
 2 files changed, 5 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3346771a/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java 
b/src/java/org/apache/cassandra/net/MessagingService.java
index b605575..bfc97ba 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -70,6 +70,7 @@ public final class MessagingService implements 
MessagingServiceMBean
 public static final int VERSION_10  = 3;
 public static final int VERSION_11  = 4;
 public static final int VERSION_117 = 5;
+public static final int VERSION_12  = 6;
 
 public static final int version_ = VERSION_117;
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3346771a/src/java/org/apache/cassandra/service/MigrationManager.java
--
diff --git a/src/java/org/apache/cassandra/service/MigrationManager.java 
b/src/java/org/apache/cassandra/service/MigrationManager.java
index 49e0c93..bb9149f 100644
--- a/src/java/org/apache/cassandra/service/MigrationManager.java
+++ b/src/java/org/apache/cassandra/service/MigrationManager.java
@@ -110,6 +110,10 @@ public class MigrationManager implements 
IEndpointStateChangeSubscriber
 if (Gossiper.instance.getVersion(endpoint) < 
MessagingService.VERSION_117)
 return;
 
+// Don't request migrations from nodes with versions that are >= 1.2
+if (Gossiper.instance.getVersion(endpoint) >= 
MessagingService.VERSION_12)
+return;
+
 if (Schema.instance.getVersion().equals(theirVersion))
 return;
 



[jira] [Updated] (CASSANDRA-5334) Don't announce migrations to pre-1.2 nodes

2013-03-13 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-5334:
-

Attachment: 5334-extra.txt

5334-extra patch modifies 1.2 MigrationRequestVerbHandler to return an empty 
collection to 1.1 nodes' schema requests.

> Don't announce migrations to pre-1.2 nodes
> --
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Aleksey Yeschenko
> Fix For: 1.2.3
>
> Attachments: 5334-extra.txt, 5334.patch, 5334-v2.txt, 
> cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[Cassandra Wiki] Trivial Update of "CharaMotl" by CharaMotl

2013-03-13 Thread Apache Wiki
Dear Wiki user,

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

The "CharaMotl" page has been changed by CharaMotl:
http://wiki.apache.org/cassandra/CharaMotl

New page:
I am content, secure, energetic, ijg nice, motivated; major and the reason for 
operate, project, may deal with challenges together with take a position work, 
dares towards innovate, the particular courage to fulfill the process, dares to 
attempt the responsibility; good work eagerness, and additionally dedication, 
increased exposure of friends working together zxgttuf together with a 
significant and even responsible function; formidable organizational ability 
plus fine power team assistance heart, full leaders nwyvgx and colleagues; and 
also develop their ability to your job together with the increase of online 
business go through, reu but also superior ones own self-confidence.<>
<>
<>
Feel free to visit my web blog [[http://www.dressesd.com|simple wedding 
dresses]]


[jira] [Commented] (CASSANDRA-5344) Make LCR less memory-abusive

2013-03-13 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601731#comment-13601731
 ] 

Jonathan Ellis commented on CASSANDRA-5344:
---

I took a stab at this in https://github.com/jbellis/cassandra/branches/5344, by 
moving the index update into ACR.write.  My plan was to then make the index 
build go directly to disk.  (BF would build in memory, but write to disk as 
soon as it was done.)

isEmpty stymied me, though -- it basically requires that we do a pass first 
that doesn't write anything, before we can do the real work.

Hoping [~jasobrown] or [~yukim] might have some ideas...

> Make LCR less memory-abusive
> 
>
> Key: CASSANDRA-5344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5344
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Jonathan Ellis
>Priority: Minor
>
> We've seen several reports of compaction causing GC pauses.  You would think 
> this would be the fault of PCR (which materializes the rows in memory) but 
> LCR seems to be more of a problem.
> I hypothesize that PCR mostly generates just young-gen garbage, but since LCR 
> keeps the BF and row index in-memory for a long time (from construction, 
> until after the row has been merged and written), it gets tenured and can 
> cause fragmentation or promotion failures.

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


[jira] [Created] (CASSANDRA-5344) Make LCR less memory-abusive

2013-03-13 Thread Jonathan Ellis (JIRA)
Jonathan Ellis created CASSANDRA-5344:
-

 Summary: Make LCR less memory-abusive
 Key: CASSANDRA-5344
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5344
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jonathan Ellis
Priority: Minor


We've seen several reports of compaction causing GC pauses.  You would think 
this would be the fault of PCR (which materializes the rows in memory) but LCR 
seems to be more of a problem.

I hypothesize that PCR mostly generates just young-gen garbage, but since LCR 
keeps the BF and row index in-memory for a long time (from construction, until 
after the row has been merged and written), it gets tenured and can cause 
fragmentation or promotion failures.

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


[jira] [Commented] (CASSANDRA-5334) Don't announce migrations to pre-1.2 nodes

2013-03-13 Thread Ryan McGuire (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601723#comment-13601723
 ] 

Ryan McGuire commented on CASSANDRA-5334:
-

giving this back to [~iamaleksey] to revisit "IIRC we already have code to 
prevent 1.1 from pulling the schema from 1.2 nodes."

> Don't announce migrations to pre-1.2 nodes
> --
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Aleksey Yeschenko
> Fix For: 1.2.3
>
> Attachments: 5334.patch, 5334-v2.txt, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Updated] (CASSANDRA-5334) Don't announce migrations to pre-1.2 nodes

2013-03-13 Thread Ryan McGuire (JIRA)

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

Ryan McGuire updated CASSANDRA-5334:


Assignee: Aleksey Yeschenko  (was: Ryan McGuire)

> Don't announce migrations to pre-1.2 nodes
> --
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Aleksey Yeschenko
> Fix For: 1.2.3
>
> Attachments: 5334.patch, 5334-v2.txt, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Comment Edited] (CASSANDRA-5334) Don't announce migrations to pre-1.2 nodes

2013-03-13 Thread Ryan McGuire (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601708#comment-13601708
 ] 

Ryan McGuire edited comment on CASSANDRA-5334 at 3/13/13 9:52 PM:
--

hmm, looks like the same NPE is coming from a different place than before:

{code}
ERROR [InternalResponseStage:1] 2013-03-13 17:41:01,836 
AbstractCassandraDaemon.java (line 135) Exception in thread 
Thread[InternalResponseStage:1,5,main]
java.lang.NullPointerException
at 
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
at 
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
at 
org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
at 
org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
at 
org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
at 
org.apache.cassandra.service.MigrationManager$MigrationTask$1.response(MigrationManager.java:453)
at 
org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:45)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
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)
{code}

  was (Author: enigmacurry):
hmm, looks like the same NPE is coming from a different place than before:

{code}
java.lang.NullPointerException
at 
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
at 
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
at 
org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
at 
org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
at 
org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
at 
org.apache.cassandra.service.MigrationManager$MigrationTask$1.response(MigrationManager.java:453)
at 
org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:45)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
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)
{code}
  
> Don't announce migrations to pre-1.2 nodes
> --
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Ryan McGuire
> Fix For: 1.2.3
>
> Attachments: 5334.patch, 5334-v2.txt, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache

[jira] [Commented] (CASSANDRA-5334) Don't announce migrations to pre-1.2 nodes

2013-03-13 Thread Ryan McGuire (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601708#comment-13601708
 ] 

Ryan McGuire commented on CASSANDRA-5334:
-

hmm, looks like the same NPE is coming from a different place than before:

{code}
java.lang.NullPointerException
at 
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
at 
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
at 
org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
at 
org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
at 
org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
at 
org.apache.cassandra.service.MigrationManager$MigrationTask$1.response(MigrationManager.java:453)
at 
org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:45)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
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)
{code}

> Don't announce migrations to pre-1.2 nodes
> --
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Ryan McGuire
> Fix For: 1.2.3
>
> Attachments: 5334.patch, 5334-v2.txt, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Reopened] (CASSANDRA-5334) Don't announce migrations to pre-1.2 nodes

2013-03-13 Thread Ryan McGuire (JIRA)

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

Ryan McGuire reopened CASSANDRA-5334:
-

  Assignee: Ryan McGuire  (was: Aleksey Yeschenko)

This is intermittently reoccurring for me, I'll assign it to me until I can 
come up with a dependable way to reproduce it.

> Don't announce migrations to pre-1.2 nodes
> --
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Ryan McGuire
> Fix For: 1.2.3
>
> Attachments: 5334.patch, 5334-v2.txt, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Commented] (CASSANDRA-5321) Fix the dtest for upgrading a cluster

2013-03-13 Thread Ryan McGuire (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601657#comment-13601657
 ] 

Ryan McGuire commented on CASSANDRA-5321:
-

CASSANDRA-5343 still leaves an AssertionError in the logs, so I need to handle 
that error explicitly in the test.

> Fix the dtest for upgrading a cluster
> -
>
> Key: CASSANDRA-5321
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5321
> Project: Cassandra
>  Issue Type: Test
>Reporter: Ryan McGuire
>Assignee: Ryan McGuire
>
> Fix the upgrade test, have it perform a 1.1->1.2 upgrade (and forget 
> everything else), and perhaps do some things that would be valid when the 
> cluster is still mixed.

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


[jira] [Resolved] (CASSANDRA-5343) 1.2 creates LZ4 compressed users table which is incompatible in mixed 1.2/1.1 cluster

2013-03-13 Thread Ryan McGuire (JIRA)

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

Ryan McGuire resolved CASSANDRA-5343.
-

Resolution: Fixed

fair enough, will do the exception handling in the test then.

> 1.2 creates LZ4 compressed users table which is incompatible in mixed 1.2/1.1 
> cluster 
> --
>
> Key: CASSANDRA-5343
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5343
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9, 1.2.2
>Reporter: Ryan McGuire
>
> * Start with a 3 node 1.1.9 cluster.
> * Take down node1, replace with 1.2.2.
> * Bring node1 back up, the cluster now has mixed versions.
> When node1 comes up, it tries to create a new keyspace: system_auth, which 
> looks like this:
> {code}
> CREATE KEYSPACE system_auth WITH replication = {
>   'class': 'SimpleStrategy',
>   'replication_factor': '1'
> };
> USE system_auth;
> CREATE TABLE users (
>   name text PRIMARY KEY,
>   super boolean
> ) WITH
>   bloom_filter_fp_chance=0.01 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=7776000 AND
>   read_repair_chance=0.10 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'LZ4Compressor'};
> {code}
> The system_auth.users table is using *LZ4Compressor* which does not work with 
> the 1.1.9 nodes. The 1.1.9 nodes return this error in the logs:
> {code}
> ERROR [MigrationStage:1] 2013-03-13 15:24:44,246 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.RuntimeException: 
> org.apache.cassandra.config.ConfigurationException: Could not create 
> Compression for type org.apache.cassandra.io.compress.LZ4Compressor
>   at 
> org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaData.java:1234)
>   at 
> org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1247)
>   at 
> org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:299)
>   at 
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:462)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:374)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> Caused by: org.apache.cassandra.config.ConfigurationException: Could not 
> create Compression for type org.apache.cassandra.io.compress.LZ4Compressor
>   at 
> org.apache.cassandra.io.compress.CompressionParameters.parseCompressorClass(CompressionParameters.java:141)
>   at 
> org.apache.cassandra.io.compress.CompressionParameters.(CompressionParameters.java:70)
>   at 
> org.apache.cassandra.io.compress.CompressionParameters.create(CompressionParameters.java:63)
>   at 
> org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaData.java:1224)
>   ... 13 more
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.cassandra.io.compress.LZ4Compressor
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:169)
>   at 
> org.apache.cassandra.io.compress.CompressionParameters.parseCompressorClass(CompressionParameters.java:137)
>   ... 16 more
> ERROR [ReadStage:33] 2013-03-13 15:24:54,319 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[ReadStage:33,5,main]
> java.lang.RuntimeException: java.lang.IllegalArgumentException: Unknown 
> table/cf pair (system_auth.users)
>   at 
> org.apache.cassandra.service.RangeSliceVerbHandler.doVerb(RangeSliceVerbHandler.java:71)
>  

[jira] [Commented] (CASSANDRA-5343) 1.2 creates LZ4 compressed users table which is incompatible in mixed 1.2/1.1 cluster

2013-03-13 Thread Aleksey Yeschenko (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601643#comment-13601643
 ] 

Aleksey Yeschenko commented on CASSANDRA-5343:
--

This AssertionError is harmless. I don't think it can/should be replaced with a 
warning, though. I'm afraid you'll have to find a way around it in dtests.

> 1.2 creates LZ4 compressed users table which is incompatible in mixed 1.2/1.1 
> cluster 
> --
>
> Key: CASSANDRA-5343
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5343
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9, 1.2.2
>Reporter: Ryan McGuire
>
> * Start with a 3 node 1.1.9 cluster.
> * Take down node1, replace with 1.2.2.
> * Bring node1 back up, the cluster now has mixed versions.
> When node1 comes up, it tries to create a new keyspace: system_auth, which 
> looks like this:
> {code}
> CREATE KEYSPACE system_auth WITH replication = {
>   'class': 'SimpleStrategy',
>   'replication_factor': '1'
> };
> USE system_auth;
> CREATE TABLE users (
>   name text PRIMARY KEY,
>   super boolean
> ) WITH
>   bloom_filter_fp_chance=0.01 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=7776000 AND
>   read_repair_chance=0.10 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'LZ4Compressor'};
> {code}
> The system_auth.users table is using *LZ4Compressor* which does not work with 
> the 1.1.9 nodes. The 1.1.9 nodes return this error in the logs:
> {code}
> ERROR [MigrationStage:1] 2013-03-13 15:24:44,246 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.RuntimeException: 
> org.apache.cassandra.config.ConfigurationException: Could not create 
> Compression for type org.apache.cassandra.io.compress.LZ4Compressor
>   at 
> org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaData.java:1234)
>   at 
> org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1247)
>   at 
> org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:299)
>   at 
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:462)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:374)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> Caused by: org.apache.cassandra.config.ConfigurationException: Could not 
> create Compression for type org.apache.cassandra.io.compress.LZ4Compressor
>   at 
> org.apache.cassandra.io.compress.CompressionParameters.parseCompressorClass(CompressionParameters.java:141)
>   at 
> org.apache.cassandra.io.compress.CompressionParameters.(CompressionParameters.java:70)
>   at 
> org.apache.cassandra.io.compress.CompressionParameters.create(CompressionParameters.java:63)
>   at 
> org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaData.java:1224)
>   ... 13 more
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.cassandra.io.compress.LZ4Compressor
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:169)
>   at 
> org.apache.cassandra.io.compress.CompressionParameters.parseCompressorClass(CompressionParameters.java:137)
>   ... 16 more
> ERROR [ReadStage:33] 2013-03-13 15:24:54,319 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[ReadStage:33,5,main]
> java.lang.RuntimeException: java.lang.IllegalArgumentException: Unknown 
> table/cf

[Cassandra Wiki] Trivial Update of "VerleneCh" by VerleneCh

2013-03-13 Thread Apache Wiki
Dear Wiki user,

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

The "VerleneCh" page has been changed by VerleneCh:
http://wiki.apache.org/cassandra/VerleneCh

New page:
Hiya, anyone.<>
<>
For sure, Now i'm:Nei Jvsqg<>
<>
Arrive in this article, I had been extremely excited, as I will with the tpqfr 
new situation, to search for completely new close friends.<>
<>
I am a understanding usually, normal look and feel, bricks-and-mortar common 
introverted trainees.<>
<>
My organization is peaceful, style, can be fairly yj fine, everyone is able to 
socialize by himself. I really like to study a manuscript.<>
<>
Goodness me, almost everyone consideration I had been many consumers the main 
advantages of the application, however i evdhw was in fact lazy, coughing, it 
is a set When i helpless oh. hek<>
<>
In future analysis txjgbso your life, our nation come together at the same 
time, analyze tricky, thus to their own personal long run along with lie down a 
good all round footing, we bust your tail mutually! Thanks for your time.<>
<>
Feel free to surf to my site: [[http://www.runchaneloutlet.com|chanel wallet]]


[jira] [Updated] (CASSANDRA-5334) Don't announce migrations to pre-1.2 nodes

2013-03-13 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-5334:
-

Summary: Don't announce migrations to pre-1.2 nodes  (was: 
NullPointerException in a mixed 1.1 / 1.2 cluster)

> Don't announce migrations to pre-1.2 nodes
> --
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: 5334.patch, 5334-v2.txt, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


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

2013-03-13 Thread aleksey
Updated Branches:
  refs/heads/trunk b88867ffa -> cfbcd98e0


Merge branch 'cassandra-1.2' into trunk


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

Branch: refs/heads/trunk
Commit: cfbcd98e0ab08317780b7c2598f99735fe0be191
Parents: b88867f 7cb8cf1
Author: Aleksey Yeschenko 
Authored: Thu Mar 14 00:03:46 2013 +0300
Committer: Aleksey Yeschenko 
Committed: Thu Mar 14 00:03:46 2013 +0300

--
 CHANGES.txt|1 +
 .../apache/cassandra/service/MigrationManager.java |4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/cfbcd98e/src/java/org/apache/cassandra/service/MigrationManager.java
--



[1/2] git commit: Don't announce migrations to pre-1.2 nodes

2013-03-13 Thread aleksey
Don't announce migrations to pre-1.2 nodes

patch by Aleksey Yeschenko; reviewed by Jonathan Ellis for
CASSANDRA-5334


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

Branch: refs/heads/trunk
Commit: 7cb8cf1df57a025d148bf1e5d84530e7c360fd24
Parents: c688125
Author: Aleksey Yeschenko 
Authored: Thu Mar 14 00:02:01 2013 +0300
Committer: Aleksey Yeschenko 
Committed: Thu Mar 14 00:02:01 2013 +0300

--
 CHANGES.txt|1 +
 .../apache/cassandra/service/MigrationManager.java |4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7cb8cf1d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6472974..a34b73e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -20,6 +20,7 @@
  * Fix repair -pr for vnodes (CASSANDRA-5329)
  * Relax CL for auth queries for non-default users (CASSANDRA-5310)
  * Fix AssertionError during repair (CASSANDRA-5245)
+ * Don't announce migrations to pre-1.2 nodes (CASSANDRA-5334)
 Merged from 1.1:
  * add tmp flag to Descriptor hashcode (CASSANDRA-4021)
  * fix logging of "Found table data in data directories" when only system 
tables

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7cb8cf1d/src/java/org/apache/cassandra/service/MigrationManager.java
--
diff --git a/src/java/org/apache/cassandra/service/MigrationManager.java 
b/src/java/org/apache/cassandra/service/MigrationManager.java
index ab1d6b2..7b9d64b 100644
--- a/src/java/org/apache/cassandra/service/MigrationManager.java
+++ b/src/java/org/apache/cassandra/service/MigrationManager.java
@@ -305,8 +305,8 @@ public class MigrationManager implements 
IEndpointStateChangeSubscriber
 if (endpoint.equals(FBUtilities.getBroadcastAddress()))
 continue; // we've delt with localhost already
 
-// don't send migrations to the nodes with the versions older than 
< 1.1
-if (MessagingService.instance().getVersion(endpoint) < 
MessagingService.VERSION_11)
+// don't send migrations to the nodes with the versions older than 
< 1.2
+if (MessagingService.instance().getVersion(endpoint) < 
MessagingService.VERSION_12)
 continue;
 
 pushSchemaMutation(endpoint, schema);



git commit: Don't announce migrations to pre-1.2 nodes

2013-03-13 Thread aleksey
Updated Branches:
  refs/heads/cassandra-1.2 c688125ba -> 7cb8cf1df


Don't announce migrations to pre-1.2 nodes

patch by Aleksey Yeschenko; reviewed by Jonathan Ellis for
CASSANDRA-5334


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

Branch: refs/heads/cassandra-1.2
Commit: 7cb8cf1df57a025d148bf1e5d84530e7c360fd24
Parents: c688125
Author: Aleksey Yeschenko 
Authored: Thu Mar 14 00:02:01 2013 +0300
Committer: Aleksey Yeschenko 
Committed: Thu Mar 14 00:02:01 2013 +0300

--
 CHANGES.txt|1 +
 .../apache/cassandra/service/MigrationManager.java |4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7cb8cf1d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6472974..a34b73e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -20,6 +20,7 @@
  * Fix repair -pr for vnodes (CASSANDRA-5329)
  * Relax CL for auth queries for non-default users (CASSANDRA-5310)
  * Fix AssertionError during repair (CASSANDRA-5245)
+ * Don't announce migrations to pre-1.2 nodes (CASSANDRA-5334)
 Merged from 1.1:
  * add tmp flag to Descriptor hashcode (CASSANDRA-4021)
  * fix logging of "Found table data in data directories" when only system 
tables

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7cb8cf1d/src/java/org/apache/cassandra/service/MigrationManager.java
--
diff --git a/src/java/org/apache/cassandra/service/MigrationManager.java 
b/src/java/org/apache/cassandra/service/MigrationManager.java
index ab1d6b2..7b9d64b 100644
--- a/src/java/org/apache/cassandra/service/MigrationManager.java
+++ b/src/java/org/apache/cassandra/service/MigrationManager.java
@@ -305,8 +305,8 @@ public class MigrationManager implements 
IEndpointStateChangeSubscriber
 if (endpoint.equals(FBUtilities.getBroadcastAddress()))
 continue; // we've delt with localhost already
 
-// don't send migrations to the nodes with the versions older than 
< 1.1
-if (MessagingService.instance().getVersion(endpoint) < 
MessagingService.VERSION_11)
+// don't send migrations to the nodes with the versions older than 
< 1.2
+if (MessagingService.instance().getVersion(endpoint) < 
MessagingService.VERSION_12)
 continue;
 
 pushSchemaMutation(endpoint, schema);



[jira] [Comment Edited] (CASSANDRA-5343) 1.2 creates LZ4 compressed users table which is incompatible in mixed 1.2/1.1 cluster

2013-03-13 Thread Ryan McGuire (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601629#comment-13601629
 ] 

Ryan McGuire edited comment on CASSANDRA-5343 at 3/13/13 8:59 PM:
--

[~iamaleksey]'s proposed patch for CASSANDRA-5334 mostly fixes this, but this 
is still sitting in the 1.1.9 nodes log:

{code}
ERROR [ReadStage:33] 2013-03-13 16:50:47,202 AbstractCassandraDaemon.java (line 
135) Exception in thread Thread[ReadStage:33,5,main]
java.lang.AssertionError: Unknown keyspace system_auth
at org.apache.cassandra.db.Table.(Table.java:287)
at org.apache.cassandra.db.Table.open(Table.java:119)
at org.apache.cassandra.db.Table.open(Table.java:97)
at 
org.apache.cassandra.service.RangeSliceVerbHandler.executeLocally(RangeSliceVerbHandler.java:44)
at 
org.apache.cassandra.service.RangeSliceVerbHandler.doVerb(RangeSliceVerbHandler.java:63)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
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)
{code}

AssertionError doesn't sound that bad to me, but it would be nice if this were 
a warning instead so as not to make dtests fail.

  was (Author: enigmacurry):
[~iamaleksey]'s proposed patch for CASSANDRA-5343 mostly fixes this, but 
this is still sitting in the 1.1.9 nodes log:

{code}
ERROR [ReadStage:33] 2013-03-13 16:50:47,202 AbstractCassandraDaemon.java (line 
135) Exception in thread Thread[ReadStage:33,5,main]
java.lang.AssertionError: Unknown keyspace system_auth
at org.apache.cassandra.db.Table.(Table.java:287)
at org.apache.cassandra.db.Table.open(Table.java:119)
at org.apache.cassandra.db.Table.open(Table.java:97)
at 
org.apache.cassandra.service.RangeSliceVerbHandler.executeLocally(RangeSliceVerbHandler.java:44)
at 
org.apache.cassandra.service.RangeSliceVerbHandler.doVerb(RangeSliceVerbHandler.java:63)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
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)
{code}

AssertionError doesn't sound that bad to me, but it would be nice if this were 
a warning instead so as not to make dtests fail.
  
> 1.2 creates LZ4 compressed users table which is incompatible in mixed 1.2/1.1 
> cluster 
> --
>
> Key: CASSANDRA-5343
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5343
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9, 1.2.2
>Reporter: Ryan McGuire
>
> * Start with a 3 node 1.1.9 cluster.
> * Take down node1, replace with 1.2.2.
> * Bring node1 back up, the cluster now has mixed versions.
> When node1 comes up, it tries to create a new keyspace: system_auth, which 
> looks like this:
> {code}
> CREATE KEYSPACE system_auth WITH replication = {
>   'class': 'SimpleStrategy',
>   'replication_factor': '1'
> };
> USE system_auth;
> CREATE TABLE users (
>   name text PRIMARY KEY,
>   super boolean
> ) WITH
>   bloom_filter_fp_chance=0.01 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=7776000 AND
>   read_repair_chance=0.10 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'LZ4Compressor'};
> {code}
> The system_auth.users table is using *LZ4Compressor* which does not work with 
> the 1.1.9 nodes. The 1.1.9 nodes return this error in the logs:
> {code}
> ERROR [MigrationStage:1] 2013-03-13 15:24:44,246 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.RuntimeException: 
> org.apache.cassandra.config.ConfigurationException: Could not create 
> Compression for type org.apache.cassandra.io.compress.LZ4Compressor
>   at 
> org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaData.java:1234)
>   at 
> org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1247)
>   at 
> org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:299)
>   at 
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:462)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:374)
>   at 
> org.apache.cassandra.db.DefsTable.merg

[jira] [Commented] (CASSANDRA-5343) 1.2 creates LZ4 compressed users table which is incompatible in mixed 1.2/1.1 cluster

2013-03-13 Thread Ryan McGuire (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601629#comment-13601629
 ] 

Ryan McGuire commented on CASSANDRA-5343:
-

[~iamaleksey]'s proposed patch for CASSANDRA-5343 mostly fixes this, but this 
is still sitting in the 1.1.9 nodes log:

{code}
ERROR [ReadStage:33] 2013-03-13 16:50:47,202 AbstractCassandraDaemon.java (line 
135) Exception in thread Thread[ReadStage:33,5,main]
java.lang.AssertionError: Unknown keyspace system_auth
at org.apache.cassandra.db.Table.(Table.java:287)
at org.apache.cassandra.db.Table.open(Table.java:119)
at org.apache.cassandra.db.Table.open(Table.java:97)
at 
org.apache.cassandra.service.RangeSliceVerbHandler.executeLocally(RangeSliceVerbHandler.java:44)
at 
org.apache.cassandra.service.RangeSliceVerbHandler.doVerb(RangeSliceVerbHandler.java:63)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
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)
{code}

AssertionError doesn't sound that bad to me, but it would be nice if this were 
a warning instead so as not to make dtests fail.

> 1.2 creates LZ4 compressed users table which is incompatible in mixed 1.2/1.1 
> cluster 
> --
>
> Key: CASSANDRA-5343
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5343
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9, 1.2.2
>Reporter: Ryan McGuire
>
> * Start with a 3 node 1.1.9 cluster.
> * Take down node1, replace with 1.2.2.
> * Bring node1 back up, the cluster now has mixed versions.
> When node1 comes up, it tries to create a new keyspace: system_auth, which 
> looks like this:
> {code}
> CREATE KEYSPACE system_auth WITH replication = {
>   'class': 'SimpleStrategy',
>   'replication_factor': '1'
> };
> USE system_auth;
> CREATE TABLE users (
>   name text PRIMARY KEY,
>   super boolean
> ) WITH
>   bloom_filter_fp_chance=0.01 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=7776000 AND
>   read_repair_chance=0.10 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'LZ4Compressor'};
> {code}
> The system_auth.users table is using *LZ4Compressor* which does not work with 
> the 1.1.9 nodes. The 1.1.9 nodes return this error in the logs:
> {code}
> ERROR [MigrationStage:1] 2013-03-13 15:24:44,246 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.RuntimeException: 
> org.apache.cassandra.config.ConfigurationException: Could not create 
> Compression for type org.apache.cassandra.io.compress.LZ4Compressor
>   at 
> org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaData.java:1234)
>   at 
> org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1247)
>   at 
> org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:299)
>   at 
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:462)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:374)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> Caused by: org.apache.cassandra.config.ConfigurationException: Could not 
> create Compression for type org.apache.cassandra.io.compress.LZ4Compressor
>   at 
> org.apache.cassandra.io.compress.CompressionParameters.parseCompressorClass(CompressionParameters.java:141)
>   at 
> org.apache.cassandra.io.compress.CompressionParameters.(CompressionParameters.java:70)
>   at 
> org.apache.cassandra.io.compress.CompressionParameters.create(CompressionParameters.java:63)
>   at 
> org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaDat

[jira] [Commented] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Ryan McGuire (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601624#comment-13601624
 ] 

Ryan McGuire commented on CASSANDRA-5334:
-

Tested [~iamaleksey]'s patch fixes all NPEs and resolves this issue. It mostly 
fixes CASSANDRA-5343, too, but there is a lingering AsseritionError.

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: 5334.patch, 5334-v2.txt, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Updated] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-5334:
-

Attachment: 5334-v2.txt

v2 prevents 1.2 nodes from pushing migrations to 1.1 nodes.

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: 5334.patch, 5334-v2.txt, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Updated] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-5334:
-

Attachment: (was: 5334.txt)

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: 5334.patch, 5334-v2.txt, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Updated] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-5334:
-

Attachment: 5334.txt

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: 5334.patch, 5334.txt, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[Cassandra Wiki] Trivial Update of "TeresaWIC" by TeresaWIC

2013-03-13 Thread Apache Wiki
Dear Wiki user,

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

The "TeresaWIC" page has been changed by TeresaWIC:
http://wiki.apache.org/cassandra/TeresaWIC

New page:
Not much to say about me at all.<>
Hurrey Im here and a member of this site.<>
<>
I really hope I'm useful in one way here.<>
<>
my webpage :: 
[[http://www.nursingbraexpress.com/hooray-huge-step-make-breastfeeding-norm-healthcare|baby
 sling]]


[jira] [Commented] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601580#comment-13601580
 ] 

Jonathan Ellis commented on CASSANDRA-5334:
---

That sounds simplest to me, and should fix CASSANDRA-5343.  (IIRC we already 
have code to prevent 1.1 from pulling the schema from 1.2 nodes, so we just 
need to stop 1.2 from pushing it as well.)

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: 5334.patch, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Commented] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Aleksey Yeschenko (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601570#comment-13601570
 ] 

Aleksey Yeschenko commented on CASSANDRA-5334:
--

Should MigrationManager.announce() send migrations to 1.1 nodes at all?

{noformat}
// don't send migrations to the nodes with the versions older than 
< 1.1
if (MessagingService.instance().getVersion(endpoint) < 
MessagingService.VERSION_11)
continue;
{noformat}

Should change it to '< MessagingService.VERSION_12'. Any downsides to it?

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: 5334.patch, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Comment Edited] (CASSANDRA-5228) Track maximum ttl and use to expire entire sstables

2013-03-13 Thread Marcus Eriksson (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601565#comment-13601565
 ] 

Marcus Eriksson edited comment on CASSANDRA-5228 at 3/13/13 8:01 PM:
-

tries to drop sstables in CompactionTask#runWith

also checks if it is possible to drop sstable in 
AbstractCompactionStrategy#worthDroppingTombstones

still applies on top of v3 of the max deletiontime patch

  was (Author: krummas):
tries to drop sstables in CompactionTask#runWith

also checks if it is possible to drop sstable in 
AbstractCompactionStrategy#worthDroppingTombstones
  
> Track maximum ttl and use to expire entire sstables
> ---
>
> Key: CASSANDRA-5228
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5228
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jonathan Ellis
>Assignee: Marcus Eriksson
>Priority: Minor
> Attachments: 0001-track-max-local-deletiontime-v2.patch, 
> 0001-track-max-local-deletiontime-v3.patch, 0001-track-max-ttl-v1.patch, 
> 0002-CASSANDRA-5228-add-a-nodetool-command-that-drops-ent.patch, 
> 0002-CASSANDRA-5228-drop-entire-sstables-if-all-tombstone-v2.patch
>
>
> It would be nice to be able to throw away entire sstables worth of data when 
> we know that it's all expired.

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


[jira] [Updated] (CASSANDRA-5228) Track maximum ttl and use to expire entire sstables

2013-03-13 Thread Marcus Eriksson (JIRA)

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

Marcus Eriksson updated CASSANDRA-5228:
---

Attachment: 
0002-CASSANDRA-5228-drop-entire-sstables-if-all-tombstone-v2.patch

tries to drop sstables in CompactionTask#runWith

also checks if it is possible to drop sstable in 
AbstractCompactionStrategy#worthDroppingTombstones

> Track maximum ttl and use to expire entire sstables
> ---
>
> Key: CASSANDRA-5228
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5228
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jonathan Ellis
>Assignee: Marcus Eriksson
>Priority: Minor
> Attachments: 0001-track-max-local-deletiontime-v2.patch, 
> 0001-track-max-local-deletiontime-v3.patch, 0001-track-max-ttl-v1.patch, 
> 0002-CASSANDRA-5228-add-a-nodetool-command-that-drops-ent.patch, 
> 0002-CASSANDRA-5228-drop-entire-sstables-if-all-tombstone-v2.patch
>
>
> It would be nice to be able to throw away entire sstables worth of data when 
> we know that it's all expired.

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


[jira] [Updated] (CASSANDRA-5343) 1.2 creates LZ4 compressed users table which is incompatible in mixed 1.2/1.1 cluster

2013-03-13 Thread Ryan McGuire (JIRA)

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

Ryan McGuire updated CASSANDRA-5343:


Affects Version/s: 1.2.2

> 1.2 creates LZ4 compressed users table which is incompatible in mixed 1.2/1.1 
> cluster 
> --
>
> Key: CASSANDRA-5343
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5343
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9, 1.2.2
>Reporter: Ryan McGuire
>
> * Start with a 3 node 1.1.9 cluster.
> * Take down node1, replace with 1.2.2.
> * Bring node1 back up, the cluster now has mixed versions.
> When node1 comes up, it tries to create a new keyspace: system_auth, which 
> looks like this:
> {code}
> CREATE KEYSPACE system_auth WITH replication = {
>   'class': 'SimpleStrategy',
>   'replication_factor': '1'
> };
> USE system_auth;
> CREATE TABLE users (
>   name text PRIMARY KEY,
>   super boolean
> ) WITH
>   bloom_filter_fp_chance=0.01 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=7776000 AND
>   read_repair_chance=0.10 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'LZ4Compressor'};
> {code}
> The system_auth.users table is using *LZ4Compressor* which does not work with 
> the 1.1.9 nodes. The 1.1.9 nodes return this error in the logs:
> {code}
> ERROR [MigrationStage:1] 2013-03-13 15:24:44,246 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.RuntimeException: 
> org.apache.cassandra.config.ConfigurationException: Could not create 
> Compression for type org.apache.cassandra.io.compress.LZ4Compressor
>   at 
> org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaData.java:1234)
>   at 
> org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1247)
>   at 
> org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:299)
>   at 
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:462)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:374)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> Caused by: org.apache.cassandra.config.ConfigurationException: Could not 
> create Compression for type org.apache.cassandra.io.compress.LZ4Compressor
>   at 
> org.apache.cassandra.io.compress.CompressionParameters.parseCompressorClass(CompressionParameters.java:141)
>   at 
> org.apache.cassandra.io.compress.CompressionParameters.(CompressionParameters.java:70)
>   at 
> org.apache.cassandra.io.compress.CompressionParameters.create(CompressionParameters.java:63)
>   at 
> org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaData.java:1224)
>   ... 13 more
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.cassandra.io.compress.LZ4Compressor
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:169)
>   at 
> org.apache.cassandra.io.compress.CompressionParameters.parseCompressorClass(CompressionParameters.java:137)
>   ... 16 more
> ERROR [ReadStage:33] 2013-03-13 15:24:54,319 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[ReadStage:33,5,main]
> java.lang.RuntimeException: java.lang.IllegalArgumentException: Unknown 
> table/cf pair (system_auth.users)
>   at 
> org.apache.cassandra.service.RangeSliceVerbHandler.doVerb(RangeSliceVerbHandler.java:71)
>   at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliver

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

2013-03-13 Thread Matthew Goodson (JIRA)

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

Matthew Goodson commented on CASSANDRA-4687:


Hi Dan, I've only got one keyspace (other than system) and we never drop it. I 
occasionally create new CF's but that's about it. It just runs. No row caching 
is enabled just the key cache which was set to the default 20. It was prob 
me that you saw report it on IRC and there was another guy who said that he 
just started seeing it as well with version 1.1.?. It has just started 
randomly, I don't think I have touched the cluster for about a month. I think 
it might be time to replace the node and see if that makes the problem go away

> Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
> ---
>
> Key: CASSANDRA-4687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single 
> node cluster
>Reporter: Leonid Shalupov
>Assignee: Pavel Yaskevich
> Fix For: 1.2.3
>
> Attachments: 4687-debugging.txt
>
>
> Under heavy write load sometimes cassandra fails with assertion error.
> git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
> works fine if global key/row caches disabled in code.
> {quote}
> java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in 
> /var/lib/cassandra/data/...-he-1-Data.db
>   at 
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.(SSTableSliceIterator.java:60)
>   at 
> org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
>   at 
> org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
>   at 
> org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
>   at 
> org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
>   at org.apache.cassandra.db.Table.getRow(Table.java:378)
>   at 
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
>   at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:662)
> {quote}

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


[jira] [Created] (CASSANDRA-5343) 1.2 creates LZ4 compressed users table which is incompatible in mixed 1.2/1.1 cluster

2013-03-13 Thread Ryan McGuire (JIRA)
Ryan McGuire created CASSANDRA-5343:
---

 Summary: 1.2 creates LZ4 compressed users table which is 
incompatible in mixed 1.2/1.1 cluster 
 Key: CASSANDRA-5343
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5343
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.9
Reporter: Ryan McGuire


* Start with a 3 node 1.1.9 cluster.
* Take down node1, replace with 1.2.2.
* Bring node1 back up, the cluster now has mixed versions.

When node1 comes up, it tries to create a new keyspace: system_auth, which 
looks like this:

{code}
CREATE KEYSPACE system_auth WITH replication = {
  'class': 'SimpleStrategy',
  'replication_factor': '1'
};

USE system_auth;

CREATE TABLE users (
  name text PRIMARY KEY,
  super boolean
) WITH
  bloom_filter_fp_chance=0.01 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.00 AND
  gc_grace_seconds=7776000 AND
  read_repair_chance=0.10 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  compaction={'class': 'SizeTieredCompactionStrategy'} AND
  compression={'sstable_compression': 'LZ4Compressor'};
{code}

The system_auth.users table is using *LZ4Compressor* which does not work with 
the 1.1.9 nodes. The 1.1.9 nodes return this error in the logs:

{code}
ERROR [MigrationStage:1] 2013-03-13 15:24:44,246 AbstractCassandraDaemon.java 
(line 135) Exception in thread Thread[MigrationStage:1,5,main]
java.lang.RuntimeException: org.apache.cassandra.config.ConfigurationException: 
Could not create Compression for type 
org.apache.cassandra.io.compress.LZ4Compressor
at 
org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaData.java:1234)
at 
org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1247)
at 
org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:299)
at 
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:462)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:374)
at 
org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
at 
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
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)
Caused by: org.apache.cassandra.config.ConfigurationException: Could not create 
Compression for type org.apache.cassandra.io.compress.LZ4Compressor
at 
org.apache.cassandra.io.compress.CompressionParameters.parseCompressorClass(CompressionParameters.java:141)
at 
org.apache.cassandra.io.compress.CompressionParameters.(CompressionParameters.java:70)
at 
org.apache.cassandra.io.compress.CompressionParameters.create(CompressionParameters.java:63)
at 
org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaData.java:1224)
... 13 more
Caused by: java.lang.ClassNotFoundException: 
org.apache.cassandra.io.compress.LZ4Compressor
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at 
org.apache.cassandra.io.compress.CompressionParameters.parseCompressorClass(CompressionParameters.java:137)
... 16 more
ERROR [ReadStage:33] 2013-03-13 15:24:54,319 AbstractCassandraDaemon.java (line 
135) Exception in thread Thread[ReadStage:33,5,main]
java.lang.RuntimeException: java.lang.IllegalArgumentException: Unknown 
table/cf pair (system_auth.users)
at 
org.apache.cassandra.service.RangeSliceVerbHandler.doVerb(RangeSliceVerbHandler.java:71)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
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.lang.IllegalArgumentException: Unknown table/cf pair 
(system_auth.users)
at org.apac

[jira] [Updated] (CASSANDRA-5343) 1.2 creates LZ4 compressed users table which is incompatible in mixed 1.2/1.1 cluster

2013-03-13 Thread Ryan McGuire (JIRA)

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

Ryan McGuire updated CASSANDRA-5343:


Description: 
* Start with a 3 node 1.1.9 cluster.
* Take down node1, replace with 1.2.2.
* Bring node1 back up, the cluster now has mixed versions.

When node1 comes up, it tries to create a new keyspace: system_auth, which 
looks like this:

{code}
CREATE KEYSPACE system_auth WITH replication = {
  'class': 'SimpleStrategy',
  'replication_factor': '1'
};

USE system_auth;

CREATE TABLE users (
  name text PRIMARY KEY,
  super boolean
) WITH
  bloom_filter_fp_chance=0.01 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.00 AND
  gc_grace_seconds=7776000 AND
  read_repair_chance=0.10 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  compaction={'class': 'SizeTieredCompactionStrategy'} AND
  compression={'sstable_compression': 'LZ4Compressor'};
{code}

The system_auth.users table is using *LZ4Compressor* which does not work with 
the 1.1.9 nodes. The 1.1.9 nodes return this error in the logs:

{code}
ERROR [MigrationStage:1] 2013-03-13 15:24:44,246 AbstractCassandraDaemon.java 
(line 135) Exception in thread Thread[MigrationStage:1,5,main]
java.lang.RuntimeException: org.apache.cassandra.config.ConfigurationException: 
Could not create Compression for type 
org.apache.cassandra.io.compress.LZ4Compressor
at 
org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaData.java:1234)
at 
org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1247)
at 
org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:299)
at 
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:462)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:374)
at 
org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
at 
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
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)
Caused by: org.apache.cassandra.config.ConfigurationException: Could not create 
Compression for type org.apache.cassandra.io.compress.LZ4Compressor
at 
org.apache.cassandra.io.compress.CompressionParameters.parseCompressorClass(CompressionParameters.java:141)
at 
org.apache.cassandra.io.compress.CompressionParameters.(CompressionParameters.java:70)
at 
org.apache.cassandra.io.compress.CompressionParameters.create(CompressionParameters.java:63)
at 
org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaData.java:1224)
... 13 more
Caused by: java.lang.ClassNotFoundException: 
org.apache.cassandra.io.compress.LZ4Compressor
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at 
org.apache.cassandra.io.compress.CompressionParameters.parseCompressorClass(CompressionParameters.java:137)
... 16 more
ERROR [ReadStage:33] 2013-03-13 15:24:54,319 AbstractCassandraDaemon.java (line 
135) Exception in thread Thread[ReadStage:33,5,main]
java.lang.RuntimeException: java.lang.IllegalArgumentException: Unknown 
table/cf pair (system_auth.users)
at 
org.apache.cassandra.service.RangeSliceVerbHandler.doVerb(RangeSliceVerbHandler.java:71)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
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.lang.IllegalArgumentException: Unknown table/cf pair 
(system_auth.users)
at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:159)
at 
org.apache.cassandra.service.RangeSliceVerbHandler.executeLocally(RangeSliceVerbHandler.java:44)
at 
org.apache.cassand

[jira] [Commented] (CASSANDRA-5151) Implement better way of eliminating compaction left overs.

2013-03-13 Thread Yuki Morishita (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601547#comment-13601547
 ] 

Yuki Morishita commented on CASSANDRA-5151:
---

We should also remove ancestors from sstable metadata because those could 
consume heap when you are using LCS(CASSANDRA-5342).

> Implement better way of eliminating compaction left overs.
> --
>
> Key: CASSANDRA-5151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5151
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.3
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
> Fix For: 2.0
>
> Attachments: 
> 0001-move-scheduling-MeteredFlusher-to-CassandraDaemon.patch, 5151-1.2.txt, 
> 5151-v2.txt
>
>
> This is from discussion in CASSANDRA-5137. Currently we skip loading SSTables 
> that are left over from incomplete compaction to not over-count counter, but 
> the way we track compaction completion is not secure.
> One possible solution is to create system CF like:
> {code}
> create table compaction_log (
>   id uuid primary key,
>   inputs set,
>   outputs set
> );
> {code}
> to track incomplete compaction.

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


[jira] [Commented] (CASSANDRA-5342) ancestors are not cleared in SSTableMetadata after compactions are done and old SSTables are removed

2013-03-13 Thread Yuki Morishita (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601546#comment-13601546
 ] 

Yuki Morishita commented on CASSANDRA-5342:
---

Ancestors are used to track compaction leftovers. We are implementing better 
way to achieve that in CASSANDRA-5151 using system table.

> ancestors are not cleared in SSTableMetadata after compactions are done and 
> old SSTables are removed
> 
>
> Key: CASSANDRA-5342
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5342
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.10, 1.2.2
>Reporter: Wei Zhu
> Attachments: Screen Shot 2013-03-13 at 12.05.08 PM.png
>
>
> We are using LCS and have total of 38000 SSTables for one CF. During LCS, 
> there could be over a thousand SSTable involved. All those SSTable IDs are 
> stored in ancestors field of SSTableMetatdata for the new table. In our case, 
> it consumes more than 1G of heap memory for those field. Put it in 
> perspective, the ancestors consume 2 - 3 times more memory than bloomfilter 
> (fp = 0.1 by default) in LCS. 
> We should remove those ancestors from SSTableMetadata after the compaction is 
> finished and the old SSTable is removed. It  might be a big deal for Sized 
> Compaction since there are small number of SSTable involved. But it consumes 
> a lot of memory for LCS. 
> At least, we shouldn't load those ancestors to the memory during startup if 
> the files are removed. 
> I would love to contribute and provide patch. Please let me know how to 
> start. 

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


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

2013-03-13 Thread Dan Peebles (JIRA)

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

Dan Peebles commented on CASSANDRA-4687:


Matthew, what kind of use pattern do you have, and has it changed recently? In 
my experience with this problem, I get it a lot when I truncate CFs or drop 
keyspaces. The fact that clearing/disabling the key cache (are you using a row 
cache?) doesn't help you suggests that your cause might be different from mine, 
because that remedy did help me.

It's also worth noting that I saw someone on the IRC channel report this issue 
last night, so it does seem to be affecting quite a few people.

> Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
> ---
>
> Key: CASSANDRA-4687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single 
> node cluster
>Reporter: Leonid Shalupov
>Assignee: Pavel Yaskevich
> Fix For: 1.2.3
>
> Attachments: 4687-debugging.txt
>
>
> Under heavy write load sometimes cassandra fails with assertion error.
> git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
> works fine if global key/row caches disabled in code.
> {quote}
> java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in 
> /var/lib/cassandra/data/...-he-1-Data.db
>   at 
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.(SSTableSliceIterator.java:60)
>   at 
> org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
>   at 
> org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
>   at 
> org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
>   at 
> org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
>   at org.apache.cassandra.db.Table.getRow(Table.java:378)
>   at 
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
>   at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:662)
> {quote}

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


[jira] [Commented] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Ryan McGuire (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601536#comment-13601536
 ] 

Ryan McGuire commented on CASSANDRA-5334:
-

I've tested [~slebresne]'s patch; it works to resolve all the NPEs, assuming 
that's the way we want to go. I'm seeing some other issues after the upgrade, 
but I'll break those out into separate bugs as I'm pretty sure they're 
unrelated to this report.



> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: 5334.patch, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


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

2013-03-13 Thread Matthew Goodson (JIRA)

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

Matthew Goodson edited comment on CASSANDRA-4687 at 3/13/13 7:31 PM:
-

I have just started seeing this error on one node. I get it 2 or 3 times a 
minute. I am using a 3 node cluster running cassandra 1.0.6 which has been 
running for about a year and only just started doing it. It is only happening 
to our largest column family (~= 17G). I have disabled key caching for the CF, 
invalidated the cache and removed the CF's saved cache. None of these 
workarounds have worked.

  was (Author: goody44):
I have just started seeing this error. I get it 2 or 3 times a minute. I am 
using a 3 node cluster running cassandra 1.0.6 which has been running for about 
a year and only just started doing it. It is only happening to our largest 
column family (~= 17G). I have disabled key caching for the CF, invalidated the 
cache and removed the CF's saved cache. None of these workarounds have worked.
  
> Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
> ---
>
> Key: CASSANDRA-4687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single 
> node cluster
>Reporter: Leonid Shalupov
>Assignee: Pavel Yaskevich
> Fix For: 1.2.3
>
> Attachments: 4687-debugging.txt
>
>
> Under heavy write load sometimes cassandra fails with assertion error.
> git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
> works fine if global key/row caches disabled in code.
> {quote}
> java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in 
> /var/lib/cassandra/data/...-he-1-Data.db
>   at 
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.(SSTableSliceIterator.java:60)
>   at 
> org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
>   at 
> org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
>   at 
> org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
>   at 
> org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
>   at org.apache.cassandra.db.Table.getRow(Table.java:378)
>   at 
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
>   at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:662)
> {quote}

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


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

2013-03-13 Thread Matthew Goodson (JIRA)

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

Matthew Goodson commented on CASSANDRA-4687:


I have just started seeing this error. I get it 2 or 3 times a minute. I am 
using a 3 node cluster running cassandra 1.0.6 which has been running for about 
a year and only just started doing it. It is only happening to our largest 
column family (~= 17G). I have disabled key caching for the CF, invalidated the 
cache and removed the CF's saved cache. None of these workarounds have worked.

> Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
> ---
>
> Key: CASSANDRA-4687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single 
> node cluster
>Reporter: Leonid Shalupov
>Assignee: Pavel Yaskevich
> Fix For: 1.2.3
>
> Attachments: 4687-debugging.txt
>
>
> Under heavy write load sometimes cassandra fails with assertion error.
> git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
> works fine if global key/row caches disabled in code.
> {quote}
> java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in 
> /var/lib/cassandra/data/...-he-1-Data.db
>   at 
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.(SSTableSliceIterator.java:60)
>   at 
> org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
>   at 
> org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
>   at 
> org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
>   at 
> org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
>   at org.apache.cassandra.db.Table.getRow(Table.java:378)
>   at 
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
>   at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:662)
> {quote}

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


[jira] [Updated] (CASSANDRA-5342) ancestors are not cleared in SSTableMetadata after compactions are done and old SSTables are removed

2013-03-13 Thread Wei Zhu (JIRA)

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

Wei Zhu updated CASSANDRA-5342:
---

Attachment: Screen Shot 2013-03-13 at 12.05.08 PM.png

> ancestors are not cleared in SSTableMetadata after compactions are done and 
> old SSTables are removed
> 
>
> Key: CASSANDRA-5342
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5342
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.10, 1.2.2
>Reporter: Wei Zhu
> Attachments: Screen Shot 2013-03-13 at 12.05.08 PM.png
>
>
> We are using LCS and have total of 38000 SSTables for one CF. During LCS, 
> there could be over a thousand SSTable involved. All those SSTable IDs are 
> stored in ancestors field of SSTableMetatdata for the new table. In our case, 
> it consumes more than 1G of heap memory for those field. Put it in 
> perspective, the ancestors consume 2 - 3 times more memory than bloomfilter 
> (fp = 0.1 by default) in LCS. 
> We should remove those ancestors from SSTableMetadata after the compaction is 
> finished and the old SSTable is removed. It  might be a big deal for Sized 
> Compaction since there are small number of SSTable involved. But it consumes 
> a lot of memory for LCS. 
> At least, we shouldn't load those ancestors to the memory during startup if 
> the files are removed. 
> I would love to contribute and provide patch. Please let me know how to 
> start. 

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


[jira] [Created] (CASSANDRA-5342) ancestors are not cleared in SSTableMetadata after compactions are done and old SSTables are removed

2013-03-13 Thread Wei Zhu (JIRA)
Wei Zhu created CASSANDRA-5342:
--

 Summary: ancestors are not cleared in SSTableMetadata after 
compactions are done and old SSTables are removed
 Key: CASSANDRA-5342
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5342
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.2, 1.1.10
Reporter: Wei Zhu


We are using LCS and have total of 38000 SSTables for one CF. During LCS, there 
could be over a thousand SSTable involved. All those SSTable IDs are stored in 
ancestors field of SSTableMetatdata for the new table. In our case, it consumes 
more than 1G of heap memory for those field. Put it in perspective, the 
ancestors consume 2 - 3 times more memory than bloomfilter (fp = 0.1 by 
default) in LCS. 
We should remove those ancestors from SSTableMetadata after the compaction is 
finished and the old SSTable is removed. It  might be a big deal for Sized 
Compaction since there are small number of SSTable involved. But it consumes a 
lot of memory for LCS. 
At least, we shouldn't load those ancestors to the memory during startup if the 
files are removed. 
I would love to contribute and provide patch. Please let me know how to start. 

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


[jira] [Updated] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Ryan McGuire (JIRA)

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

Ryan McGuire updated CASSANDRA-5334:


Tester: enigmacurry

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: 5334.patch, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[Cassandra Wiki] Trivial Update of "LaurenSie" by LaurenSie

2013-03-13 Thread Apache Wiki
Dear Wiki user,

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

The "LaurenSie" page has been changed by LaurenSie:
http://wiki.apache.org/cassandra/LaurenSie

New page:
<>
<>
Feel free to surf to my web blog: [[http://www.foundcheapbeatsbydre.com|dr dre 
beats headphones]]


[jira] [Commented] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601470#comment-13601470
 ] 

Jonathan Ellis commented on CASSANDRA-5334:
---

Alternatively, could we hack 1.1.x to ignore the auth CFs?

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: 5334.patch, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[2/3] git commit: add tmp flag to Descriptor hashcode patch by Boris Yen; reviewed by jbellis for CASSANDRA-4021

2013-03-13 Thread jbellis
add tmp flag to Descriptor hashcode
patch by Boris Yen; reviewed by jbellis for CASSANDRA-4021


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

Branch: refs/heads/trunk
Commit: c688125ba895c47ad04cb048187e162c4105892a
Parents: e4b3d40
Author: Jonathan Ellis 
Authored: Mon Mar 11 18:13:57 2013 -0500
Committer: Jonathan Ellis 
Committed: Wed Mar 13 13:33:59 2013 -0500

--
 CHANGES.txt|1 +
 .../apache/cassandra/io/sstable/Descriptor.java|4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c688125b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d249806..6472974 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -21,6 +21,7 @@
  * Relax CL for auth queries for non-default users (CASSANDRA-5310)
  * Fix AssertionError during repair (CASSANDRA-5245)
 Merged from 1.1:
+ * add tmp flag to Descriptor hashcode (CASSANDRA-4021)
  * fix logging of "Found table data in data directories" when only system 
tables
are present (CASSANDRA-5289)
  * cli: Add JMX authentication support (CASSANDRA-5080)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c688125b/src/java/org/apache/cassandra/io/sstable/Descriptor.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/Descriptor.java 
b/src/java/org/apache/cassandra/io/sstable/Descriptor.java
index cf1907e..f0709d8 100644
--- a/src/java/org/apache/cassandra/io/sstable/Descriptor.java
+++ b/src/java/org/apache/cassandra/io/sstable/Descriptor.java
@@ -197,7 +197,7 @@ public class Descriptor
 this.cfname = cfname;
 this.generation = generation;
 temporary = temp;
-hashCode = Objects.hashCode(directory, generation, ksname, cfname);
+hashCode = Objects.hashCode(directory, generation, ksname, cfname, 
temp);
 }
 
 public Descriptor withGeneration(int newGeneration)
@@ -328,7 +328,7 @@ public class Descriptor
 if (!(o instanceof Descriptor))
 return false;
 Descriptor that = (Descriptor)o;
-return that.directory.equals(this.directory) && that.generation == 
this.generation && that.ksname.equals(this.ksname) && 
that.cfname.equals(this.cfname);
+return that.directory.equals(this.directory) && that.generation == 
this.generation && that.ksname.equals(this.ksname) && 
that.cfname.equals(this.cfname) && that.temporary == this.temporary;
 }
 
 @Override



[1/3] git commit: add tmp flag to Descriptor hashcode patch by Boris Yen; reviewed by jbellis for CASSANDRA-4021

2013-03-13 Thread jbellis
add tmp flag to Descriptor hashcode
patch by Boris Yen; reviewed by jbellis for CASSANDRA-4021


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

Branch: refs/heads/cassandra-1.2
Commit: c688125ba895c47ad04cb048187e162c4105892a
Parents: e4b3d40
Author: Jonathan Ellis 
Authored: Mon Mar 11 18:13:57 2013 -0500
Committer: Jonathan Ellis 
Committed: Wed Mar 13 13:33:59 2013 -0500

--
 CHANGES.txt|1 +
 .../apache/cassandra/io/sstable/Descriptor.java|4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c688125b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d249806..6472974 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -21,6 +21,7 @@
  * Relax CL for auth queries for non-default users (CASSANDRA-5310)
  * Fix AssertionError during repair (CASSANDRA-5245)
 Merged from 1.1:
+ * add tmp flag to Descriptor hashcode (CASSANDRA-4021)
  * fix logging of "Found table data in data directories" when only system 
tables
are present (CASSANDRA-5289)
  * cli: Add JMX authentication support (CASSANDRA-5080)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c688125b/src/java/org/apache/cassandra/io/sstable/Descriptor.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/Descriptor.java 
b/src/java/org/apache/cassandra/io/sstable/Descriptor.java
index cf1907e..f0709d8 100644
--- a/src/java/org/apache/cassandra/io/sstable/Descriptor.java
+++ b/src/java/org/apache/cassandra/io/sstable/Descriptor.java
@@ -197,7 +197,7 @@ public class Descriptor
 this.cfname = cfname;
 this.generation = generation;
 temporary = temp;
-hashCode = Objects.hashCode(directory, generation, ksname, cfname);
+hashCode = Objects.hashCode(directory, generation, ksname, cfname, 
temp);
 }
 
 public Descriptor withGeneration(int newGeneration)
@@ -328,7 +328,7 @@ public class Descriptor
 if (!(o instanceof Descriptor))
 return false;
 Descriptor that = (Descriptor)o;
-return that.directory.equals(this.directory) && that.generation == 
this.generation && that.ksname.equals(this.ksname) && 
that.cfname.equals(this.cfname);
+return that.directory.equals(this.directory) && that.generation == 
this.generation && that.ksname.equals(this.ksname) && 
that.cfname.equals(this.cfname) && that.temporary == this.temporary;
 }
 
 @Override



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

2013-03-13 Thread jbellis
Updated Branches:
  refs/heads/cassandra-1.2 e4b3d403f -> c688125ba
  refs/heads/trunk c7230f2e2 -> b88867ffa


Merge branch 'cassandra-1.2' into trunk


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

Branch: refs/heads/trunk
Commit: b88867ffa934bbcfc1abe6df4c8c18da62e7a9a0
Parents: c7230f2 c688125
Author: Jonathan Ellis 
Authored: Wed Mar 13 13:34:28 2013 -0500
Committer: Jonathan Ellis 
Committed: Wed Mar 13 13:34:28 2013 -0500

--
 CHANGES.txt|1 +
 .../apache/cassandra/io/sstable/Descriptor.java|4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b88867ff/src/java/org/apache/cassandra/io/sstable/Descriptor.java
--



[jira] [Updated] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne updated CASSANDRA-5334:


Attachment: 5334.patch

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: 5334.patch, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Updated] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne updated CASSANDRA-5334:


Attachment: (was: 5334.txt)

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Updated] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne updated CASSANDRA-5334:


Attachment: 5334.txt

Alright. The problem is that due to CASSANDRA-3794 (and to a lower extend 
CASSANDRA-4433), new keyspaces/column families cannot be created in a mixed 
1.1/1.2 cluster (keyspace lacks the "name" column and column families lack an 
old-style CfId).

This is a limitation we accepted in CASSANDRA-3794, but unfortunately, 1.2 
creates the system_auth keyspace/column families on startup if they don't exist 
which triggers pretty much all the stacktrace on this issue.

One hacky solution I can see is to 1) reintroduce the "name" column for 
keyspace, and 2) we manually provide an old-style cfId for the Auth.USERS_CF. 
Attaching an updated patch that does both. This is ugly however.


> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Updated] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne updated CASSANDRA-5334:


Attachment: (was: 5334.txt)

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Commented] (CASSANDRA-5335) need ability to switch to LCS node by node

2013-03-13 Thread Dean Hiller (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601386#comment-13601386
 ] 

Dean Hiller commented on CASSANDRA-5335:


We went to org.apache.cassandra.db -> ColumnFamilies -> {our keyspace}-> {our 
CF} -> Attributes -> CompactionStrategyClass and then changed "SizeTiered" to 
"Leveled" or rather the whole string was 
org.apache.cassandra.db.compaction.LeveledCompactionStrategy.  We hit 
enter...nothing happened.  We ran a "nodetool compact databus5 nreldata" and 
the files are the same.  unfortunately we are in QA with little data and wanted 
to set the default size=1 but could not find that in JMX.  We can't tell if it 
is working or not.

> need ability to switch to LCS node by node
> --
>
> Key: CASSANDRA-5335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5335
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.2.2
> Environment: linux, cassandra 1.2.2
>Reporter: Dean Hiller
>  Labels: compaction
>
> when we switched to LCS, nearly all the servers started rewriting their file 
> structure.  We need a way to switch just one node so we can slowly roll out a 
> huge change like this.  doing the whole cluster brought it to it's needs and 
> we tried nodetool stop compaction on some nodes but that did not help at all. 
>  We had to really wait overnight for all LCS to finish. 
> We had also tried nodetool setcompactionthroughput 1 which also had no effect 
> and performance was still pretty bad.  Ideally, none of this would be a 
> problem if we were just doing one node as we would just pull the node back 
> out while it was converting to LCS.

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


[jira] [Comment Edited] (CASSANDRA-4316) Compaction Throttle too bursty with large rows

2013-03-13 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13561320#comment-13561320
 ] 

Jonathan Ellis edited comment on CASSANDRA-4316 at 3/13/13 5:13 PM:


Not thrilled about pushing this down into RAR.  Feels like we're violating 
encapsulation too much.

What if we did this?
# Make compaction truly single-pass (CASSANDRA-4180)
# Introduce a SequentialReader to replace RAR
# Subclass SR to CompactionReader and add throttling there

(I suppose we could subclass RAR already for CompactionReader, but since I want 
to do #1 and #2 anyway, it would be less work to do it in this order... :)

  was (Author: jbellis):
Not thrilled about pushing this down into RAR.  Feels like we're violating 
encapsulation too much.

What if we did this?
# Make compaction truly single-pass (there's a ticket for this somewhere)
# Introduce a SequentialReader to replace RAR
# Subclass SR to CompactionReader and add throttling there

(I suppose we could subclass RAR already for CompactionReader, but since I want 
to do #1 and #2 anyway, it would be less work to do it in this order... :)
  
> Compaction Throttle too bursty with large rows
> --
>
> Key: CASSANDRA-4316
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4316
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 0.8.0
>Reporter: Wayne Lewis
>Assignee: Yuki Morishita
> Fix For: 1.2.3
>
> Attachments: 4316-1.2.txt, 4316-1.2-v2.txt
>
>
> In org.apache.cassandra.db.compaction.CompactionIterable the check for 
> compaction throttling occurs once every 1000 rows. In our workload this is 
> much too large as we have many large rows (16 - 100 MB).
> With a 100 MB row, about 100 GB is read (and possibly written) before the 
> compaction throttle sleeps. This causes bursts of essentially unthrottled 
> compaction IO followed by a long sleep which yields inconsistence performance 
> and high error rates during the bursts.
> We applied a workaround to check throttle every row which solved our 
> performance and error issues:
> line 116 in org.apache.cassandra.db.compaction.CompactionIterable:
> if ((row++ % 1000) == 0)
> replaced with
> if ((row++ % 1) == 0)
> I think the better solution is to calculate how often throttle should be 
> checked based on the throttle rate to apply sleeps more consistently. E.g. if 
> 16MB/sec is the limit then check for sleep after every 16MB is read so sleeps 
> are spaced out about every second.

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


[Cassandra Wiki] Trivial Update of "HoustonWa" by HoustonWa

2013-03-13 Thread Apache Wiki
Dear Wiki user,

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

The "HoustonWa" page has been changed by HoustonWa:
http://wiki.apache.org/cassandra/HoustonWa

New page:
Got nothing to write about me I think.<>
<>
My page :: [[http://djgalix.pl/|Going In this article]]


[jira] [Updated] (CASSANDRA-4180) Single-pass compaction for LCR

2013-03-13 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis updated CASSANDRA-4180:
--

Summary: Single-pass compaction for LCR  (was: Single-pass compaction)

> Single-pass compaction for LCR
> --
>
> Key: CASSANDRA-4180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4180
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Sylvain Lebresne
>Assignee: Jason Brown
>  Labels: compaction
> Fix For: 2.0
>
>
> LazilyCompactedRow reads all data twice to compact a row which is obviously 
> inefficient. The main reason we do that is to compute the row header. 
> However, CASSANDRA-2319 have removed the main part of that row header. What 
> remains is the size in bytes and the number of columns, but it should be 
> relatively simple to remove those, which would then remove the need for the 
> two-phase compaction.

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


[jira] [Updated] (CASSANDRA-4180) Single-pass compaction

2013-03-13 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis updated CASSANDRA-4180:
--

Summary: Single-pass compaction  (was: Remove 2-phase compaction)

> Single-pass compaction
> --
>
> Key: CASSANDRA-4180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4180
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Sylvain Lebresne
>Assignee: Jason Brown
>  Labels: compaction
> Fix For: 2.0
>
>
> LazilyCompactedRow reads all data twice to compact a row which is obviously 
> inefficient. The main reason we do that is to compute the row header. 
> However, CASSANDRA-2319 have removed the main part of that row header. What 
> remains is the size in bytes and the number of columns, but it should be 
> relatively simple to remove those, which would then remove the need for the 
> two-phase compaction.

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


[jira] [Updated] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Ryan McGuire (JIRA)

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

Ryan McGuire updated CASSANDRA-5334:


Attachment: cassandra.trunk.yaml

The cassandra.yaml for the 1.1.9 nodes are the default that ccm creates.

Attached is my cassandra.yaml that I use for the upgraded node. This is 
basically the default one that ccm creates for 1.2.2 modified to use the 
RandomPartitioner that the node is using and some path fixes.

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: 5334.txt, cassandra.trunk.yaml
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Commented] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Ryan McGuire (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601346#comment-13601346
 ] 

Ryan McGuire commented on CASSANDRA-5334:
-

I thought maybe the dtest was doing something I didn't want to have happen, so 
I'm not using it for this bug report. The two exceptions in my previous comment 
were from issuing ccm commands directly on the command line exactly as I have 
in the original report (no dtest used.)

Both exceptions appear in the logs directly after starting the upgraded node. 
The only queries issued in this test is the stress command before the upgrade, 
no queries were issued after the upgrade.

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: 5334.txt
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Commented] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Sylvain Lebresne (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601337#comment-13601337
 ] 

Sylvain Lebresne commented on CASSANDRA-5334:
-

Quick question: does the dtest create new tables in the mixed version cluster? 
The last NPE seems related to the old CF id removed by CASSANDRA-3794, however 
we still write the old id for column families that have one in 1.2, so in 
theory this should only happen if a new column family is created. If that is 
the case (that the test create a column family in the mixed version cluster), 
then I'm afraid this is not supported between 1.1 and 1.2 (due to 
CASSANDRA-3794).

For the 2nd error (the system_auth one), is the dtest doing anything related to 
authorization in the mixed version cluster? 

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: 5334.txt
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 stop
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
> Edit node1's cassandra.yaml to be 1.2 compliant.
> {code}
> ccm node1 start
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Updated] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Ryan McGuire (JIRA)

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

Ryan McGuire updated CASSANDRA-5334:


Description: 
I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 node 
upgraded from 1.1.9. 

The upgrade works, and I don't see any end user problems, however I see this 
exception in the logs on the non-upgraded nodes:

{code}
ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
(line 135) Exception in thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at 
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
at 
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
at 
org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
at 
org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
at 
org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
at 
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
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)
{code}


Steps to reproduce:
{code}
ccm create -v 1.1.9 1.1.9
ccm populate -n 3
ccm start
ccm node1 stress
ccm node1 stop
{code}

edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2. 
Edit node1's cassandra.yaml to be 1.2 compliant.

{code}
ccm node1 start
{code}

The cluster is now a mixed version, and works for user queries, but with the 
exception above.

  was:
I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 node 
upgraded from 1.1.9. 

The upgrade works, and I don't see any end user problems, however I see this 
exception in the logs on the non-upgraded nodes:

{code}
ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
(line 135) Exception in thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at 
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
at 
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
at 
org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
at 
org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
at 
org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
at 
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
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)
{code}


Steps to reproduce:
{code}
ccm create -v 1.1.9 1.1.9
ccm populate -n 3
ccm start
ccm node1 stress
ccm node1 down
{code}

edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2

{code}
ccm node1 up
{code}

The cluster is now a mixed version, and works for user queries, but with the 
exception above.


> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Proj

[jira] [Commented] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Ryan McGuire (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601279#comment-13601279
 ] 

Ryan McGuire commented on CASSANDRA-5334:
-

[~slebresne], applying your patch and reproducing the steps above I get this in 
node2's log (running 1.1.9). The first exception is similar but different, 
perhaps another field needs migrating? The second exception I'm not sure if 
it's related or needs another ticket.

{code}
ERROR [MigrationStage:1] 2013-03-13 11:57:13,722 AbstractCassandraDaemon.java 
(line 135) Exception in thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at 
org.apache.cassandra.utils.ByteBufferUtil.toInt(ByteBufferUtil.java:414)
at org.apache.cassandra.cql.jdbc.JdbcInt32.compose(JdbcInt32.java:98)
at org.apache.cassandra.db.marshal.Int32Type.compose(Int32Type.java:37)
at 
org.apache.cassandra.cql3.UntypedResultSet$Row.getInt(UntypedResultSet.java:97)
at 
org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaData.java:1202)
at 
org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1247)
at 
org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:299)
at 
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:462)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:374)
at 
org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
at 
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
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)
ERROR [ReadStage:33] 2013-03-13 11:57:23,794 AbstractCassandraDaemon.java (line 
135) Exception in thread Thread[ReadStage:33,5,main]
java.lang.AssertionError: Unknown keyspace system_auth
at org.apache.cassandra.db.Table.(Table.java:287)
at org.apache.cassandra.db.Table.open(Table.java:119)
at org.apache.cassandra.db.Table.open(Table.java:97)
at 
org.apache.cassandra.service.RangeSliceVerbHandler.executeLocally(RangeSliceVerbHandler.java:44)
at 
org.apache.cassandra.service.RangeSliceVerbHandler.doVerb(RangeSliceVerbHandler.java:63)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
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)
{code}

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
> Fix For: 1.2.3
>
> Attachments: 5334.txt
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:

[Cassandra Wiki] Trivial Update of "Basil27I" by Basil27I

2013-03-13 Thread Apache Wiki
Dear Wiki user,

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

The "Basil27I" page has been changed by Basil27I:
http://wiki.apache.org/cassandra/Basil27I

New page:
Hi! I'm michael duivis: Nwhr S. Cxxtubc<>
I connect with others, v no matter what nation, n the specific area are you 
feeling p because of.<>
I g wish to examine a lot of fashion magazines, publications. Study a few vogue 
portions of the patient.<>
This communication might be:291 * 0255432<>
<>
My webpage ... [[http://www.packchaneloutlet.com|chanel outlet]]


[jira] [Commented] (CASSANDRA-5338) scripts fail when paths contain space

2013-03-13 Thread Brandon Williams (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601239#comment-13601239
 ] 

Brandon Williams commented on CASSANDRA-5338:
-

See CASSANDRA-5301 for the duplication.

> scripts fail when paths contain space
> -
>
> Key: CASSANDRA-5338
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5338
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.2.2
> Environment: Kubuntu 12.10 (GNU bash 4.2.37), and Windows XP (msysgit 
> GNU bash 3.1.0)
>Reporter: Amichai Rothman
>Priority: Minor
> Attachments: fix_spaces_in_paths.patch
>
>
> The shell scripts fail when the cassandra or java dirs contain spaces.

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


[jira] [Updated] (CASSANDRA-5338) scripts fail when paths contain space

2013-03-13 Thread Brandon Williams (JIRA)

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

Brandon Williams updated CASSANDRA-5338:


Reviewer: urandom

> scripts fail when paths contain space
> -
>
> Key: CASSANDRA-5338
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5338
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.2.2
> Environment: Kubuntu 12.10 (GNU bash 4.2.37), and Windows XP (msysgit 
> GNU bash 3.1.0)
>Reporter: Amichai Rothman
>Priority: Minor
> Attachments: fix_spaces_in_paths.patch
>
>
> The shell scripts fail when the cassandra or java dirs contain spaces.

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


[jira] [Created] (CASSANDRA-5341) Select writetime Exception when data doesn't exist

2013-03-13 Thread julien campan (JIRA)
julien campan created CASSANDRA-5341:


 Summary: Select writetime  Exception when  data doesn't exist
 Key: CASSANDRA-5341
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5341
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.2.2
Reporter: julien campan
Priority: Minor


Hi,

When I try do to a “select writetime” on a empty column, I have an Exception. 
For example : 
Create table test (id  int, value int, value2 int, primary key (id));   
INSERT INTO test (id, value ) VALUES ( 1,100) ;

select * from test where id =1; 
==>
 id | value | value2
+---+
  1 |   100 |   null

It’s working.

select WRITETIME(value) from test where id =1; 
==>
 writetime(value)
--
 1363184789539000
It’s working


select WRITETIME(value2) from test where id =1; 

==>TSocket read 0 bytes

I have an Exception.


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


[jira] [Commented] (CASSANDRA-5202) AssertionError in the backend: "DecoratedKey(-1, ) != DecoratedKey(x, y) ..." while querying data after bulk insert - 1M rows with 100 columns. Also failure to drop

2013-03-13 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601216#comment-13601216
 ] 

Jonathan Ellis commented on CASSANDRA-5202:
---

bq. truncate ... seems to lead to the same symptoms

I think we can fix that by recording the sstable generation somewhere, instead 
of just assuming that "if no files of generation >= X exist, we should start 
creating new sstables with X."

(Which I think would actually be a simpler fix for the issue in general...  but 
giving different "versions" of a table distinct IDs is the Right Solution, so 
I'm still +1 on that unless Yuki thinks the cost is too high for the practical 
benefits.)

> AssertionError in the backend: "DecoratedKey(-1, ) != DecoratedKey(x, y) ..." 
> while querying data after bulk insert - 1M rows with 100 columns. Also 
> failure to drop column families
> 
>
> Key: CASSANDRA-5202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5202
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.9
> Environment: OS: Windows 7, 
> Server: Cassandra 1.1.9 release drop
> Client: astyanax 1.56.21, 
> JVM: Sun/Oracle JVM 64 bit (jdk1.6.0_27)
>Reporter: Marat Bedretdinov
>  Labels: test
> Attachments: 5202-1.1.txt, astyanax-stress-driver.zip
>
>
> Attached is a driver that sequentially:
> 1. Drops keyspace
> 2. Creates keyspace
> 4. Creates 2 column families
> 5. Seeds 1M rows with 100 columns
> 6. Queries these 2 column families
> The above steps are repeated 1000 times.
> The following exception is observed at random (race - SEDA?):
> ERROR [ReadStage:55] 2013-01-29 19:24:52,676 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[ReadStage:55,5,main]
> java.lang.AssertionError: DecoratedKey(-1, ) != 
> DecoratedKey(62819832764241410631599989027761269388, 313a31) in 
> C:\var\lib\cassandra\data\user_role_reverse_index\business_entity_role\user_role_reverse_index-business_entity_role-hf-1-Data.db
>   at 
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.(SSTableSliceIterator.java:60)
>   at 
> org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
>   at 
> org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
>   at 
> org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
>   at 
> org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1367)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1229)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1164)
>   at org.apache.cassandra.db.Table.getRow(Table.java:378)
>   at 
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
>   at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:822)
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1271)
>   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)
> This exception appears in the server at the time of client submitting a query 
> request (row slice) and not at the time data is seeded. The client times out 
> and this data can no longer be queried as the same exception would always 
> occur from there on.
> Also on iteration 201, it appears that dropping column families failed and as 
> a result their recreation failed with unique column family name violation 
> (see exception below). Note that the data files are actually gone, so it 
> appears that the server runtime responsible for creating column family was 
> out of sync with the piece that dropped them:
> Starting dropping column families
> Dropped column families
> Starting dropping keyspace
> Dropped keyspace
> Starting creating column families
> Created column families
> Starting seeding data
> Total rows inserted: 100 in 5105 ms
> Iteration: 200; Total running time for 1000 queries is 232; Average running 
> time of 1000 queries is 0 ms
> Starting dropping column families
> Dropped column families
> Starting dropping keyspace
> Dropped keyspace
> Starting creating column families
> Created column families
> Starting seeding data
> Total rows inserted: 100 in

[jira] [Commented] (CASSANDRA-5202) AssertionError in the backend: "DecoratedKey(-1, ) != DecoratedKey(x, y) ..." while querying data after bulk insert - 1M rows with 100 columns. Also failure to drop

2013-03-13 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601213#comment-13601213
 ] 

Jonathan Ellis commented on CASSANDRA-5202:
---

bq. I don't want to embed UUID cfId to file name

It's ugly, but that's the logical solution, isn't it?  We're saying that 
sstables for table foo on Tuesday, and table foo on Wednesday after drop and 
re-create, are really different things, so distinguishing them as such on the 
FS is if nothing else a good extra layer of protection against mixing the two.

And your patch already stores cfid in the system table, so users could still 
find out which sstables belong to which table definitions, although granted 
it's not as convenient.

> AssertionError in the backend: "DecoratedKey(-1, ) != DecoratedKey(x, y) ..." 
> while querying data after bulk insert - 1M rows with 100 columns. Also 
> failure to drop column families
> 
>
> Key: CASSANDRA-5202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5202
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.9
> Environment: OS: Windows 7, 
> Server: Cassandra 1.1.9 release drop
> Client: astyanax 1.56.21, 
> JVM: Sun/Oracle JVM 64 bit (jdk1.6.0_27)
>Reporter: Marat Bedretdinov
>  Labels: test
> Attachments: 5202-1.1.txt, astyanax-stress-driver.zip
>
>
> Attached is a driver that sequentially:
> 1. Drops keyspace
> 2. Creates keyspace
> 4. Creates 2 column families
> 5. Seeds 1M rows with 100 columns
> 6. Queries these 2 column families
> The above steps are repeated 1000 times.
> The following exception is observed at random (race - SEDA?):
> ERROR [ReadStage:55] 2013-01-29 19:24:52,676 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[ReadStage:55,5,main]
> java.lang.AssertionError: DecoratedKey(-1, ) != 
> DecoratedKey(62819832764241410631599989027761269388, 313a31) in 
> C:\var\lib\cassandra\data\user_role_reverse_index\business_entity_role\user_role_reverse_index-business_entity_role-hf-1-Data.db
>   at 
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.(SSTableSliceIterator.java:60)
>   at 
> org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
>   at 
> org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
>   at 
> org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
>   at 
> org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1367)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1229)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1164)
>   at org.apache.cassandra.db.Table.getRow(Table.java:378)
>   at 
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
>   at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:822)
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1271)
>   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)
> This exception appears in the server at the time of client submitting a query 
> request (row slice) and not at the time data is seeded. The client times out 
> and this data can no longer be queried as the same exception would always 
> occur from there on.
> Also on iteration 201, it appears that dropping column families failed and as 
> a result their recreation failed with unique column family name violation 
> (see exception below). Note that the data files are actually gone, so it 
> appears that the server runtime responsible for creating column family was 
> out of sync with the piece that dropped them:
> Starting dropping column families
> Dropped column families
> Starting dropping keyspace
> Dropped keyspace
> Starting creating column families
> Created column families
> Starting seeding data
> Total rows inserted: 100 in 5105 ms
> Iteration: 200; Total running time for 1000 queries is 232; Average running 
> time of 1000 queries is 0 ms
> Starting dropping column families
> Dropped column families
> Starting dropping keyspace
> Dropped keyspace
> Starting creating column families
> Created column families
> Starting 

[jira] [Commented] (CASSANDRA-5202) AssertionError in the backend: "DecoratedKey(-1, ) != DecoratedKey(x, y) ..." while querying data after bulk insert - 1M rows with 100 columns. Also failure to drop

2013-03-13 Thread Dan Peebles (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601202#comment-13601202
 ] 

Dan Peebles commented on CASSANDRA-5202:


I was getting the same issue and found this bug. As a workaround, I tried 
changing my testsuite to avoid dropping the keyspace each time, and simply 
truncate every CF in the keyspace instead, but that seems to lead to the same 
symptoms. Just thought I'd point that out in case the truncate code path was 
being overlooked.

> AssertionError in the backend: "DecoratedKey(-1, ) != DecoratedKey(x, y) ..." 
> while querying data after bulk insert - 1M rows with 100 columns. Also 
> failure to drop column families
> 
>
> Key: CASSANDRA-5202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5202
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.9
> Environment: OS: Windows 7, 
> Server: Cassandra 1.1.9 release drop
> Client: astyanax 1.56.21, 
> JVM: Sun/Oracle JVM 64 bit (jdk1.6.0_27)
>Reporter: Marat Bedretdinov
>  Labels: test
> Attachments: 5202-1.1.txt, astyanax-stress-driver.zip
>
>
> Attached is a driver that sequentially:
> 1. Drops keyspace
> 2. Creates keyspace
> 4. Creates 2 column families
> 5. Seeds 1M rows with 100 columns
> 6. Queries these 2 column families
> The above steps are repeated 1000 times.
> The following exception is observed at random (race - SEDA?):
> ERROR [ReadStage:55] 2013-01-29 19:24:52,676 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[ReadStage:55,5,main]
> java.lang.AssertionError: DecoratedKey(-1, ) != 
> DecoratedKey(62819832764241410631599989027761269388, 313a31) in 
> C:\var\lib\cassandra\data\user_role_reverse_index\business_entity_role\user_role_reverse_index-business_entity_role-hf-1-Data.db
>   at 
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.(SSTableSliceIterator.java:60)
>   at 
> org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
>   at 
> org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
>   at 
> org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
>   at 
> org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1367)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1229)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1164)
>   at org.apache.cassandra.db.Table.getRow(Table.java:378)
>   at 
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
>   at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:822)
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1271)
>   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)
> This exception appears in the server at the time of client submitting a query 
> request (row slice) and not at the time data is seeded. The client times out 
> and this data can no longer be queried as the same exception would always 
> occur from there on.
> Also on iteration 201, it appears that dropping column families failed and as 
> a result their recreation failed with unique column family name violation 
> (see exception below). Note that the data files are actually gone, so it 
> appears that the server runtime responsible for creating column family was 
> out of sync with the piece that dropped them:
> Starting dropping column families
> Dropped column families
> Starting dropping keyspace
> Dropped keyspace
> Starting creating column families
> Created column families
> Starting seeding data
> Total rows inserted: 100 in 5105 ms
> Iteration: 200; Total running time for 1000 queries is 232; Average running 
> time of 1000 queries is 0 ms
> Starting dropping column families
> Dropped column families
> Starting dropping keyspace
> Dropped keyspace
> Starting creating column families
> Created column families
> Starting seeding data
> Total rows inserted: 100 in 5361 ms
> Iteration: 201; Total running time for 1000 queries is 222; Average running 
> time of 1000 queries is 0 ms
> Starting dropping column families
> Starting creating

[Cassandra Wiki] Trivial Update of "MallorySc" by MallorySc

2013-03-13 Thread Apache Wiki
Dear Wiki user,

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

The "MallorySc" page has been changed by MallorySc:
http://wiki.apache.org/cassandra/MallorySc

New page:
Not much to say about me at all.<>
Finally a part of this community.<>
I really wish I'm useful at all<>
<>
My page :: 
[[http://linuxvpnrouter.com/tiki-index.php?page=UserPagemaggiewil|linuxvpnrouter.com]]


[jira] [Commented] (CASSANDRA-5336) C* crashes with an OOM error when using the Simba Driver on a very wide table

2013-03-13 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601132#comment-13601132
 ] 

Jonathan Ellis commented on CASSANDRA-5336:
---

I guess I didn't read very carefully; I assumed that it would be using 
{{get_count}} on the Thrift side, which auto-pages to avoid this problem.  If 
you're going to use get_range_slices, then as Sylvain says you [which is to 
say, Simba] need to do your own paging to avoid OOM.

> C* crashes with an OOM error when using the Simba Driver on a very wide table
> -
>
> Key: CASSANDRA-5336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5336
> Project: Cassandra
>  Issue Type: Bug
>  Components: API
>Affects Versions: 1.1.6
> Environment: C* on a Mac with 1GB VM.  Simba ODBC driver
>Reporter: Steven Lowenthal
> Attachments: nhanes600-10k.tarZ, thrift.in, thrift.out
>
>
> The Simba driver executes a version of a count(*) query:
> SELECT SUM(1) from nhanes3 having sum(1) > 0.   It uses this format so ODBC 
> returns a no rows found error if the table is empty.   It translates into a 
> series of get_range_slice calls which bring back all of the rows, and for 
> every row, it brings back every single column name.   C* crashes with an OOM 
> in the thrift code.  The table has almost 600 columns of mixed text and 
> numeric data with many empty values.

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


[Cassandra Wiki] Trivial Update of "CarmenCIA" by CarmenCIA

2013-03-13 Thread Apache Wiki
Dear Wiki user,

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

The "CarmenCIA" page has been changed by CarmenCIA:
http://wiki.apache.org/cassandra/CarmenCIA

New page:
Not much to say about myself really.<>
Great to be a part of this site.<>
I really hope Im useful at all<>
<>
Also visit my web blog - [[http://www.housebuyerenquiry.co.uk|sell your home 
fast]]


[Cassandra Wiki] Trivial Update of "RoccoBurn" by RoccoBurn

2013-03-13 Thread Apache Wiki
Dear Wiki user,

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

The "RoccoBurn" page has been changed by RoccoBurn:
http://wiki.apache.org/cassandra/RoccoBurn

New page:
University or college bit by bit apart around an additional, Gu school, through 
the mentor and also lessons that belongs to them tough understand, I've 
productively performed expert tutorials,, not to mention establish good 
practice of significant research not to mention perform!. Can hard-working, 
faithful and even follow the guideline db of credibility plus condition, this 
daring to help challenge his or her self together with construct their very own 
probable;<>
Help to make a dynamic human being, the project determination, in an effort to 
unique goal to undertake the situations you are looking for gravely straight 
into strength;<>
Have a very good bxec style, able to get in touch with many people, basically 
teams, might be fairly immediate verbal exchanges with folks, solid crew 
organization competencies and also a nature associated with collaboration 
individuals, be ready to actually work together to quickly attain crew 
goals;<>
Be a master at discovering, homework and additionally pragmatism, assiduously, 
own intensive interest emm as well as vibrant skills, robust ability to change, 
in for you to include into a brand-new line of business in a very amount of 
time, to adapt to the pup and set him to undertake;<>
<>
Here is my blog post - [[http://www.firmchaneloutlet.com|chanel handbags]]


[jira] [Commented] (CASSANDRA-5129) newly bootstrapping nodes hang indefinitely in STATUS:BOOT while JOINING cluster

2013-03-13 Thread Kristoffer Carlson (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601043#comment-13601043
 ] 

Kristoffer Carlson commented on CASSANDRA-5129:
---

I'm still experiencing this on 1.2.2. Same exception and same result. I took a 
thread dump and it didn't have anything interesting in it.

> newly bootstrapping nodes hang indefinitely in STATUS:BOOT while JOINING 
> cluster  
> --
>
> Key: CASSANDRA-5129
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5129
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.0
> Environment: Ubuntu 12.04
>Reporter: Michael Kjellman
>Assignee: Brandon Williams
> Fix For: 1.2.2
>
>
> bootstrapping a new node causes it to hang indefinitely in STATUS:BOOT
> Nodes streaming to the new node report 
> {code}
> Mode: NORMAL
>  Nothing streaming to /10.8.30.16
> Not receiving any streams.
> Pool NameActive   Pending  Completed
> Commandsn/a 01843990
> Responses   n/a 2 661750
> {code}
> the node being streamed to stuck in the JOINING state reports:
> {code}
> Mode: JOINING
> Not sending any streams.
>  Nothing streaming from /10.8.30.103
>  Nothing streaming from /10.8.30.102
> Pool NameActive   Pending  Completed
> Commandsn/a 0 10
> Responses   n/a 0 613577
> {code}
> it appears that the nodes in the "nothing streaming" state never sends a 
> "finished streaming" to the joining node.
> no exceptions are thrown during the streaming on either node while the node 
> is in this state.
> {code:name="full gossip state of bootstrapping node"}
> /10.8.30.16
>   NET_VERSION:6
>   RELEASE_VERSION:1.2.0
>   STATUS:BOOT,127605887595351923798765477786913079289
>   RACK:RAC1
>   RPC_ADDRESS:0.0.0.0
>   DC:DC1
>   SCHEMA:5cd8420d-ce3c-3625-8293-67558a24816b
>   HOST_ID:e20817ce-7454-4dc4-a1c6-b1dec35c4491
>   LOAD:1.11824041581E11
> {code}

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


[jira] [Updated] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne updated CASSANDRA-5334:


Fix Version/s: 1.2.3

> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
> Fix For: 1.2.3
>
> Attachments: 5334.txt
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 down
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2
> {code}
> ccm node1 up
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Updated] (CASSANDRA-5334) NullPointerException in a mixed 1.1 / 1.2 cluster

2013-03-13 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne updated CASSANDRA-5334:


Attachment: 5334.txt

This was introduced by CASSANDRA-4433, that removed the "name" column of the 
schema_keyspaces table, but that one, while redundant, is used by 1.1 nodes.

This boils down to the problem I described in CASSANDRA-4603: we cannot easily 
remove anything in the schema tables without breaking rolling upgrades.

So attaching a patch that reintroduce the "name" column in 1.2 (we don't use it 
but we write it for compatibility sake). 


> NullPointerException in a mixed 1.1 / 1.2 cluster
> -
>
> Key: CASSANDRA-5334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5334
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.9
>Reporter: Ryan McGuire
> Attachments: 5334.txt
>
>
> I have a mixed version cluster consisting of two 1.1.9 nodes and one 1.2.2 
> node upgraded from 1.1.9. 
> The upgrade works, and I don't see any end user problems, however I see this 
> exception in the logs on the non-upgraded nodes:
> {code}
> ERROR [MigrationStage:1] 2013-03-11 18:09:09,001 AbstractCassandraDaemon.java 
> (line 135) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
>   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
>   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
>   at 
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
>   at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
>   at 
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:48)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>   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)
> {code}
> Steps to reproduce:
> {code}
> ccm create -v 1.1.9 1.1.9
> ccm populate -n 3
> ccm start
> ccm node1 stress
> ccm node1 down
> {code}
> edit ~/.ccm/1.1.9/cluster.conf and configure cassandra_dir to point to 1.2.2
> {code}
> ccm node1 up
> {code}
> The cluster is now a mixed version, and works for user queries, but with the 
> exception above.

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


[jira] [Created] (CASSANDRA-5340) use getopts instead of getopt in shell script

2013-03-13 Thread Amichai Rothman (JIRA)
Amichai Rothman created CASSANDRA-5340:
--

 Summary: use getopts instead of getopt in shell script
 Key: CASSANDRA-5340
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5340
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.2
 Environment: Windows XP msysgit GNU bash 3.1.0
Reporter: Amichai Rothman
Priority: Minor


I don't know what the officially supported platforms are or what versions of sh 
they support... however I do know that the cassandra startup script fails on at 
least one platform (Windows XP/msysgit) since it uses the external utility 
getopt which is not available there. Using the shell built-in getopts command 
instead, or parsing the command line manually, would fix the problem.

I'm no shell expert, but a little searching came up with the fact that the 
getopt utility is not required by POSIX (which a script comment claims needs to 
be adhered to) whereas getopts is standard and more portable. Some claim getopt 
is better when long option names need to be supported, however cassandra 
doesn't use those anyway.

Unless someone knows of a supported platform that doesn't support getopts, the 
script should be changed to use it instead of getopt. If such a platform 
exists, perhaps using neither (manually parsing args) should be considered - 
it's not too much work, and there are plenty of existing templates for doing 
this to build on, and that would provide the best portability across platforms.


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


[jira] [Commented] (CASSANDRA-5338) scripts fail when paths contain space

2013-03-13 Thread Amichai Rothman (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13600975#comment-13600975
 ] 

Amichai Rothman commented on CASSANDRA-5338:


btw, this problem would be easily alleviated if there wasn't so much 
duplication in the scripts, some of which get updated and others forgotten... 
why not consolidate the duplication into a single master script? For backwards 
compatibility, the existing scripts can continue to exist but just call the 
master script with appropriate parameters.

> scripts fail when paths contain space
> -
>
> Key: CASSANDRA-5338
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5338
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.2.2
> Environment: Kubuntu 12.10 (GNU bash 4.2.37), and Windows XP (msysgit 
> GNU bash 3.1.0)
>Reporter: Amichai Rothman
>Priority: Minor
> Attachments: fix_spaces_in_paths.patch
>
>
> The shell scripts fail when the cassandra or java dirs contain spaces.

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


[Cassandra Wiki] Trivial Update of "GettingStarted" by SylvainLebresne

2013-03-13 Thread Apache Wiki
Dear Wiki user,

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

The "GettingStarted" page has been changed by SylvainLebresne:
http://wiki.apache.org/cassandra/GettingStarted?action=diff&rev1=82&rev2=83

  == Cassandra documentation from DataStax ==
- !DataStax's latest [[http://www.datastax.com/docs/1.1/index|Cassandra 
documentation]] covers topics from installation to troubleshooting, including a 
[[http://www.datastax.com/docs/quick_start/quickstart|Quick Start Guide]].  
Documentation for older releases is also available.
+ !DataStax's latest [[http://www.datastax.com/docs/1.2/index|Cassandra 
documentation]] covers topics from installation to troubleshooting, including a 
[[http://www.datastax.com/docs/quick_start/quickstart|Quick Start Guide]].  
Documentation for older releases is also available.
   
  == Introduction ==
  This document aims to provide a few easy to follow steps to take the 
first-time user from installation, to running single node Cassandra, and 
overview to configure multinode cluster.


[jira] [Resolved] (CASSANDRA-5336) C* crashes with an OOM error when using the Simba Driver on a very wide table

2013-03-13 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne resolved CASSANDRA-5336.
-

Resolution: Not A Problem

bq. I think a simple select count(*) from  limit 1; will do it

If we are talking of CQL3, this is a duplicate of CASSANDRA-3702 that will be 
(but is not currently) solved by CASSANDRA-4415. Namely, 'select count' has to 
count everything (because we have no better way to do it) and is not paged, so 
it is going to OOM if asked to count too much.

bq. It translates into a series of get_range_slice calls which bring back all 
of the rows, and for every row, it brings back every single column name.

Then it means that the Simba Driver should page those get_range_slice calls 
that it generates to avoid the OOM. But that's a Simba Driver bug, not a 
Cassandra one.

So to sum up, we are aware that for CQL3 the COUNT may OOM because it doesn't 
page and we're going to fix it in CASSANDRA-4415. But on the thrift side, 
paging should be done by the client (the simba driver in that instance) and 
this is likely not going to change (as for "shouldn't that throw an exception 
rather than OOMing?", CASSANDRA-3911 might be relevant).


> C* crashes with an OOM error when using the Simba Driver on a very wide table
> -
>
> Key: CASSANDRA-5336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5336
> Project: Cassandra
>  Issue Type: Bug
>  Components: API
>Affects Versions: 1.1.6
> Environment: C* on a Mac with 1GB VM.  Simba ODBC driver
>Reporter: Steven Lowenthal
> Attachments: nhanes600-10k.tarZ, thrift.in, thrift.out
>
>
> The Simba driver executes a version of a count(*) query:
> SELECT SUM(1) from nhanes3 having sum(1) > 0.   It uses this format so ODBC 
> returns a no rows found error if the table is empty.   It translates into a 
> series of get_range_slice calls which bring back all of the rows, and for 
> every row, it brings back every single column name.   C* crashes with an OOM 
> in the thrift code.  The table has almost 600 columns of mixed text and 
> numeric data with many empty values.

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


[Cassandra Wiki] Trivial Update of "GertrudeR" by GertrudeR

2013-03-13 Thread Apache Wiki
Dear Wiki user,

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

The "GertrudeR" page has been changed by GertrudeR:
http://wiki.apache.org/cassandra/GertrudeR

New page:
Nothing to write about me really.<>
Nice to be here and a part of apache.org.<>
I really wish I am useful at all<>
<>
Here is my web-site :: 
[[http://www.Eyelashextensionsreviews.co.uk/reviews/rio-eyelash-extension-kit-reviews/|rio
 Eyelash extension set]]


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

2013-03-13 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-3929:
-

bq. How would you use this filter interface to implement something 
CQL-row-aware?

I'm not sure honestly. I was suggesting that as a simpler alternative to 
modifying the compaction strategy API, which wouldn't be easily CQL-aware 
either because both solution involve dealing with the internal storage engine. 
Now, it would be possible to write something CQL-aware with the filter 
interface above (except maybe that we might want to provide the CFMetaData 
object too), but that would have to be done manually (typically using the 
ColumnCounter class, you could reasonably easily start "dropping" columns once 
you reach the nth CQL-row).

> Support row size limits
> ---
>
> Key: CASSANDRA-3929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3929
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Core
>Reporter: Jonathan Ellis
>Priority: Minor
>  Labels: ponies
> Fix For: 2.0
>
> Attachments: 3929_b.txt, 3929_c.txt, 3929_d.txt, 3929_e.txt, 
> 3929_f.txt, 3929_g_tests.txt, 3929_g.txt, 3929.txt
>
>
> We currently support expiring columns by time-to-live; we've also had 
> requests for keeping the most recent N columns in a row.

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


  1   2   >