date:20121012


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

Jonathan Ellis resolved CASSANDRA-4798.
---

Resolution: Duplicate

Duplicate of CASSANDRA-4587

 ValidationExecutor throws StackOverflowError during repair with LCS
 ---

 Key: CASSANDRA-4798
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4798
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.4
 Environment: JRE 1.6.0_31 on Debian Squeeze
Reporter: Omid Aladini

 During a repair, I get StackOverflowError originating from 
 ValidationExecutor. All CFs had been offline-scrubed after CASSANDRA-4411 fix.
 {code}
 2012-10-12_13:07:39.12921 ERROR 13:07:39,120 Exception in thread 
 Thread[ValidationExecutor:2,1,main]
 2012-10-12_13:07:39.12929 java.lang.StackOverflowError
 2012-10-12_13:07:39.12934 at 
 sun.nio.cs.US_ASCII$Encoder.encodeLoop(Unknown Source)
 2012-10-12_13:07:39.12942 at 
 java.nio.charset.CharsetEncoder.encode(Unknown Source)
 2012-10-12_13:07:39.12950 at 
 java.lang.StringCoding$StringEncoder.encode(Unknown Source)
 2012-10-12_13:07:39.12958 at java.lang.StringCoding.encode(Unknown Source)
 2012-10-12_13:07:39.12964 at java.lang.String.getBytes(Unknown Source)
 2012-10-12_13:07:39.12969 at java.io.RandomAccessFile.open(Native Method)
 2012-10-12_13:07:39.12976 at java.io.RandomAccessFile.init(Unknown 
 Source)
 2012-10-12_13:07:39.12981 at 
 org.apache.cassandra.io.util.RandomAccessReader.init(RandomAccessReader.java:67)
 2012-10-12_13:07:39.12990 at 
 org.apache.cassandra.io.compress.CompressedRandomAccessReader.init(CompressedRandomAccessReader.java:64)
 2012-10-12_13:07:39.13003 at 
 org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:46)
 2012-10-12_13:07:39.13014 at 
 org.apache.cassandra.io.sstable.SSTableReader.openDataReader(SSTableReader.java:1007)
 2012-10-12_13:07:39.13024 at 
 org.apache.cassandra.io.sstable.SSTableScanner.init(SSTableScanner.java:56)
 2012-10-12_13:07:39.13032 at 
 org.apache.cassandra.io.sstable.SSTableBoundedScanner.init(SSTableBoundedScanner.java:41)
 2012-10-12_13:07:39.13043 at 
 org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:869)
 2012-10-12_13:07:39.13053 at 
 org.apache.cassandra.db.compaction.LeveledCompactionStrategy$LeveledScanner.computeNext(LeveledCompactionStrategy.java:247)
 2012-10-12_13:07:39.13066 at 
 org.apache.cassandra.db.compaction.LeveledCompactionStrategy$LeveledScanner.computeNext(LeveledCompactionStrategy.java:240)
 // More stack recursion goes here
 2012-10-12_13:07:39.25061 at 
 org.apache.cassandra.db.compaction.LeveledCompactionStrategy$LeveledScanner.computeNext(LeveledCompactionStrategy.java:240)
 {code}

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

[jira] [Commented] (CASSANDRA-4798) ValidationExecutor throws StackOverflowError during repair with LCS

2012-10-12 Thread Omid Aladini (JIRA)


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

Omid Aladini commented on CASSANDRA-4798:
-

Great! Thanks!

 ValidationExecutor throws StackOverflowError during repair with LCS
 ---

 Key: CASSANDRA-4798
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4798
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.4
 Environment: JRE 1.6.0_31 on Debian Squeeze
Reporter: Omid Aladini

 During a repair, I get StackOverflowError originating from 
 ValidationExecutor. All CFs had been offline-scrubed after CASSANDRA-4411 fix.
 {code}
 2012-10-12_13:07:39.12921 ERROR 13:07:39,120 Exception in thread 
 Thread[ValidationExecutor:2,1,main]
 2012-10-12_13:07:39.12929 java.lang.StackOverflowError
 2012-10-12_13:07:39.12934 at 
 sun.nio.cs.US_ASCII$Encoder.encodeLoop(Unknown Source)
 2012-10-12_13:07:39.12942 at 
 java.nio.charset.CharsetEncoder.encode(Unknown Source)
 2012-10-12_13:07:39.12950 at 
 java.lang.StringCoding$StringEncoder.encode(Unknown Source)
 2012-10-12_13:07:39.12958 at java.lang.StringCoding.encode(Unknown Source)
 2012-10-12_13:07:39.12964 at java.lang.String.getBytes(Unknown Source)
 2012-10-12_13:07:39.12969 at java.io.RandomAccessFile.open(Native Method)
 2012-10-12_13:07:39.12976 at java.io.RandomAccessFile.init(Unknown 
 Source)
 2012-10-12_13:07:39.12981 at 
 org.apache.cassandra.io.util.RandomAccessReader.init(RandomAccessReader.java:67)
 2012-10-12_13:07:39.12990 at 
 org.apache.cassandra.io.compress.CompressedRandomAccessReader.init(CompressedRandomAccessReader.java:64)
 2012-10-12_13:07:39.13003 at 
 org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:46)
 2012-10-12_13:07:39.13014 at 
 org.apache.cassandra.io.sstable.SSTableReader.openDataReader(SSTableReader.java:1007)
 2012-10-12_13:07:39.13024 at 
 org.apache.cassandra.io.sstable.SSTableScanner.init(SSTableScanner.java:56)
 2012-10-12_13:07:39.13032 at 
 org.apache.cassandra.io.sstable.SSTableBoundedScanner.init(SSTableBoundedScanner.java:41)
 2012-10-12_13:07:39.13043 at 
 org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:869)
 2012-10-12_13:07:39.13053 at 
 org.apache.cassandra.db.compaction.LeveledCompactionStrategy$LeveledScanner.computeNext(LeveledCompactionStrategy.java:247)
 2012-10-12_13:07:39.13066 at 
 org.apache.cassandra.db.compaction.LeveledCompactionStrategy$LeveledScanner.computeNext(LeveledCompactionStrategy.java:240)
 // More stack recursion goes here
 2012-10-12_13:07:39.25061 at 
 org.apache.cassandra.db.compaction.LeveledCompactionStrategy$LeveledScanner.computeNext(LeveledCompactionStrategy.java:240)
 {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

buildbot success in ASF Buildbot on cassandra-trunk

2012-10-12 Thread buildbot

The Buildbot has detected a restored build on builder cassandra-trunk while 
building ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/cassandra-trunk/builds/1940

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: portunus_ubuntu

Build Reason: forced: by IRC user driftx on channel #cassandra-dev: cuz I 
have no idea why that happens
Build Source Stamp: HEAD
Blamelist: 

Build succeeded!

sincerely,
 -The Buildbot

[jira] [Created] (CASSANDRA-4799) assertion failure in leveled compaction test

Brandon Williams created CASSANDRA-4799:
---

 Summary: assertion failure in leveled compaction test
 Key: CASSANDRA-4799
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4799
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Brandon Williams
Assignee: Yuki Morishita
 Fix For: 1.2.0


It's somewhat rare, but I'm regularly seeing this failure on trunk:

{{noformat}}
[junit] Testcase: 
testValidationMultipleSSTablePerLevel(org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest):
  FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at 
org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest.testValidationMultipleSSTablePerLevel(LeveledCompactionStrategyTest.java:78)
[junit] 
[junit] 
[junit] Test 
org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest FAILED
{{noformat}}

I suspect there's a deeper problem, since this is a pretty fundamental 
assertion.

--
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-4799) assertion failure in leveled compaction test


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

Brandon Williams updated CASSANDRA-4799:


Description: 
It's somewhat rare, but I'm regularly seeing this failure on trunk:

{noformat}
[junit] Testcase: 
testValidationMultipleSSTablePerLevel(org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest):
  FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at 
org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest.testValidationMultipleSSTablePerLevel(LeveledCompactionStrategyTest.java:78)
[junit] 
[junit] 
[junit] Test 
org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest FAILED
{noformat}

I suspect there's a deeper problem, since this is a pretty fundamental 
assertion.

  was:
It's somewhat rare, but I'm regularly seeing this failure on trunk:

{{noformat}}
[junit] Testcase: 
testValidationMultipleSSTablePerLevel(org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest):
  FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at 
org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest.testValidationMultipleSSTablePerLevel(LeveledCompactionStrategyTest.java:78)
[junit] 
[junit] 
[junit] Test 
org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest FAILED
{{noformat}}

I suspect there's a deeper problem, since this is a pretty fundamental 
assertion.


 assertion failure in leveled compaction test
 

 Key: CASSANDRA-4799
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4799
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Brandon Williams
Assignee: Yuki Morishita
 Fix For: 1.2.0


 It's somewhat rare, but I'm regularly seeing this failure on trunk:
 {noformat}
 [junit] Testcase: 
 testValidationMultipleSSTablePerLevel(org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest):
 FAILED
 [junit] null
 [junit] junit.framework.AssertionFailedError
 [junit]   at 
 org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest.testValidationMultipleSSTablePerLevel(LeveledCompactionStrategyTest.java:78)
 [junit] 
 [junit] 
 [junit] Test 
 org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest FAILED
 {noformat}
 I suspect there's a deeper problem, since this is a pretty fundamental 
 assertion.

--
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-4786) NPE in migration stage after creating an index


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

Brandon Williams commented on CASSANDRA-4786:
-

If what we're seeing here is racy memtable switch behavior, then this is only 
being seen by schema changes since they flush two tables so close together, so 
we have a greater overall problem.  [~slebresne], can you take a look?

 NPE in migration stage after creating an index
 --

 Key: CASSANDRA-4786
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4786
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Brandon Williams
Assignee: Pavel Yaskevich
 Fix For: 1.2.0 beta 2


 The dtests are generating this error after trying to create an index in cql2:
 {noformat}
 ERROR [MigrationStage:1] 2012-10-09 20:54:12,796 CassandraDaemon.java (line 
 132) Exception in thread Thread[MigrationStage:1,5,main]
 java.lang.NullPointerException
 at 
 org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:162)
 at 
 org.apache.cassandra.db.DefsTable.updateColumnFamily(DefsTable.java:549)
 at 
 org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:479)
 at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:344)
 at 
 org.apache.cassandra.service.MigrationManager$1.call(MigrationManager.java:256)
 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 [Thrift:1] 2012-10-09 20:54:12,797 CustomTThreadPoolServer.java (line 
 214) Error occurred during processing of message.
 java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
 java.lang.NullPointerException
 at 
 org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:348)
 at 
 org.apache.cassandra.service.MigrationManager.announce(MigrationManager.java:238)
 at 
 org.apache.cassandra.service.MigrationManager.announceColumnFamilyUpdate(MigrationManager.java:209)
 at 
 org.apache.cassandra.cql.QueryProcessor.processStatement(QueryProcessor.java:714)
 at 
 org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor.java:816)
 at 
 org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1656)
 at 
 org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3721)
 at 
 org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3709)
 at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
 at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
 at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:196)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)
 Caused by: java.util.concurrent.ExecutionException: 
 java.lang.NullPointerException
 at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
 at java.util.concurrent.FutureTask.get(FutureTask.java:83)
 at 
 org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:344)
 ... 13 more
 Caused by: java.lang.NullPointerException
 at 
 org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:162)
 at 
 org.apache.cassandra.db.DefsTable.updateColumnFamily(DefsTable.java:549)
 at 
 org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:479)
 at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:344)
 at 
 org.apache.cassandra.service.MigrationManager$1.call(MigrationManager.java:256)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 ... 3 more
 {noformat}

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

git commit: Sort commitlog segments for replay by id instead of mtime patch by Fabien Rousseau; reviewed by jbellis for CASSANDRA-4793

2012-10-12 Thread jbellis

Updated Branches:
  refs/heads/trunk e19fa37d4 - f81864eba


Sort commitlog segments for replay by id instead of mtime
patch by Fabien Rousseau; reviewed by jbellis for CASSANDRA-4793


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

Branch: refs/heads/trunk
Commit: f81864ebae0f7e098a21ab957921a7a3f4ad1b3f
Parents: e19fa37
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Oct 12 10:26:39 2012 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Oct 12 10:26:39 2012 -0500

--
 CHANGES.txt|1 +
 .../apache/cassandra/db/commitlog/CommitLog.java   |2 +-
 .../cassandra/db/commitlog/CommitLogSegment.java   |   12 
 .../org/apache/cassandra/io/util/FileUtils.java|8 
 4 files changed, 14 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f81864eb/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 94f65ad..0edd211 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 1.2-beta2
+ * Sort commitlog segments for replay by id instead of mtime (CASSANDRA-4793)
  * Make hint delivery asynchronous (CASSANDRA-4761)
  * Pluggable Thrift transport factories for CLI and cqlsh (CASSANDRA-4609, 
4610)
  * cassandra-cli: allow Double value type to be inserted to a column 
(CASSANDRA-4661)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f81864eb/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
index 22abcb7..74e57a6 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
@@ -122,7 +122,7 @@ public class CommitLog implements CommitLogMBean
 }
 else
 {
-Arrays.sort(files, new FileUtils.FileComparator());
+Arrays.sort(files, new 
CommitLogSegment.CommitLogSegmentFileComparator());
 logger.info(Replaying  + StringUtils.join(files, , ));
 replayed = recover(files);
 logger.info(Log replay complete,  + replayed +  replayed 
mutations);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f81864eb/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
index ecff23b..d292aef 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
@@ -23,6 +23,7 @@ import java.io.RandomAccessFile;
 import java.nio.MappedByteBuffer;
 import java.nio.channels.FileChannel;
 import java.util.Collection;
+import java.util.Comparator;
 import java.util.HashMap;
 import java.util.UUID;
 import java.util.concurrent.atomic.AtomicInteger;
@@ -374,4 +375,15 @@ public class CommitLogSegment
 {
 return buffer.position();
 }
+
+
+public static class CommitLogSegmentFileComparator implements 
ComparatorFile
+{
+public int compare(File f, File f2)
+{
+CommitLogDescriptor desc = 
CommitLogDescriptor.fromFileName(f.getName());
+CommitLogDescriptor desc2 = 
CommitLogDescriptor.fromFileName(f2.getName());
+return (int) (desc.id - desc2.id);
+}
+}
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f81864eb/src/java/org/apache/cassandra/io/util/FileUtils.java
--
diff --git a/src/java/org/apache/cassandra/io/util/FileUtils.java 
b/src/java/org/apache/cassandra/io/util/FileUtils.java
index 42b240b..bc4d67e 100644
--- a/src/java/org/apache/cassandra/io/util/FileUtils.java
+++ b/src/java/org/apache/cassandra/io/util/FileUtils.java
@@ -245,14 +245,6 @@ public class FileUtils
 }
 }
 
-public static class FileComparator implements ComparatorFile
-{
-public int compare(File f, File f2)
-{
-return (int)(f.lastModified() - f2.lastModified());
-}
-}
-
 public static void createDirectory(String directory)
 {
 createDirectory(new File(directory));

[jira] [Updated] (CASSANDRA-4793) Commitlog files replayed but not in the order of their ids


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

Jonathan Ellis updated CASSANDRA-4793:
--

 Reviewer: jbellis
Affects Version/s: (was: 1.1.5)
   1.1.0
Fix Version/s: 1.2.0 beta 2
   Labels: commitlog  (was: )

committed, thanks!

 Commitlog files replayed but not in the order of their ids
 --

 Key: CASSANDRA-4793
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4793
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Fabien Rousseau
Priority: Minor
  Labels: commitlog
 Fix For: 1.2.0 beta 2

 Attachments: 
 4793-potential-patch-for-correctly-ordering-commit-log-fi.patch, 
 4793-trunk-potential-patch-for-correctly-ordering-commit-log-fi.patch


 I noticed that the commitlog files were not replayed in the order of their 
 ids.
 It seems that they are sorted by last modification date before being 
 replayed, but this does not corresponds to their ids.
 Moreover, last modification date is changed when a file is copied, so, this 
 could also change the order of archived commitlogs.
 Maybe it's safer to sort them using the id in the file name ?

--
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-4481) Commitlog not replayed after restart - data lost

2012-10-12 Thread Steven Haufe (JIRA)


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

Steven Haufe commented on CASSANDRA-4481:
-

I have seen this same issue of data loss on restart with fresh install of 
cassandra 1.1.3.

Fixed it by upgrading to cassandra 1.1.5 and then used the instruction in 
https://issues.apache.org/jira/browse/CASSANDRA-4481?focusedCommentId=13435597page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13435597
 to reload the data




 Commitlog not replayed after restart - data lost
 

 Key: CASSANDRA-4481
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4481
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.2
 Environment: Single node cluster on 64Bit CentOS
Reporter: Ivo Meißner
Priority: Critical

 When data is written to the commitlog and I restart the machine, all commited 
 data is lost that has not been flushed to disk. 
 In the startup logs it says that it replays the commitlog successfully, but 
 the data is not available then. 
 When I open the commitlog file in an editor I can see the added data, but 
 after the restart it cannot be fetched from cassandra. 
 {code}
  INFO 09:59:45,362 Replaying 
 /var/myproject/cassandra/commitlog/CommitLog-83203377067.log
  INFO 09:59:45,476 Finished reading 
 /var/myproject/cassandra/commitlog/CommitLog-83203377067.log
  INFO 09:59:45,476 Log replay complete, 0 replayed mutations
 {code}

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

[jira] [Commented] (CASSANDRA-4787) Escape characters in values for prepared statement

2012-10-12 Thread Ivan Velykorodnyy (JIRA)


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

Ivan Velykorodnyy commented on CASSANDRA-4787:
--

Right, as long as there are binary buffers passed no need to escape chars. This 
is nice and sorry I should have tried it first. Thx

 Escape characters in values for prepared statement
 --

 Key: CASSANDRA-4787
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4787
 Project: Cassandra
  Issue Type: Improvement
  Components: API, Core
Affects Versions: 1.1.5
Reporter: Ivan Velykorodnyy

 e.g. if I pass String value=abc'efg as a parameter to prepared statement, 
 would be nice if API does escape substitution: abc''efg.
 * Are there other characters to escape?
 * I think it should be default behavior for prepared statements.

--
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-4787) Escape characters in values for prepared statement


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

Jonathan Ellis resolved CASSANDRA-4787.
---

Resolution: Not A Problem

 Escape characters in values for prepared statement
 --

 Key: CASSANDRA-4787
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4787
 Project: Cassandra
  Issue Type: Improvement
  Components: API, Core
Affects Versions: 1.1.5
Reporter: Ivan Velykorodnyy

 e.g. if I pass String value=abc'efg as a parameter to prepared statement, 
 would be nice if API does escape substitution: abc''efg.
 * Are there other characters to escape?
 * I think it should be default behavior for prepared statements.

--
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-4734) Move CQL3 consistency to protocol

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

Sylvain Lebresne updated CASSANDRA-4734:

Attachment: 0002-Thrift-generated-file-diffs-2.txt
0001-Move-consistency-level-to-the-protocol-level-2.txt

The patches needed some rebasing, but after reflexion, I also think that we
should keep CASSANDRA-4448 even with that. I think the most of the arguments in
that issue still hold even if we move the consistency to the protocol level. So
v2 attached keep that feature.

Move CQL3 consistency to protocol
-

Key: CASSANDRA-4734
URL: https://issues.apache.org/jira/browse/CASSANDRA-4734
Project: Cassandra
Issue Type: Task
Components: API
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
Fix For: 1.2.0 beta 2

Attachments: 0001-Move-consistency-level-to-the-protocol-level-2.txt,
0001-Move-consistency-level-to-the-protocol-level.txt,
0002-Remove-remains-of-4448.txt, 0002-Thrift-generated-file-diffs-2.txt,
0003-Thrift-generated-file-diffs.txt

Currently, in CQL3, you set the consistency level of an operation in
the language, eg 'SELECT * FROM foo USING CONSISTENCY QUORUM'. It now
looks like this was a mistake, and that consistency should be set at
the protocol level, i.e. as a separate parameter along with the query.
The reasoning is that the CL applies to the guarantee provided by the
operation being successful, not to the query itself. Specifically,
having the CL being part of the language means that CL is opaque to
low level client libraries without themselves parsing the CQL, which
we want to avoid. Thus,
- Those libraries can't implement automatic retries policy, where a query
would be retried with a smaller CL. (I'm aware that this is often a Bad
Idea, but it does have legitimate uses and not having that available is seen
as a regression from the Thrift api.)
- We had to introduce CASSANDRA-4448 to allow the client to configure some
form of default CL since the library can't handle that anymore, which is
hackish.
- Executing prepared statements with different CL requires preparing multiple
statements.
- CL only makes sense for BATCH operations as a whole, not the sub-statements
within the batch. Currently CQL3 fixes that by validating the given CLs
match, but it would be much more clear if the CL was on the protocol side.

--
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-4734) Move CQL3 consistency to protocol

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

Jonathan Ellis commented on CASSANDRA-4734:
---

I'm not sure how per-CF CL interacts w/ protocol level. Is there a CL.DEFAULT
now then, or do you pass null? How do we deal w/ different default CL in a
batch?

Seems a lot cleaner to me to leave it protocol-only.

Move CQL3 consistency to protocol
-

[jira] [Commented] (CASSANDRA-4734) Move CQL3 consistency to protocol

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

Sylvain Lebresne commented on CASSANDRA-4734:
-

bq. Is there a CL.DEFAULT now then, or do you pass null?

You pass null.

bq. How do we deal w/ different default CL in a batch?

That's a good point, but it's more a problem of CASSANDRA-4448 than of this
patch really. And the solution we've adopted in CASSANDRA-4448 was to refuse a
batch without an explicitly set CL unless all the default CLs are the same
(that being said I forgot to re-add that part to my v2 but I'll update the
patch shortly).

bq. Seems a lot cleaner to me to leave it protocol-only

As said above, I think that CASSANDRA-4448 and this are fairly orthogonal
problems. In particular, it was my mistake to think in my first version that
moving the CL to the protocol level was making CASSANDRA-4448 in any way
irrelevant but it's really not.

Move CQL3 consistency to protocol
-

[jira] [Updated] (CASSANDRA-4734) Move CQL3 consistency to protocol


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

Sylvain Lebresne updated CASSANDRA-4734:


Attachment: (was: 
0001-Move-consistency-level-to-the-protocol-level-2.txt)

 Move CQL3 consistency to protocol
 -

 Key: CASSANDRA-4734
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4734
 Project: Cassandra
  Issue Type: Task
  Components: API
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
 Fix For: 1.2.0 beta 2

 Attachments: 0001-Move-consistency-level-to-the-protocol-level.txt, 
 0002-Remove-remains-of-4448.txt, 0002-Thrift-generated-file-diffs-2.txt, 
 0003-Thrift-generated-file-diffs.txt


 Currently, in CQL3, you set the consistency level of an operation in
 the language, eg 'SELECT * FROM foo USING CONSISTENCY QUORUM'.  It now
 looks like this was a mistake, and that consistency should be set at
 the protocol level, i.e. as a separate parameter along with the query.
 The reasoning is that the CL applies to the guarantee provided by the
 operation being successful, not to the query itself.  Specifically,
 having the CL being part of the language means that CL is opaque to
 low level client libraries without themselves parsing the CQL, which
 we want to avoid.  Thus,
 - Those libraries can't implement automatic retries policy, where a query 
 would be retried with a smaller CL.  (I'm aware that this is often a Bad 
 Idea, but it does have legitimate uses and not having that available is seen 
 as a regression from the Thrift api.)
 - We had to introduce CASSANDRA-4448 to allow the client to configure some  
 form of default CL since the library can't handle that anymore, which is  
 hackish.
 - Executing prepared statements with different CL requires preparing multiple 
 statements.
 - CL only makes sense for BATCH operations as a whole, not the sub-statements 
 within the batch. Currently CQL3 fixes that by validating the given CLs 
 match, but it would be much more clear if the CL was on the protocol side.

--
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-4734) Move CQL3 consistency to protocol


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

Sylvain Lebresne updated CASSANDRA-4734:


Attachment: 0001-Move-consistency-level-to-the-protocol-level-2.txt

(I've updated my v2 to keep the current behavior of the default CL concerning 
batches)

 Move CQL3 consistency to protocol
 -

 Key: CASSANDRA-4734
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4734
 Project: Cassandra
  Issue Type: Task
  Components: API
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
 Fix For: 1.2.0 beta 2

 Attachments: 0001-Move-consistency-level-to-the-protocol-level-2.txt, 
 0001-Move-consistency-level-to-the-protocol-level.txt, 
 0002-Remove-remains-of-4448.txt, 0002-Thrift-generated-file-diffs-2.txt, 
 0003-Thrift-generated-file-diffs.txt


 Currently, in CQL3, you set the consistency level of an operation in
 the language, eg 'SELECT * FROM foo USING CONSISTENCY QUORUM'.  It now
 looks like this was a mistake, and that consistency should be set at
 the protocol level, i.e. as a separate parameter along with the query.
 The reasoning is that the CL applies to the guarantee provided by the
 operation being successful, not to the query itself.  Specifically,
 having the CL being part of the language means that CL is opaque to
 low level client libraries without themselves parsing the CQL, which
 we want to avoid.  Thus,
 - Those libraries can't implement automatic retries policy, where a query 
 would be retried with a smaller CL.  (I'm aware that this is often a Bad 
 Idea, but it does have legitimate uses and not having that available is seen 
 as a regression from the Thrift api.)
 - We had to introduce CASSANDRA-4448 to allow the client to configure some  
 form of default CL since the library can't handle that anymore, which is  
 hackish.
 - Executing prepared statements with different CL requires preparing multiple 
 statements.
 - CL only makes sense for BATCH operations as a whole, not the sub-statements 
 within the batch. Currently CQL3 fixes that by validating the given CLs 
 match, but it would be much more clear if the CL was on the protocol side.

--
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-4734) Move CQL3 consistency to protocol

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

Jonathan Ellis commented on CASSANDRA-4734:
---

bq. it was my mistake to think in my first version that moving the CL to the
protocol level was making CASSANDRA-4448 in any way irrelevant but it's really
not.

But I'm totally on board with your first inclination. Why do you now think
it's still relevant?

Move CQL3 consistency to protocol
-

[jira] [Commented] (CASSANDRA-4734) Move CQL3 consistency to protocol

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

Jonathan Ellis commented on CASSANDRA-4734:
---

To elaborate: ConsistencyLevel is part of application logic, not data model.
So it really belongs in the protocol and client layer, which is where this
ticket pushes it.

Pushing it into CFMetadata in 4448 was consistent with it's part of the data
model / query language approach we used to take, but now that we're fixing
that it no longer makes sense to enshrine it server-side.

Move CQL3 consistency to protocol
-

[jira] [Created] (CASSANDRA-4800) cqlsh help is obsolete for cql3 DDL

Jonathan Ellis created CASSANDRA-4800:
-

 Summary: cqlsh help is obsolete for cql3 DDL
 Key: CASSANDRA-4800
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4800
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.2.0 beta 1
Reporter: Jonathan Ellis
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 1.2.0 beta 2


For example, new syntax for CREATE KEYSPACE is

create keyspace foo with replication = {'class': 'SimpleStrategy', 
'replication_factor': 1}


--
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-4584) Add cqlsh syntax to enable request tracing


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

Jonathan Ellis reopened CASSANDRA-4584:
---


I'm getting errors on a simple example.  (On Windows.)

{code}
create keyspace foo with replication = {'class': 'SimpleStrategy', 
'replication_factor': '1'};
use foo;
create table one (id int primary key, c int);
TRACING ON;
insert into one (id, c) values (1, 2);

value '\x7f\x00\x00\x01' (in col 'source') can't be deserialized as inet: 
'module' object has no attribute 'inet_ntop'
{code}


 Add cqlsh syntax to enable request tracing
 --

 Key: CASSANDRA-4584
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584
 Project: Cassandra
  Issue Type: Sub-task
Affects Versions: 1.2.0 beta 1
Reporter: Jonathan Ellis
Assignee: Aleksey Yeschenko
  Labels: cql3
 Fix For: 1.2.0 beta 2

 Attachments: 4584.patch, 4584.patch, 4584.patch, 4584.patch, 
 4584.patch, CASSANDRA-4584-INCOMPLETE.txt




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

[jira] [Commented] (CASSANDRA-4584) Add cqlsh syntax to enable request tracing

2012-10-12 Thread Aleksey Yeschenko (JIRA)


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

Aleksey Yeschenko commented on CASSANDRA-4584:
--

OS X:

~/Repos/ASF/cassandra ➤ bin/cqlsh 
Connected to Test Cluster at localhost:9160.
[cqlsh 2.3.0 | Cassandra 1.2.0-beta1-SNAPSHOT | CQL spec 3.0.0 | Thrift 
protocol 19.34.0]
Use HELP for help.
cqlsh create keyspace foo with replication = {'class': 'SimpleStrategy', 
'replication_factor': '1'};
cqlsh use foo;
cqlsh:foo create table one (id int primary key, c int);
cqlsh:foo TRACING ON;
Now tracing requests.
cqlsh:foo insert into one (id, c) values (1, 2);
 session_id   | event_id | activity 

   
| happened_at  | source| source_elapsed | thread
--+--+-+--+---++--
 df2cfa90-14b1-11e2--242d50cf1fdf | 2012-10-13 00:14:56+0300 | 
Mutations/ConsistencyLevel are [RowMutation(keyspace='foo', key='0001', 
modifications=[ColumnFamily(one 
[:false:0@1350076496063000,c:false:4@1350076496063000,])])]/ONE | 2012-10-13 
00:14:56+0300 | 127.0.0.1 |   1417 | Thrift:1
 df2cfa90-14b1-11e2--242d50cf1fdf | 2012-10-13 00:14:56+0300 |  
 insert 
writing local RowMutation(keyspace='foo', key='0001', modifications=[one]) 
| 2012-10-13 00:14:56+0300 | 127.0.0.1 |   5774 | Thrift:1
 df2cfa90-14b1-11e2--242d50cf1fdf | 2012-10-13 00:14:56+0300 |  

 applying mutation 
| 2012-10-13 00:14:56+0300 | 127.0.0.1 |   6317 | MutationStage:34
 df2cfa90-14b1-11e2--242d50cf1fdf | 2012-10-13 00:14:56+0300 |  

   1 regions now allocated in org.apache.cassandra.utils.SlabAllocator@c303a60 
| 2012-10-13 00:14:56+0300 | 127.0.0.1 |   6531 | MutationStage:34
 df2cfa90-14b1-11e2--242d50cf1fdf | 2012-10-13 00:14:56+0300 |  
 completed executing 
TraceSessionWrapper{state=org.apache.cassandra.tracing.TraceState@962e703, 
callable=null} | 2012-10-13 00:14:56+0300 | 127.0.0.1 |   6892 | 
MutationStage:34

cqlsh:foo 

Same output on Ubuntu 12.04. Might be Windows specific.

 Add cqlsh syntax to enable request tracing
 --

 Key: CASSANDRA-4584
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584
 Project: Cassandra
  Issue Type: Sub-task
Affects Versions: 1.2.0 beta 1
Reporter: Jonathan Ellis
Assignee: Aleksey Yeschenko
  Labels: cql3
 Fix For: 1.2.0 beta 2

 Attachments: 4584.patch, 4584.patch, 4584.patch, 4584.patch, 
 4584.patch, CASSANDRA-4584-INCOMPLETE.txt




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

[jira] [Created] (CASSANDRA-4801) inet datatype does not work with cqlsh on windows

Jonathan Ellis created CASSANDRA-4801:
-

 Summary: inet datatype does not work with cqlsh on windows
 Key: CASSANDRA-4801
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4801
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.2.0 beta 1
 Environment: Windows 7, Python 2.7.2
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
 Fix For: 1.2.0 beta 2


{noformat}
create keyspace foo with replication = {'class': 'SimpleStrategy', 
'replication_factor': '1'};
use foo;
create table one (id int primary key, c int);
TRACING ON;
insert into one (id, c) values (1, 2);

value '\x7f\x00\x00\x01' (in col 'source') can't be deserialized as inet: 
'module' object has no attribute 'inet_ntop'
{noformat}

--
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-4584) Add cqlsh syntax to enable request tracing


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

Jonathan Ellis resolved CASSANDRA-4584.
---

Resolution: Fixed

looks like a general problem w/ inet on windows: CASSANDRA-4801

 Add cqlsh syntax to enable request tracing
 --

 Key: CASSANDRA-4584
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584
 Project: Cassandra
  Issue Type: Sub-task
Affects Versions: 1.2.0 beta 1
Reporter: Jonathan Ellis
Assignee: Aleksey Yeschenko
  Labels: cql3
 Fix For: 1.2.0 beta 2

 Attachments: 4584.patch, 4584.patch, 4584.patch, 4584.patch, 
 4584.patch, CASSANDRA-4584-INCOMPLETE.txt




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

[jira] [Commented] (CASSANDRA-4481) Commitlog not replayed after restart - data lost

2012-10-12 Thread Florent Clairambault (JIRA)


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

Florent Clairambault commented on CASSANDRA-4481:
-

I doesn't work, it failed again a week ago on a 1.1.5 that was running for a 
little bit.

First of all, it's a commitLog writing and/or reading issue, so if you flush 
your data frequently (every hour and in the stop command of the rc.d's script) 
you reduce your risk of big data losses. You can lose days of data if you don't 
do that. Restarting cassandra and going 2 days in the past is a very unpleasant 
situation.

So here is the new process I applied to fix my data (which is in fact 
restarting from scatch [except we keep the data]):
- Export the keyspace's schema
{code}
cassandra-cli -k ks schema.txt EOF 
show schema;
exit;
EOF
{code}
- Simplify the export (all CF with key_validation_class in AsciiType, 
default_validation_class in UTF8Type for most CF except the one that contains 
binary data where I used BytesTypes).

I simplify an export like that:
{code}
create column family User
  with column_type = 'Standard'
  and comparator = 'AsciiType'
  and default_validation_class = 'UTF8Type'
  and key_validation_class = 'AsciiType'
  and read_repair_chance = 0.1
  and dclocal_read_repair_chance = 0.0
  and gc_grace = 864000
  and min_compaction_threshold = 4
  and max_compaction_threshold = 32
  and replicate_on_write = true
  and compaction_strategy = 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
  and caching = 'KEYS_ONLY'
  and column_metadata = [
{column_name : 'domain',
validation_class : UTF8Type,
index_name : 'User_domain_idx',
index_type : 0},
{column_name : 'username',
validation_class : UTF8Type,
index_name : 'User_username',
index_type : 0}]
  and compression_options = {'sstable_compression' : 
'org.apache.cassandra.io.compress.SnappyCompressor'};
{code}

To something like that:
{code}
create column family User
  with column_type = 'Standard'
  and key_validation_class = 'AsciiType'
  and comparator = 'AsciiType'
  and default_validation_class = 'UTF8Type'
  and column_metadata = [
{column_name : 'domain', validation_class : UTF8Type, index_type : 0},
{column_name : 'username', validation_class : UTF8Type, index_type : 0}];
{code}

During this simplification process, I discovered that some 
default_validation_class had incorrect type, so maybe it comes from that. It 
seems strange that we could confuse cassandra this way, but this problem is 
indeed very strange...

- Stop cassandra
- Move the keyspace folder to somewhere else (mkdir backup; mv ks backup)
- Start cassandra (Not having a keyspace folder is like not having any data, 
it's not a problem).
- Delete the keyspace (I know deletion creates snapshots and moving is 
unecessary but it's easier to use sstableloader that way)
- Recreate the keyspace with the schema exported and simplified
- Use sstableloader to import data:
{code}
cd backup; find ks -type d -exec sstableloader -d localhost {} \;
{code}

NOTE: Don't think about replaying your commitLogs with your new schema, the 
column families won't have the same id.

Any empty cassandra instance startup does at least 1 mutation replay because of 
the system keyspace. So I still think 0 replayed mutations should never occur 
and if they do, we should have some warning with them. And if it's indeed a CF 
that doesn't fully exist, it should be reported at startup.

I hope we can find a way to reproduce it.

 Commitlog not replayed after restart - data lost
 

 Key: CASSANDRA-4481
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4481
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.2
 Environment: Single node cluster on 64Bit CentOS
Reporter: Ivo Meißner
Priority: Critical

 When data is written to the commitlog and I restart the machine, all commited 
 data is lost that has not been flushed to disk. 
 In the startup logs it says that it replays the commitlog successfully, but 
 the data is not available then. 
 When I open the commitlog file in an editor I can see the added data, but 
 after the restart it cannot be fetched from cassandra. 
 {code}
  INFO 09:59:45,362 Replaying 
 /var/myproject/cassandra/commitlog/CommitLog-83203377067.log
  INFO 09:59:45,476 Finished reading 
 /var/myproject/cassandra/commitlog/CommitLog-83203377067.log
  INFO 09:59:45,476 Log replay complete, 0 replayed mutations
 {code}

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

[jira] [Commented] (CASSANDRA-4801) inet datatype does not work with cqlsh on windows


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

Brandon Williams commented on CASSANDRA-4801:
-

It looks like we can check socket.has_ipv6 to decide between inet_ntop and 
inet_ntoa, and if there are more than 4 bytes just display the escaped bytes.  
In other words, ipv4 would work on windows but not ipv6.

 inet datatype does not work with cqlsh on windows
 -

 Key: CASSANDRA-4801
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4801
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.2.0 beta 1
 Environment: Windows 7, Python 2.7.2
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
  Labels: cqlsh, windows
 Fix For: 1.2.0 beta 2


 {noformat}
 create keyspace foo with replication = {'class': 'SimpleStrategy', 
 'replication_factor': '1'};
 use foo;
 create table one (id int primary key, c int);
 TRACING ON;
 insert into one (id, c) values (1, 2);
 value '\x7f\x00\x00\x01' (in col 'source') can't be deserialized as inet: 
 'module' object has no attribute 'inet_ntop'
 {noformat}

--
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-4802) Regular startup log has confusing Bootstrap/Replace/Move completed! without boostrap, replace, or move

2012-10-12 Thread Karl Mueller (JIRA)

Karl Mueller created CASSANDRA-4802:
---

 Summary: Regular startup log has confusing Bootstrap/Replace/Move 
completed! without boostrap, replace, or move
 Key: CASSANDRA-4802
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4802
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.0.12
 Environment: RHEL6, JDK1.6
Reporter: Karl Mueller
Priority: Trivial


A regular startup completes successfully, but it has a confusing message the 
end of the startup:

  INFO 15:19:29,137 Bootstrap/Replace/Move completed! Now serving reads.

This happens despite no bootstrap, replace, or move.

While purely cosmetic, this makes you wonder what the node just did - did it 
just bootstrap?!  It should simply read something like Startup completed! Now 
serving reads unless it actually has done one of the actions in the error 
message.



Complete log at the end:


INFO 15:13:30,522 Log replay complete, 6274 replayed mutations
 INFO 15:13:30,527 Cassandra version: 1.0.12
 INFO 15:13:30,527 Thrift API version: 19.20.0
 INFO 15:13:30,527 Loading persisted ring state
 INFO 15:13:30,541 Starting up server gossip
 INFO 15:13:30,542 Enqueuing flush of Memtable-LocationInfo@1828864224(29/36 
serialized/live bytes, 1 ops)
 INFO 15:13:30,543 Writing Memtable-LocationInfo@1828864224(29/36 
serialized/live bytes, 1 ops)
 INFO 15:13:30,550 Completed flushing 
/data2/data-cassandra/system/LocationInfo-hd-274-Data.db (80 bytes)
 INFO 15:13:30,563 Starting Messaging Service on port 7000
 INFO 15:13:30,571 Using saved token 31901471898837980949691369446728269823
 INFO 15:13:30,572 Enqueuing flush of Memtable-LocationInfo@294410307(53/66 
serialized/live bytes, 2 ops)
 INFO 15:13:30,573 Writing Memtable-LocationInfo@294410307(53/66 
serialized/live bytes, 2 ops)
 INFO 15:13:30,579 Completed flushing 
/data2/data-cassandra/system/LocationInfo-hd-275-Data.db (163 bytes)
 INFO 15:13:30,581 Node kaos-cass02.xxx/1.2.3.4 state jump to normal
 INFO 15:13:30,598 Bootstrap/Replace/Move completed! Now serving reads.
 INFO 15:13:30,600 Will not load MX4J, mx4j-tools.jar is not in the classpath


--
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-4481) Commitlog not replayed after restart - data lost


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

Jonathan Ellis commented on CASSANDRA-4481:
---

Commitlog failing to replay is CASSANDRA-4782.

 Commitlog not replayed after restart - data lost
 

 Key: CASSANDRA-4481
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4481
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.2
 Environment: Single node cluster on 64Bit CentOS
Reporter: Ivo Meißner
Priority: Critical

 When data is written to the commitlog and I restart the machine, all commited 
 data is lost that has not been flushed to disk. 
 In the startup logs it says that it replays the commitlog successfully, but 
 the data is not available then. 
 When I open the commitlog file in an editor I can see the added data, but 
 after the restart it cannot be fetched from cassandra. 
 {code}
  INFO 09:59:45,362 Replaying 
 /var/myproject/cassandra/commitlog/CommitLog-83203377067.log
  INFO 09:59:45,476 Finished reading 
 /var/myproject/cassandra/commitlog/CommitLog-83203377067.log
  INFO 09:59:45,476 Log replay complete, 0 replayed mutations
 {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-4481) Commitlog not replayed after restart - data lost

2012-10-12 Thread Florent Clairambault (JIRA)


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

Florent Clairambault updated CASSANDRA-4481:


Comment: was deleted

(was: I doesn't work, it failed again a week ago on a 1.1.5 that was running 
for a little bit.

First of all, it's a commitLog writing and/or reading issue, so if you flush 
your data frequently (every hour and in the stop command of the rc.d's script) 
you reduce your risk of big data losses. You can lose days of data if you don't 
do that. Restarting cassandra and going 2 days in the past is a very unpleasant 
situation.

So here is the new process I applied to fix my data (which is in fact 
restarting from scatch [except we keep the data]):
- Export the keyspace's schema
{code}
cassandra-cli -k ks schema.txt EOF 
show schema;
exit;
EOF
{code}
- Simplify the export (all CF with key_validation_class in AsciiType, 
default_validation_class in UTF8Type for most CF except the one that contains 
binary data where I used BytesTypes).

I simplify an export like that:
{code}
create column family User
  with column_type = 'Standard'
  and comparator = 'AsciiType'
  and default_validation_class = 'UTF8Type'
  and key_validation_class = 'AsciiType'
  and read_repair_chance = 0.1
  and dclocal_read_repair_chance = 0.0
  and gc_grace = 864000
  and min_compaction_threshold = 4
  and max_compaction_threshold = 32
  and replicate_on_write = true
  and compaction_strategy = 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
  and caching = 'KEYS_ONLY'
  and column_metadata = [
{column_name : 'domain',
validation_class : UTF8Type,
index_name : 'User_domain_idx',
index_type : 0},
{column_name : 'username',
validation_class : UTF8Type,
index_name : 'User_username',
index_type : 0}]
  and compression_options = {'sstable_compression' : 
'org.apache.cassandra.io.compress.SnappyCompressor'};
{code}

To something like that:
{code}
create column family User
  with column_type = 'Standard'
  and key_validation_class = 'AsciiType'
  and comparator = 'AsciiType'
  and default_validation_class = 'UTF8Type'
  and column_metadata = [
{column_name : 'domain', validation_class : UTF8Type, index_type : 0},
{column_name : 'username', validation_class : UTF8Type, index_type : 0}];
{code}

During this simplification process, I discovered that some 
default_validation_class had incorrect type, so maybe it comes from that. It 
seems strange that we could confuse cassandra this way, but this problem is 
indeed very strange...

- Stop cassandra
- Move the keyspace folder to somewhere else (mkdir backup; mv ks backup)
- Start cassandra (Not having a keyspace folder is like not having any data, 
it's not a problem).
- Delete the keyspace (I know deletion creates snapshots and moving is 
unecessary but it's easier to use sstableloader that way)
- Recreate the keyspace with the schema exported and simplified
- Use sstableloader to import data:
{code}
cd backup; find ks -type d -exec sstableloader -d localhost {} \;
{code}

NOTE: Don't think about replaying your commitLogs with your new schema, the 
column families won't have the same id.

Any empty cassandra instance startup does at least 1 mutation replay because of 
the system keyspace. So I still think 0 replayed mutations should never occur 
and if they do, we should have some warning with them. And if it's indeed a CF 
that doesn't fully exist, it should be reported at startup.

I hope we can find a way to reproduce it.)

 Commitlog not replayed after restart - data lost
 

 Key: CASSANDRA-4481
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4481
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.2
 Environment: Single node cluster on 64Bit CentOS
Reporter: Ivo Meißner
Priority: Critical

 When data is written to the commitlog and I restart the machine, all commited 
 data is lost that has not been flushed to disk. 
 In the startup logs it says that it replays the commitlog successfully, but 
 the data is not available then. 
 When I open the commitlog file in an editor I can see the added data, but 
 after the restart it cannot be fetched from cassandra. 
 {code}
  INFO 09:59:45,362 Replaying 
 /var/myproject/cassandra/commitlog/CommitLog-83203377067.log
  INFO 09:59:45,476 Finished reading 
 /var/myproject/cassandra/commitlog/CommitLog-83203377067.log
  INFO 09:59:45,476 Log replay complete, 0 replayed mutations
 {code}

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

[jira] [Commented] (CASSANDRA-4481) Commitlog not replayed after restart - data lost

2012-10-12 Thread Florent Clairambault (JIRA)


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

Florent Clairambault commented on CASSANDRA-4481:
-

Thank you. It makes a lot of sense (and the code is amazingly clear). That's 
why the only way to be able to read the commitLogs was to delete the previous 
one.

I deleted my last comment (about recreating the CF + re-loading the data with 
sstableloader), as it won't help anyone. 

In the mean time, people wanting to upgrade cassandra between 1.1.0 and 1.1.5 
can flush (before stopping the old cassandra) and delete commit logs (before 
starting the new cassandra).

 Commitlog not replayed after restart - data lost
 

 Key: CASSANDRA-4481
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4481
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.2
 Environment: Single node cluster on 64Bit CentOS
Reporter: Ivo Meißner
Priority: Critical

 When data is written to the commitlog and I restart the machine, all commited 
 data is lost that has not been flushed to disk. 
 In the startup logs it says that it replays the commitlog successfully, but 
 the data is not available then. 
 When I open the commitlog file in an editor I can see the added data, but 
 after the restart it cannot be fetched from cassandra. 
 {code}
  INFO 09:59:45,362 Replaying 
 /var/myproject/cassandra/commitlog/CommitLog-83203377067.log
  INFO 09:59:45,476 Finished reading 
 /var/myproject/cassandra/commitlog/CommitLog-83203377067.log
  INFO 09:59:45,476 Log replay complete, 0 replayed mutations
 {code}

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

[jira] [Commented] (CASSANDRA-4783) AE in cql3 select

2012-10-12 Thread Ian Flatness (JIRA)


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

Ian Flatness commented on CASSANDRA-4783:
-

I have also found this issue when running update or insert on an existing 
column with both list and noncollection modifications. 
For example update my_table insert set list_col = [...], noncollection_col = 
'val' where key='row_key';

{noformat}
ERROR [Thrift:1] 2012-10-12 17:08:10,911 CassandraDaemon.java (line 132) 
Exception in thread Thread[Thrift:1,5,main]
java.lang.AssertionError
at 
org.apache.cassandra.cql3.statements.ColumnGroupMap.getCollection(ColumnGroupMap.java:85)
at 
org.apache.cassandra.cql3.statements.UpdateStatement.mutationForKey(UpdateStatement.java:251)
at 
org.apache.cassandra.cql3.statements.UpdateStatement.getMutations(UpdateStatement.java:134)
at 
org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:83)
at 
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:130)
at 
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:138)
at 
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1677)
at 
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3721)
at 
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3709)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at 
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:193)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{noformat}

 AE in cql3 select
 -

 Key: CASSANDRA-4783
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4783
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Reporter: Brandon Williams
Assignee: Sylvain Lebresne
 Fix For: 1.2.0 beta 2


 Caused by 'select * from foo where key='blah' and column in (...)
 {noformat}
 ERROR 18:35:46,169 Exception in thread Thread[Thrift:11,5,main]
 java.lang.AssertionError
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.getRequestedColumns(SelectStatement.java:443)
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.makeFilter(SelectStatement.java:312)
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:200)
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:125)
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:61)
 at 
 org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:130)
 at 
 org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:138)
 at 
 org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1658)
 at 
 org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3721)
 at 
 org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3709)
 at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
 at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
 at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:196)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)
 {noformat}
 Causes cqlsh to hang forever.

--
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-4785) Secondary Index Sporadically Doesn't Return Rows

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

Arya Goudarzi commented on CASSANDRA-4785:
--

If you mean clean slate installation, I have not done that, and I won't get any
time soon to try it. But, let say I could not repro, then what should I do in
my live cluster to take it out of this state?

Secondary Index Sporadically Doesn't Return Rows

Key: CASSANDRA-4785
URL: https://issues.apache.org/jira/browse/CASSANDRA-4785
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: Ubuntu 10.04
Java 6 Sun
Cassandra 1.1.5 upgraded from 1.1.2 - 1.1.3 - 1.1.5
Reporter: Arya Goudarzi

I have a ColumnFamily with caching = ALL. I have 2 secondary indexes on it. I
have noticed if I query using the secondary index in the where clause,
sometimes I get the results and sometimes I don't. Until 2 weeks ago, the
caching option on this CF was set to NONE. So, I suspect something happened
in secondary index caching scheme.
Here are things I tried:
1. I rebuild indexes for that CF on all nodes;
2. I set the caching to KEYS_ONLY and rebuild the index again;
3. I set the caching to NONE and rebuild the index again;
None of the above helped. I suppose the caching still exists as this behavior
looks like cache mistmatch.
I did a bit research, and found CASSANDRA-4197 that could be related.
Please advice.

[jira] [Updated] (CASSANDRA-4463) Assertion Error on Serializing Cache provider on restart


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

Arya Goudarzi updated CASSANDRA-4463:
-

Environment: 
Ubuntu 12.04 Precise
Cassandra 1.1.5
Oracle Java 6

  was:
Ubuntu 12.04 Precise
Cassandra 1.1.2
Oracle Java 6


 Assertion Error on Serializing Cache provider on restart
 

 Key: CASSANDRA-4463
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4463
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.5
 Environment: Ubuntu 12.04 Precise
 Cassandra 1.1.5
 Oracle Java 6
Reporter: Arya Goudarzi

 I stopped Cassandra on one of our 1.1.2 nodes and I couldn't start it any 
 more. System.log didn't have much useful info but output.log had this:
 java.lang.AssertionError
 at 
 org.apache.cassandra.cache.SerializingCacheProvider$RowCacheSerializer.serialize(SerializingCacheProvider.java:43)
 at 
 org.apache.cassandra.cache.SerializingCacheProvider$RowCacheSerializer.serialize(SerializingCacheProvider.java:39)
 at 
 org.apache.cassandra.cache.SerializingCache.serialize(SerializingCache.java:116)
 at 
 org.apache.cassandra.cache.SerializingCache.put(SerializingCache.java:174)
 at 
 org.apache.cassandra.cache.InstrumentingCache.put(InstrumentingCache.java:45)
 at 
 org.apache.cassandra.db.ColumnFamilyStore.initRowCache(ColumnFamilyStore.java:430)
 at org.apache.cassandra.db.Table.open(Table.java:124)
 at org.apache.cassandra.db.Table.open(Table.java:97)
 at 
 org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:204)
 at 
 org.apache.cassandra.service.AbstractCassandraDaemon.init(AbstractCassandraDaemon.java:254)
 at 
 com.netflix.priam.cassandra.NFThinCassandraDaemon.init(NFThinCassandraDaemon.java:41)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:212)
 Cannot load daemon
 Service exit with a return value of 3
 Deleting the stuff in saved_caches folder fixed the problem.

--
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-4463) Assertion Error on Serializing Cache provider on restart


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

Arya Goudarzi updated CASSANDRA-4463:
-

Affects Version/s: (was: 1.1.2)
   1.1.5

 Assertion Error on Serializing Cache provider on restart
 

 Key: CASSANDRA-4463
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4463
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.5
 Environment: Ubuntu 12.04 Precise
 Cassandra 1.1.5
 Oracle Java 6
Reporter: Arya Goudarzi

 I stopped Cassandra on one of our 1.1.2 nodes and I couldn't start it any 
 more. System.log didn't have much useful info but output.log had this:
 java.lang.AssertionError
 at 
 org.apache.cassandra.cache.SerializingCacheProvider$RowCacheSerializer.serialize(SerializingCacheProvider.java:43)
 at 
 org.apache.cassandra.cache.SerializingCacheProvider$RowCacheSerializer.serialize(SerializingCacheProvider.java:39)
 at 
 org.apache.cassandra.cache.SerializingCache.serialize(SerializingCache.java:116)
 at 
 org.apache.cassandra.cache.SerializingCache.put(SerializingCache.java:174)
 at 
 org.apache.cassandra.cache.InstrumentingCache.put(InstrumentingCache.java:45)
 at 
 org.apache.cassandra.db.ColumnFamilyStore.initRowCache(ColumnFamilyStore.java:430)
 at org.apache.cassandra.db.Table.open(Table.java:124)
 at org.apache.cassandra.db.Table.open(Table.java:97)
 at 
 org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:204)
 at 
 org.apache.cassandra.service.AbstractCassandraDaemon.init(AbstractCassandraDaemon.java:254)
 at 
 com.netflix.priam.cassandra.NFThinCassandraDaemon.init(NFThinCassandraDaemon.java:41)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:212)
 Cannot load daemon
 Service exit with a return value of 3
 Deleting the stuff in saved_caches folder fixed the problem.

--
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-4463) Assertion Error on Serializing Cache provider on restart


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

Arya Goudarzi commented on CASSANDRA-4463:
--

This is still happening in 1.1.5. I just had to perform some maintenance and 
restart service and I got this again:

java.lang.AssertionError
at 
org.apache.cassandra.cache.SerializingCacheProvider$RowCacheSerializer.serialize(SerializingCacheProvider.java:43)
at 
org.apache.cassandra.cache.SerializingCacheProvider$RowCacheSerializer.serialize(SerializingCacheProvider.java:39)
at 
org.apache.cassandra.cache.SerializingCache.serialize(SerializingCache.java:116)
at 
org.apache.cassandra.cache.SerializingCache.put(SerializingCache.java:174)
at 
org.apache.cassandra.cache.InstrumentingCache.put(InstrumentingCache.java:45)
at 
org.apache.cassandra.db.ColumnFamilyStore.initRowCache(ColumnFamilyStore.java:446)
at org.apache.cassandra.db.Table.open(Table.java:124)
at org.apache.cassandra.db.Table.open(Table.java:97)
at 
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:206)
at 
org.apache.cassandra.service.AbstractCassandraDaemon.init(AbstractCassandraDaemon.java:290)
at 
com.netflix.priam.cassandra.NFThinCassandraDaemon.init(NFThinCassandraDaemon.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:212)
Cannot load daemon
Service exit with a return value of 3

 Assertion Error on Serializing Cache provider on restart
 

 Key: CASSANDRA-4463
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4463
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.5
 Environment: Ubuntu 12.04 Precise
 Cassandra 1.1.5
 Oracle Java 6
Reporter: Arya Goudarzi

 I stopped Cassandra on one of our 1.1.2 nodes and I couldn't start it any 
 more. System.log didn't have much useful info but output.log had this:
 java.lang.AssertionError
 at 
 org.apache.cassandra.cache.SerializingCacheProvider$RowCacheSerializer.serialize(SerializingCacheProvider.java:43)
 at 
 org.apache.cassandra.cache.SerializingCacheProvider$RowCacheSerializer.serialize(SerializingCacheProvider.java:39)
 at 
 org.apache.cassandra.cache.SerializingCache.serialize(SerializingCache.java:116)
 at 
 org.apache.cassandra.cache.SerializingCache.put(SerializingCache.java:174)
 at 
 org.apache.cassandra.cache.InstrumentingCache.put(InstrumentingCache.java:45)
 at 
 org.apache.cassandra.db.ColumnFamilyStore.initRowCache(ColumnFamilyStore.java:430)
 at org.apache.cassandra.db.Table.open(Table.java:124)
 at org.apache.cassandra.db.Table.open(Table.java:97)
 at 
 org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:204)
 at 
 org.apache.cassandra.service.AbstractCassandraDaemon.init(AbstractCassandraDaemon.java:254)
 at 
 com.netflix.priam.cassandra.NFThinCassandraDaemon.init(NFThinCassandraDaemon.java:41)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:212)
 Cannot load daemon
 Service exit with a return value of 3
 Deleting the stuff in saved_caches folder fixed the problem.

--
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-4691) Upgrade pig to 0.10

2012-10-12 Thread Pavel Yaskevich (JIRA)


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

Pavel Yaskevich commented on CASSANDRA-4691:


+1

 Upgrade pig to 0.10
 ---

 Key: CASSANDRA-4691
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4691
 Project: Cassandra
  Issue Type: Improvement
  Components: Hadoop
Reporter: Brandon Williams
Assignee: Brandon Williams
 Fix For: 1.2.0 beta 2

 Attachments: 4691.txt


 Now that pig has a newer release and we have an upcoming one, it's a good 
 chance to upgrade.

--
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-4463) Nodes Don't Restart: Assertion Error on Serializing Cache provider