date:20160802

[jira] [Comment Edited] (CASSANDRA-9507) range metrics are not updated for timeout and unavailable in StorageProxy

2016-08-02 Thread Alex Petrov (JIRA)


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

Alex Petrov edited comment on CASSANDRA-9507 at 8/2/16 7:16 AM:


Hi [~nachiket_patil], you mentioned that new patches attached, although 
unfortunately I can still only see patches from 5 of July. I might be missing 
something. 

Since I could only look at those patches, I have one more comment in addition 
to what Benjamin has mentioned: do we want to report time as we do with other 
metircs with {{addNano}} and time diff? 

As a sidenote, as far as I can say this issue does not qualify for "critical", 
and according to the 
[discussion|https://mail-archives.apache.org/mod_mbox/cassandra-dev/201607.mbox/%3CCALdd-zjg%2Ba73VncPkU2rw_UpFPVsw0yNwO-yBqUQfK8H8FpiKw%40mail.gmail.com%3E]
 we probably should leave it out for 2.1.


was (Author: ifesdjeen):
Hi [~nachiket_patil], you mentioned that new patches attached, although 
unfortunately I can still only see patches from 5 of July. I might be missing 
something. 

Since I could only look at those patches, I have one more comment in addition 
to what Benjamin has mentioned: do we want to report time as we do with other 
metircs with {{addNano}} and time diff? 

As a sidenote, as far as I can say this issue does not qualify for "critical", 
and according to the 
[discussion|https://mail-archives.apache.org/mod_mbox/cassandra-dev/201607.mbox/%3CCALdd-zjg%2Ba73VncPkU2rw_UpFPVsw0yNwO-yBqUQfK8H8FpiKw%40mail.gmail.com%3E]
 we probably should leave it out.

> range metrics are not updated for timeout and unavailable in StorageProxy
> -
>
> Key: CASSANDRA-9507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9507
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability
>Reporter: sankalp kohli
>Assignee: Nachiket Patil
>Priority: Minor
> Attachments: CASANDRA-9507 trunk.diff, CASSANDRA-9507 v2.1.diff, 
> CASSANDRA-9507 v2.2.diff, CASSANDRA-9507 v3.0.diff
>
>
> Looking at the code, it looks like range metrics are not updated for timeouts 
> and unavailable. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12282) SSTablesIteratedTest.testDeletionOnIndexedSSTableASC-compression failure

2016-08-02 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-12282:
--

+1, though I'd maybe remove the {{"THIS TEST HAS FAILED WITH {} LIVE 
SSTABLES!!!"}} logging, no need to shout :).

> SSTablesIteratedTest.testDeletionOnIndexedSSTableASC-compression failure
> 
>
> Key: CASSANDRA-12282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12282
> Project: Cassandra
>  Issue Type: Test
>Reporter: Joshua McKenzie
>Assignee: Stefania
>  Labels: unittest
>
> Error Message
> expected:<3> but was:<4>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<3> but was:<4>
>   at 
> org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.executeAndCheck(SSTablesIteratedTest.java:45)
>   at 
> org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnIndexedSSTableASC(SSTablesIteratedTest.java:348)
>   at 
> org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnIndexedSSTableASC(SSTablesIteratedTest.java:312)
> [Failure|http://cassci.datastax.com/job/cassandra-3.9_testall/lastCompletedBuild/testReport/org.apache.cassandra.cql3.validation.miscellaneous/SSTablesIteratedTest/testDeletionOnIndexedSSTableASC_compression/]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12359) BlacklistingCompactionsTest.testBlacklistingWithSizeTieredCompactionStrategy is flaky

2016-08-02 Thread Stefania (JIRA)


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

Stefania commented on CASSANDRA-12359:
--

This can be reproduced reliably by fixing the seed to the same seed that failed 
on Jenkins: 2080431860597L. I've also reproduced it another couple of times 
locally, it seems on average we have one failure every 100 to 150 runs.

For seed 2080431860597L, despite inserting 50 corrupt bytes at position 112 of 
sstable no. 24, the sstable still gets compacted. This is because we read 
through the corrupted bytes without complaining: vint encoding assume a 
positive byte is a valid int, flags don't particularly raise problems, neither 
do ascii types.

I've replaced Ascii types with Long types, which are fixed size types and 
should have a better chance at detecting corrupted bytes, and I've doubled the 
corruption size. I've already run the test locally 100 times and I've launched 
another multiplex of 250 times on Jenkins:

[3.9 patch|https://github.com/stef1927/cassandra/commits/12359-3.9]
[multiplexed 
results|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-testall-multiplex/16/]

Alternatively we could fix the corrupted bytes to zero or -1, and only leave 
the corruption position as random.

> BlacklistingCompactionsTest.testBlacklistingWithSizeTieredCompactionStrategy 
> is flaky
> -
>
> Key: CASSANDRA-12359
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12359
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Stefania
>
> example failure:
>   
> [http://cassci.datastax.com/job/cassandra-3.9_testall/50/testReport/junit/org.apache.cassandra.db.compaction/BlacklistingCompactionsTest/testBlacklistingWithSizeTieredCompactionStrategy/]
> Google suggests that this test is somewhat flaky historically, but we don't 
> have logs from any of the older failures any more.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

2016-08-02 Thread Stefania (JIRA)


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

Stefania commented on CASSANDRA-9318:
-

It looks good [~sbtourist], I only noticed a typo in cassandra.yaml at this 
[line|https://github.com/apache/cassandra/compare/trunk...sbtourist:CASSANDRA-9318-trunk?expand=1#diff-bdaab1104a93e723ce0b609a6477c9c4R1161]:
 "implement provide". I did not repeat the review of the files which were added 
since they should not have changed, only the existing files with modifications.

> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths, Streaming and Messaging
>Reporter: Ariel Weisberg
>Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, 
> limit.btm, no_backpressure.png
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-9507) range metrics are not updated for timeout and unavailable in StorageProxy

2016-08-02 Thread Alex Petrov (JIRA)


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

Alex Petrov commented on CASSANDRA-9507:


Yes, I meant we should leave it out for {{2.1}}. Sorry I forgot to mention the 
version number, added now.

As regards the patch, I still can see Benjamin's comments there:

  * {{final}} keywords in {{catch}} blocks in [3.0 
patch|https://github.com/ifesdjeen/cassandra/commit/4e6a45a0ffc11a8e0589fd4b48d9d3850ed535ab#diff-71f06c193f5b5e270cf8ac695164f43aR2066]
 (btw, it merges clean to trunk) (if it was the only thing we could just fix it 
on commit)
  * exceptions thrown in {{StorageProxy::getRangeSlice}} are [still 
there|https://github.com/ifesdjeen/cassandra/blob/4e6a45a0ffc11a8e0589fd4b48d9d3850ed535ab/src/java/org/apache/cassandra/service/StorageProxy.java#L2165].
 [~blerer] has suggested to remove them since they're not thrown there. As he 
mentioned, for example, the {{UnavailableException}} is thrown in 
{{RangeCommandIterator#query}} (since it calls {{assureSufficientLiveNodes}} 
originally and bubbled up. As far as I can say, they're thrown in a different 
way/different place in {{2.2}}. 

> range metrics are not updated for timeout and unavailable in StorageProxy
> -
>
> Key: CASSANDRA-9507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9507
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability
>Reporter: sankalp kohli
>Assignee: Nachiket Patil
>Priority: Minor
> Attachments: CASANDRA-9507 trunk.diff, CASSANDRA-9507 v2.1.diff, 
> CASSANDRA-9507 v2.2.diff, CASSANDRA-9507 v3.0.diff
>
>
> Looking at the code, it looks like range metrics are not updated for timeouts 
> and unavailable. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[2/3] cassandra git commit: Fixed flacky SSTablesIteratedTest

2016-08-02 Thread stefania

Fixed flacky SSTablesIteratedTest

patch by Stefania Alborghetti; reviewed by Sylvain Lebresne for CASSANDRA-12282


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

Branch: refs/heads/trunk
Commit: f5078b19c509d52d32659aef714bf9288540bfc4
Parents: e89028d
Author: Stefania Alborghetti 
Authored: Thu Jul 28 17:17:30 2016 +0800
Committer: Stefania Alborghetti 
Committed: Tue Aug 2 15:53:05 2016 +0800

--
 CHANGES.txt |  1 +
 .../org/apache/cassandra/cql3/CQLTester.java| 39 
 .../miscellaneous/SSTablesIteratedTest.java | 25 +++--
 3 files changed, 53 insertions(+), 12 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f5078b19/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0f6bc50..5647cd4 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.9
+ * Fixed flacky SSTablesIteratedTest (CASSANDRA-12282)
  * Fixed flacky SSTableRewriterTest: check file counts before calling 
validateCFS (CASSANDRA-12348)
  * cqlsh: Fix handling of $$-escaped strings (CASSANDRA-12189)
  * Fix SSL JMX requiring truststore containing server cert (CASSANDRA-12109)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f5078b19/test/unit/org/apache/cassandra/cql3/CQLTester.java
--
diff --git a/test/unit/org/apache/cassandra/cql3/CQLTester.java 
b/test/unit/org/apache/cassandra/cql3/CQLTester.java
index 7e1516a..19e40d2 100644
--- a/test/unit/org/apache/cassandra/cql3/CQLTester.java
+++ b/test/unit/org/apache/cassandra/cql3/CQLTester.java
@@ -377,10 +377,15 @@ public abstract class CQLTester
 
 public ColumnFamilyStore getCurrentColumnFamilyStore()
 {
+return getCurrentColumnFamilyStore(KEYSPACE);
+}
+
+public ColumnFamilyStore getCurrentColumnFamilyStore(String keyspace)
+{
 String currentTable = currentTable();
 return currentTable == null
  ? null
- : Keyspace.open(KEYSPACE).getColumnFamilyStore(currentTable);
+ : Keyspace.open(keyspace).getColumnFamilyStore(currentTable);
 }
 
 public void flush(boolean forceFlush)
@@ -391,14 +396,19 @@ public abstract class CQLTester
 
 public void flush()
 {
-ColumnFamilyStore store = getCurrentColumnFamilyStore();
+flush(KEYSPACE);
+}
+
+public void flush(String keyspace)
+{
+ColumnFamilyStore store = getCurrentColumnFamilyStore(keyspace);
 if (store != null)
 store.forceBlockingFlush();
 }
 
-public void disableCompaction()
+public void disableCompaction(String keyspace)
 {
-ColumnFamilyStore store = getCurrentColumnFamilyStore();
+ColumnFamilyStore store = getCurrentColumnFamilyStore(keyspace);
 store.disableAutoCompaction();
 }
 
@@ -546,8 +556,13 @@ public abstract class CQLTester
 
 protected String createTable(String query)
 {
+return createTable(KEYSPACE, query);
+}
+
+protected String createTable(String keyspace, String query)
+{
 String currentTable = createTableName();
-String fullQuery = formatQuery(query);
+String fullQuery = formatQuery(keyspace, query);
 logger.info(fullQuery);
 schemaChange(fullQuery);
 return currentTable;
@@ -697,10 +712,15 @@ public abstract class CQLTester
 return sessions.get(protocolVersion);
 }
 
-private String formatQuery(String query)
+protected String formatQuery(String query)
+{
+return formatQuery(KEYSPACE, query);
+}
+
+protected String formatQuery(String keyspace, String query)
 {
 String currentTable = currentTable();
-return currentTable == null ? query : String.format(query, KEYSPACE + 
"." + currentTable);
+return currentTable == null ? query : String.format(query, keyspace + 
"." + currentTable);
 }
 
 protected ResultMessage.Prepared prepare(String query) throws Throwable
@@ -710,8 +730,11 @@ public abstract class CQLTester
 
 protected UntypedResultSet execute(String query, Object... values) throws 
Throwable
 {
-query = formatQuery(query);
+return executeFormattedQuery(formatQuery(query), values);
+}
 
+protected UntypedResultSet executeFormattedQuery(String query, Object... 
values) throws Throwable
+{
 UntypedResultSet rs;
 if (usePrepared)
 {

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f5078b19/test/unit/org/apache/cassandra/cql

[1/3] cassandra git commit: Fixed flacky SSTablesIteratedTest

2016-08-02 Thread stefania

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.9 e89028d34 -> f5078b19c
  refs/heads/trunk c320f22a9 -> b637fee89


Fixed flacky SSTablesIteratedTest

patch by Stefania Alborghetti; reviewed by Sylvain Lebresne for CASSANDRA-12282


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

Branch: refs/heads/cassandra-3.9
Commit: f5078b19c509d52d32659aef714bf9288540bfc4
Parents: e89028d
Author: Stefania Alborghetti 
Authored: Thu Jul 28 17:17:30 2016 +0800
Committer: Stefania Alborghetti 
Committed: Tue Aug 2 15:53:05 2016 +0800

--
 CHANGES.txt |  1 +
 .../org/apache/cassandra/cql3/CQLTester.java| 39 
 .../miscellaneous/SSTablesIteratedTest.java | 25 +++--
 3 files changed, 53 insertions(+), 12 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f5078b19/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0f6bc50..5647cd4 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.9
+ * Fixed flacky SSTablesIteratedTest (CASSANDRA-12282)
  * Fixed flacky SSTableRewriterTest: check file counts before calling 
validateCFS (CASSANDRA-12348)
  * cqlsh: Fix handling of $$-escaped strings (CASSANDRA-12189)
  * Fix SSL JMX requiring truststore containing server cert (CASSANDRA-12109)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f5078b19/test/unit/org/apache/cassandra/cql3/CQLTester.java
--
diff --git a/test/unit/org/apache/cassandra/cql3/CQLTester.java 
b/test/unit/org/apache/cassandra/cql3/CQLTester.java
index 7e1516a..19e40d2 100644
--- a/test/unit/org/apache/cassandra/cql3/CQLTester.java
+++ b/test/unit/org/apache/cassandra/cql3/CQLTester.java
@@ -377,10 +377,15 @@ public abstract class CQLTester
 
 public ColumnFamilyStore getCurrentColumnFamilyStore()
 {
+return getCurrentColumnFamilyStore(KEYSPACE);
+}
+
+public ColumnFamilyStore getCurrentColumnFamilyStore(String keyspace)
+{
 String currentTable = currentTable();
 return currentTable == null
  ? null
- : Keyspace.open(KEYSPACE).getColumnFamilyStore(currentTable);
+ : Keyspace.open(keyspace).getColumnFamilyStore(currentTable);
 }
 
 public void flush(boolean forceFlush)
@@ -391,14 +396,19 @@ public abstract class CQLTester
 
 public void flush()
 {
-ColumnFamilyStore store = getCurrentColumnFamilyStore();
+flush(KEYSPACE);
+}
+
+public void flush(String keyspace)
+{
+ColumnFamilyStore store = getCurrentColumnFamilyStore(keyspace);
 if (store != null)
 store.forceBlockingFlush();
 }
 
-public void disableCompaction()
+public void disableCompaction(String keyspace)
 {
-ColumnFamilyStore store = getCurrentColumnFamilyStore();
+ColumnFamilyStore store = getCurrentColumnFamilyStore(keyspace);
 store.disableAutoCompaction();
 }
 
@@ -546,8 +556,13 @@ public abstract class CQLTester
 
 protected String createTable(String query)
 {
+return createTable(KEYSPACE, query);
+}
+
+protected String createTable(String keyspace, String query)
+{
 String currentTable = createTableName();
-String fullQuery = formatQuery(query);
+String fullQuery = formatQuery(keyspace, query);
 logger.info(fullQuery);
 schemaChange(fullQuery);
 return currentTable;
@@ -697,10 +712,15 @@ public abstract class CQLTester
 return sessions.get(protocolVersion);
 }
 
-private String formatQuery(String query)
+protected String formatQuery(String query)
+{
+return formatQuery(KEYSPACE, query);
+}
+
+protected String formatQuery(String keyspace, String query)
 {
 String currentTable = currentTable();
-return currentTable == null ? query : String.format(query, KEYSPACE + 
"." + currentTable);
+return currentTable == null ? query : String.format(query, keyspace + 
"." + currentTable);
 }
 
 protected ResultMessage.Prepared prepare(String query) throws Throwable
@@ -710,8 +730,11 @@ public abstract class CQLTester
 
 protected UntypedResultSet execute(String query, Object... values) throws 
Throwable
 {
-query = formatQuery(query);
+return executeFormattedQuery(formatQuery(query), values);
+}
 
+protected UntypedResultSet executeFormattedQuery(String query, Object... 
values) throws Throwable
+{
 UntypedResultS

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

2016-08-02 Thread stefania

Merge branch 'cassandra-3.9' into trunk


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

Branch: refs/heads/trunk
Commit: b637fee8986a5b47d236609959425aa4f0531d16
Parents: c320f22 f5078b1
Author: Stefania Alborghetti 
Authored: Tue Aug 2 15:53:32 2016 +0800
Committer: Stefania Alborghetti 
Committed: Tue Aug 2 15:53:32 2016 +0800

--
 CHANGES.txt |  1 +
 .../org/apache/cassandra/cql3/CQLTester.java| 39 
 .../miscellaneous/SSTablesIteratedTest.java | 25 +++--
 3 files changed, 53 insertions(+), 12 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b637fee8/CHANGES.txt
--
diff --cc CHANGES.txt
index 1f5ad3a,5647cd4..3de3653
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,31 -1,5 +1,32 @@@
 +3.10
 + * Add version command to cassandra-stress (CASSANDRA-12258)
 + * Create compaction-stress tool (CASSANDRA-11844)
 + * Garbage-collecting compaction operation and schema option (CASSANDRA-7019)
 + * Add schema to snapshot manifest, add USING TIMESTAMP clause to ALTER TABLE 
statements (CASSANDRA-7190)
 + * Add beta protocol flag for v5 native protocol (CASSANDRA-12142)
 + * Support filtering on non-PRIMARY KEY columns in the CREATE
 +   MATERIALIZED VIEW statement's WHERE clause (CASSANDRA-10368)
 + * Unify STDOUT and SYSTEMLOG logback format (CASSANDRA-12004)
 + * COPY FROM should raise error for non-existing input files (CASSANDRA-12174)
 + * Faster write path (CASSANDRA-12269)
 + * Option to leave omitted columns in INSERT JSON unset (CASSANDRA-11424)
 + * Support json/yaml output in nodetool tpstats (CASSANDRA-12035)
 + * Expose metrics for successful/failed authentication attempts 
(CASSANDRA-10635)
 + * Prepend snapshot name with "truncated" or "dropped" when a snapshot
 +   is taken before truncating or dropping a table (CASSANDRA-12178)
 + * Optimize RestrictionSet (CASSANDRA-12153)
 + * cqlsh does not automatically downgrade CQL version (CASSANDRA-12150)
 + * Omit (de)serialization of state variable in UDAs (CASSANDRA-9613)
 + * Create a system table to expose prepared statements (CASSANDRA-8831)
 + * Reuse DataOutputBuffer from ColumnIndex (CASSANDRA-11970)
 + * Remove DatabaseDescriptor dependency from SegmentedFile (CASSANDRA-11580)
 + * Add supplied username to authentication error messages (CASSANDRA-12076)
 + * Remove pre-startup check for open JMX port (CASSANDRA-12074)
 + * Remove compaction Severity from DynamicEndpointSnitch (CASSANDRA-11738)
 +
 +
  3.9
+  * Fixed flacky SSTablesIteratedTest (CASSANDRA-12282)
   * Fixed flacky SSTableRewriterTest: check file counts before calling 
validateCFS (CASSANDRA-12348)
   * cqlsh: Fix handling of $$-escaped strings (CASSANDRA-12189)
   * Fix SSL JMX requiring truststore containing server cert (CASSANDRA-12109)

[jira] [Commented] (CASSANDRA-12282) SSTablesIteratedTest.testDeletionOnIndexedSSTableASC-compression failure

2016-08-02 Thread Stefania (JIRA)


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

Stefania commented on CASSANDRA-12282:
--

Thank you for the review. Removed {{"THIS TEST HAS FAILED WITH {} LIVE 
SSTABLES!!!"}} :), committed to 3.9 as f5078b19c509d52d32659aef714bf9288540bfc4 
and merged into trunk.

> SSTablesIteratedTest.testDeletionOnIndexedSSTableASC-compression failure
> 
>
> Key: CASSANDRA-12282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12282
> Project: Cassandra
>  Issue Type: Test
>Reporter: Joshua McKenzie
>Assignee: Stefania
>  Labels: unittest
>
> Error Message
> expected:<3> but was:<4>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<3> but was:<4>
>   at 
> org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.executeAndCheck(SSTablesIteratedTest.java:45)
>   at 
> org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnIndexedSSTableASC(SSTablesIteratedTest.java:348)
>   at 
> org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnIndexedSSTableASC(SSTablesIteratedTest.java:312)
> [Failure|http://cassci.datastax.com/job/cassandra-3.9_testall/lastCompletedBuild/testReport/org.apache.cassandra.cql3.validation.miscellaneous/SSTablesIteratedTest/testDeletionOnIndexedSSTableASC_compression/]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12282) SSTablesIteratedTest.testDeletionOnIndexedSSTableASC-compression failure

2016-08-02 Thread Stefania (JIRA)


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

Stefania updated CASSANDRA-12282:
-
   Resolution: Fixed
Fix Version/s: 3.9
   Status: Resolved  (was: Patch Available)

> SSTablesIteratedTest.testDeletionOnIndexedSSTableASC-compression failure
> 
>
> Key: CASSANDRA-12282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12282
> Project: Cassandra
>  Issue Type: Test
>Reporter: Joshua McKenzie
>Assignee: Stefania
>  Labels: unittest
> Fix For: 3.9
>
>
> Error Message
> expected:<3> but was:<4>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<3> but was:<4>
>   at 
> org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.executeAndCheck(SSTablesIteratedTest.java:45)
>   at 
> org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnIndexedSSTableASC(SSTablesIteratedTest.java:348)
>   at 
> org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnIndexedSSTableASC(SSTablesIteratedTest.java:312)
> [Failure|http://cassci.datastax.com/job/cassandra-3.9_testall/lastCompletedBuild/testReport/org.apache.cassandra.cql3.validation.miscellaneous/SSTablesIteratedTest/testDeletionOnIndexedSSTableASC_compression/]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[2/6] cassandra git commit: Make all index names in CustomIndexTest unique

2016-08-02 Thread samt

Make all index names in CustomIndexTest unique

Patch by Sam Tunnicliffe; reviewed by Stefani Alborghetti for
CASSANDRA-12353


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

Branch: refs/heads/cassandra-3.9
Commit: c6cb31e5f841f19eaccf6995fa7bd643b1e9acc3
Parents: 10e719c
Author: Sam Tunnicliffe 
Authored: Mon Aug 1 17:58:46 2016 +0100
Committer: Sam Tunnicliffe 
Committed: Tue Aug 2 09:09:50 2016 +0100

--
 .../apache/cassandra/index/CustomIndexTest.java | 38 
 1 file changed, 23 insertions(+), 15 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6cb31e5/test/unit/org/apache/cassandra/index/CustomIndexTest.java
--
diff --git a/test/unit/org/apache/cassandra/index/CustomIndexTest.java 
b/test/unit/org/apache/cassandra/index/CustomIndexTest.java
index f02823c..b8e4185 100644
--- a/test/unit/org/apache/cassandra/index/CustomIndexTest.java
+++ b/test/unit/org/apache/cassandra/index/CustomIndexTest.java
@@ -348,12 +348,14 @@ public class CustomIndexTest extends CQLTester
 {
 Object[] row = row(0, 0, 0, 0);
 createTable("CREATE TABLE %s (a int, b int, c int, d int, PRIMARY KEY 
(a, b))");
+String indexName = currentTable() + "_custom_index";
 execute("INSERT INTO %s (a, b, c, d) VALUES (?, ?, ?, ?)", row);
 
-assertInvalidMessage(String.format(IndexRestrictions.INDEX_NOT_FOUND, 
"custom_index", keyspace(), currentTable()),
- "SELECT * FROM %s WHERE expr(custom_index, 'foo 
bar baz')");
 
-createIndex(String.format("CREATE CUSTOM INDEX custom_index ON %%s(c) 
USING '%s'", StubIndex.class.getName()));
+assertInvalidMessage(String.format(IndexRestrictions.INDEX_NOT_FOUND, 
indexName, keyspace(), currentTable()),
+ String.format("SELECT * FROM %%s WHERE expr(%s, 
'foo bar baz')", indexName));
+
+createIndex(String.format("CREATE CUSTOM INDEX %s ON %%s(c) USING 
'%s'", indexName, StubIndex.class.getName()));
 
 assertInvalidThrowMessage(Server.CURRENT_VERSION,
   
String.format(IndexRestrictions.INDEX_NOT_FOUND, "no_such_index", keyspace(), 
currentTable()),
@@ -361,52 +363,58 @@ public class CustomIndexTest extends CQLTester
   "SELECT * FROM %s WHERE expr(no_such_index, 
'foo bar baz ')");
 
 // simple case
-assertRows(execute("SELECT * FROM %s WHERE expr(custom_index, 'foo bar 
baz')"), row);
-assertRows(execute("SELECT * FROM %s WHERE expr(\"custom_index\", 'foo 
bar baz')"), row);
-assertRows(execute("SELECT * FROM %s WHERE expr(custom_index, $$foo \" 
~~~ bar Baz$$)"), row);
+assertRows(execute(String.format("SELECT * FROM %%s WHERE expr(%s, 
'foo bar baz')", indexName)), row);
+assertRows(execute(String.format("SELECT * FROM %%s WHERE expr(\"%s\", 
'foo bar baz')", indexName)), row);
+assertRows(execute(String.format("SELECT * FROM %%s WHERE expr(%s, 
$$foo \" ~~~ bar Baz$$)", indexName)), row);
 
 // multiple expressions on the same index
 assertInvalidThrowMessage(Server.CURRENT_VERSION,
   IndexRestrictions.MULTIPLE_EXPRESSIONS,
   QueryValidationException.class,
-  "SELECT * FROM %s WHERE expr(custom_index, 
'foo') AND expr(custom_index, 'bar')");
+  String.format("SELECT * FROM %%s WHERE 
expr(%1$s, 'foo') AND expr(%1$s, 'bar')",
+indexName));
 
 // multiple expressions on different indexes
 createIndex(String.format("CREATE CUSTOM INDEX other_custom_index ON 
%%s(d) USING '%s'", StubIndex.class.getName()));
 assertInvalidThrowMessage(Server.CURRENT_VERSION,
   IndexRestrictions.MULTIPLE_EXPRESSIONS,
   QueryValidationException.class,
-  "SELECT * FROM %s WHERE expr(custom_index, 
'foo') AND expr(other_custom_index, 'bar')");
+  String.format("SELECT * FROM %%s WHERE 
expr(%s, 'foo') AND expr(other_custom_index, 'bar')",
+indexName));
 
 assertInvalidThrowMessage(Server.CURRENT_VERSION,
   
StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
   QueryValidationException.class,
-  "SELECT * FROM %s WHE

[1/6] cassandra git commit: Make all index names in CustomIndexTest unique

2016-08-02 Thread samt

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 10e719cb6 -> c6cb31e5f
  refs/heads/cassandra-3.9 f5078b19c -> 245fc2ade
  refs/heads/trunk b637fee89 -> 8f1501d9c


Make all index names in CustomIndexTest unique

Patch by Sam Tunnicliffe; reviewed by Stefani Alborghetti for
CASSANDRA-12353


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

Branch: refs/heads/cassandra-3.0
Commit: c6cb31e5f841f19eaccf6995fa7bd643b1e9acc3
Parents: 10e719c
Author: Sam Tunnicliffe 
Authored: Mon Aug 1 17:58:46 2016 +0100
Committer: Sam Tunnicliffe 
Committed: Tue Aug 2 09:09:50 2016 +0100

--
 .../apache/cassandra/index/CustomIndexTest.java | 38 
 1 file changed, 23 insertions(+), 15 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6cb31e5/test/unit/org/apache/cassandra/index/CustomIndexTest.java
--
diff --git a/test/unit/org/apache/cassandra/index/CustomIndexTest.java 
b/test/unit/org/apache/cassandra/index/CustomIndexTest.java
index f02823c..b8e4185 100644
--- a/test/unit/org/apache/cassandra/index/CustomIndexTest.java
+++ b/test/unit/org/apache/cassandra/index/CustomIndexTest.java
@@ -348,12 +348,14 @@ public class CustomIndexTest extends CQLTester
 {
 Object[] row = row(0, 0, 0, 0);
 createTable("CREATE TABLE %s (a int, b int, c int, d int, PRIMARY KEY 
(a, b))");
+String indexName = currentTable() + "_custom_index";
 execute("INSERT INTO %s (a, b, c, d) VALUES (?, ?, ?, ?)", row);
 
-assertInvalidMessage(String.format(IndexRestrictions.INDEX_NOT_FOUND, 
"custom_index", keyspace(), currentTable()),
- "SELECT * FROM %s WHERE expr(custom_index, 'foo 
bar baz')");
 
-createIndex(String.format("CREATE CUSTOM INDEX custom_index ON %%s(c) 
USING '%s'", StubIndex.class.getName()));
+assertInvalidMessage(String.format(IndexRestrictions.INDEX_NOT_FOUND, 
indexName, keyspace(), currentTable()),
+ String.format("SELECT * FROM %%s WHERE expr(%s, 
'foo bar baz')", indexName));
+
+createIndex(String.format("CREATE CUSTOM INDEX %s ON %%s(c) USING 
'%s'", indexName, StubIndex.class.getName()));
 
 assertInvalidThrowMessage(Server.CURRENT_VERSION,
   
String.format(IndexRestrictions.INDEX_NOT_FOUND, "no_such_index", keyspace(), 
currentTable()),
@@ -361,52 +363,58 @@ public class CustomIndexTest extends CQLTester
   "SELECT * FROM %s WHERE expr(no_such_index, 
'foo bar baz ')");
 
 // simple case
-assertRows(execute("SELECT * FROM %s WHERE expr(custom_index, 'foo bar 
baz')"), row);
-assertRows(execute("SELECT * FROM %s WHERE expr(\"custom_index\", 'foo 
bar baz')"), row);
-assertRows(execute("SELECT * FROM %s WHERE expr(custom_index, $$foo \" 
~~~ bar Baz$$)"), row);
+assertRows(execute(String.format("SELECT * FROM %%s WHERE expr(%s, 
'foo bar baz')", indexName)), row);
+assertRows(execute(String.format("SELECT * FROM %%s WHERE expr(\"%s\", 
'foo bar baz')", indexName)), row);
+assertRows(execute(String.format("SELECT * FROM %%s WHERE expr(%s, 
$$foo \" ~~~ bar Baz$$)", indexName)), row);
 
 // multiple expressions on the same index
 assertInvalidThrowMessage(Server.CURRENT_VERSION,
   IndexRestrictions.MULTIPLE_EXPRESSIONS,
   QueryValidationException.class,
-  "SELECT * FROM %s WHERE expr(custom_index, 
'foo') AND expr(custom_index, 'bar')");
+  String.format("SELECT * FROM %%s WHERE 
expr(%1$s, 'foo') AND expr(%1$s, 'bar')",
+indexName));
 
 // multiple expressions on different indexes
 createIndex(String.format("CREATE CUSTOM INDEX other_custom_index ON 
%%s(d) USING '%s'", StubIndex.class.getName()));
 assertInvalidThrowMessage(Server.CURRENT_VERSION,
   IndexRestrictions.MULTIPLE_EXPRESSIONS,
   QueryValidationException.class,
-  "SELECT * FROM %s WHERE expr(custom_index, 
'foo') AND expr(other_custom_index, 'bar')");
+  String.format("SELECT * FROM %%s WHERE 
expr(%s, 'foo') AND expr(other_custom_index, 'bar')",
+indexName));
 
 assertInvalidThrowMessage(Server.CURRENT_VERSION,

[5/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.9

2016-08-02 Thread samt

Merge branch 'cassandra-3.0' into cassandra-3.9


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

Branch: refs/heads/cassandra-3.9
Commit: 245fc2adee9351b187e14f115add2b9a9d879e83
Parents: f5078b1 c6cb31e
Author: Sam Tunnicliffe 
Authored: Tue Aug 2 09:14:15 2016 +0100
Committer: Sam Tunnicliffe 
Committed: Tue Aug 2 09:14:15 2016 +0100

--
 .../apache/cassandra/index/CustomIndexTest.java | 38 
 1 file changed, 23 insertions(+), 15 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/245fc2ad/test/unit/org/apache/cassandra/index/CustomIndexTest.java
--

[jira] [Updated] (CASSANDRA-12353) CustomIndexTest can still fail due to async cleanup

2016-08-02 Thread Sam Tunnicliffe (JIRA)


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

Sam Tunnicliffe updated CASSANDRA-12353:

Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

Thanks, committed (with the additional update) to 3.0 in 
{{c6cb31e5f841f19eaccf6995fa7bd643b1e9acc3}} & merged to 3.9 & trunk.

> CustomIndexTest can still fail due to async cleanup
> ---
>
> Key: CASSANDRA-12353
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12353
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
>
> CASSANDRA-11453 didn't quite go far enough in ensuring that indexes in 
> {{CustomIndexTest}} are uniquely named. A couple of duplicates were missed 
> which has lead to at least one failure (on trunk):
>  
> http://cassci.datastax.com/job/trunk_utest/1613/testReport/org.apache.cassandra.index/CustomIndexTest/customIndexRejectsExpressionSyntax/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[3/6] cassandra git commit: Make all index names in CustomIndexTest unique

2016-08-02 Thread samt

Make all index names in CustomIndexTest unique

Patch by Sam Tunnicliffe; reviewed by Stefani Alborghetti for
CASSANDRA-12353


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

Branch: refs/heads/trunk
Commit: c6cb31e5f841f19eaccf6995fa7bd643b1e9acc3
Parents: 10e719c
Author: Sam Tunnicliffe 
Authored: Mon Aug 1 17:58:46 2016 +0100
Committer: Sam Tunnicliffe 
Committed: Tue Aug 2 09:09:50 2016 +0100

--
 .../apache/cassandra/index/CustomIndexTest.java | 38 
 1 file changed, 23 insertions(+), 15 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6cb31e5/test/unit/org/apache/cassandra/index/CustomIndexTest.java
--
diff --git a/test/unit/org/apache/cassandra/index/CustomIndexTest.java 
b/test/unit/org/apache/cassandra/index/CustomIndexTest.java
index f02823c..b8e4185 100644
--- a/test/unit/org/apache/cassandra/index/CustomIndexTest.java
+++ b/test/unit/org/apache/cassandra/index/CustomIndexTest.java
@@ -348,12 +348,14 @@ public class CustomIndexTest extends CQLTester
 {
 Object[] row = row(0, 0, 0, 0);
 createTable("CREATE TABLE %s (a int, b int, c int, d int, PRIMARY KEY 
(a, b))");
+String indexName = currentTable() + "_custom_index";
 execute("INSERT INTO %s (a, b, c, d) VALUES (?, ?, ?, ?)", row);
 
-assertInvalidMessage(String.format(IndexRestrictions.INDEX_NOT_FOUND, 
"custom_index", keyspace(), currentTable()),
- "SELECT * FROM %s WHERE expr(custom_index, 'foo 
bar baz')");
 
-createIndex(String.format("CREATE CUSTOM INDEX custom_index ON %%s(c) 
USING '%s'", StubIndex.class.getName()));
+assertInvalidMessage(String.format(IndexRestrictions.INDEX_NOT_FOUND, 
indexName, keyspace(), currentTable()),
+ String.format("SELECT * FROM %%s WHERE expr(%s, 
'foo bar baz')", indexName));
+
+createIndex(String.format("CREATE CUSTOM INDEX %s ON %%s(c) USING 
'%s'", indexName, StubIndex.class.getName()));
 
 assertInvalidThrowMessage(Server.CURRENT_VERSION,
   
String.format(IndexRestrictions.INDEX_NOT_FOUND, "no_such_index", keyspace(), 
currentTable()),
@@ -361,52 +363,58 @@ public class CustomIndexTest extends CQLTester
   "SELECT * FROM %s WHERE expr(no_such_index, 
'foo bar baz ')");
 
 // simple case
-assertRows(execute("SELECT * FROM %s WHERE expr(custom_index, 'foo bar 
baz')"), row);
-assertRows(execute("SELECT * FROM %s WHERE expr(\"custom_index\", 'foo 
bar baz')"), row);
-assertRows(execute("SELECT * FROM %s WHERE expr(custom_index, $$foo \" 
~~~ bar Baz$$)"), row);
+assertRows(execute(String.format("SELECT * FROM %%s WHERE expr(%s, 
'foo bar baz')", indexName)), row);
+assertRows(execute(String.format("SELECT * FROM %%s WHERE expr(\"%s\", 
'foo bar baz')", indexName)), row);
+assertRows(execute(String.format("SELECT * FROM %%s WHERE expr(%s, 
$$foo \" ~~~ bar Baz$$)", indexName)), row);
 
 // multiple expressions on the same index
 assertInvalidThrowMessage(Server.CURRENT_VERSION,
   IndexRestrictions.MULTIPLE_EXPRESSIONS,
   QueryValidationException.class,
-  "SELECT * FROM %s WHERE expr(custom_index, 
'foo') AND expr(custom_index, 'bar')");
+  String.format("SELECT * FROM %%s WHERE 
expr(%1$s, 'foo') AND expr(%1$s, 'bar')",
+indexName));
 
 // multiple expressions on different indexes
 createIndex(String.format("CREATE CUSTOM INDEX other_custom_index ON 
%%s(d) USING '%s'", StubIndex.class.getName()));
 assertInvalidThrowMessage(Server.CURRENT_VERSION,
   IndexRestrictions.MULTIPLE_EXPRESSIONS,
   QueryValidationException.class,
-  "SELECT * FROM %s WHERE expr(custom_index, 
'foo') AND expr(other_custom_index, 'bar')");
+  String.format("SELECT * FROM %%s WHERE 
expr(%s, 'foo') AND expr(other_custom_index, 'bar')",
+indexName));
 
 assertInvalidThrowMessage(Server.CURRENT_VERSION,
   
StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
   QueryValidationException.class,
-  "SELECT * FROM %s WHERE expr(

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

2016-08-02 Thread samt

Merge branch 'cassandra-3.9' into trunk


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

Branch: refs/heads/trunk
Commit: 8f1501d9c3331b11886bb19e458a2b6881407993
Parents: b637fee 245fc2a
Author: Sam Tunnicliffe 
Authored: Tue Aug 2 09:16:55 2016 +0100
Committer: Sam Tunnicliffe 
Committed: Tue Aug 2 09:16:55 2016 +0100

--
 .../apache/cassandra/index/CustomIndexTest.java | 38 
 1 file changed, 23 insertions(+), 15 deletions(-)
--

[4/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.9

2016-08-02 Thread samt

Merge branch 'cassandra-3.0' into cassandra-3.9


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

Branch: refs/heads/trunk
Commit: 245fc2adee9351b187e14f115add2b9a9d879e83
Parents: f5078b1 c6cb31e
Author: Sam Tunnicliffe 
Authored: Tue Aug 2 09:14:15 2016 +0100
Committer: Sam Tunnicliffe 
Committed: Tue Aug 2 09:14:15 2016 +0100

--
 .../apache/cassandra/index/CustomIndexTest.java | 38 
 1 file changed, 23 insertions(+), 15 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/245fc2ad/test/unit/org/apache/cassandra/index/CustomIndexTest.java
--

[jira] [Updated] (CASSANDRA-12353) CustomIndexTest can still fail due to async cleanup

2016-08-02 Thread Sam Tunnicliffe (JIRA)


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

Sam Tunnicliffe updated CASSANDRA-12353:

Fix Version/s: 3.9
   3.0.9

> CustomIndexTest can still fail due to async cleanup
> ---
>
> Key: CASSANDRA-12353
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12353
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.0.9, 3.9
>
>
> CASSANDRA-11453 didn't quite go far enough in ensuring that indexes in 
> {{CustomIndexTest}} are uniquely named. A couple of duplicates were missed 
> which has lead to at least one failure (on trunk):
>  
> http://cassci.datastax.com/job/trunk_utest/1613/testReport/org.apache.cassandra.index/CustomIndexTest/customIndexRejectsExpressionSyntax/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11968) More metrics on native protocol requests & responses

2016-08-02 Thread Robert Stupp (JIRA)


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

Robert Stupp commented on CASSANDRA-11968:
--

cstar benchmarks show no measurable regression: 
[taylor|http://cstar.datastax.com/graph?command=one_job&stats=1c9cd102-5720-11e6-9fd6-0256e416528f&metric=op_rate&operation=1_user&smoothing=1&show_aggregates=true&xmin=0&xmax=946.66&ymin=0&ymax=294561.3],
 
[blade_11|http://cstar.datastax.com/graph?command=one_job&stats=52292ffa-5707-11e6-beae-0256e416528f&metric=op_rate&operation=1_user&smoothing=1&show_aggregates=true&xmin=0&xmax=2040.5&ymin=0&ymax=142182.7]

> More metrics on native protocol requests & responses
> 
>
> Key: CASSANDRA-11968
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11968
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> Proposal to add more metrics to the native protocol:
> - number of requests per request-type
> - number of responses by response-type
> - size of request messages in bytes
> - size of response messages in bytes
> - number of in-flight requests (from request arrival to response)
> (Will provide a patch soon)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-7384) Collect metrics on queries by consistency level

2016-08-02 Thread Robert Stupp (JIRA)


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

Robert Stupp commented on CASSANDRA-7384:
-

cstar benchmark on 
[taylor|http://cstar.datastax.com/graph?command=one_job&stats=5ce959f2-5733-11e6-a662-0256e416528f&metric=op_rate&operation=1_user&smoothing=1&show_aggregates=true&xmin=0&xmax=956.34&ymin=0&ymax=288623.5]
 is fine, but 
[blade_11|http://cstar.datastax.com/graph?command=one_job&stats=a9475720-57fd-11e6-bc4f-0256e416528f&metric=op_rate&operation=1_user&smoothing=1&show_aggregates=true&xmin=0&xmax=2037.42&ymin=0&ymax=141914.3]
 shows some regression.

> Collect metrics on queries by consistency level
> ---
>
> Key: CASSANDRA-7384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7384
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Vishy Kasar
>Assignee: sankalp kohli
>Priority: Minor
> Fix For: 3.x
>
> Attachments: CASSANDRA-7384_3.0_v2.txt
>
>
> We had cases where cassandra client users thought that they were doing 
> queries at one consistency level but turned out to be not correct. It will be 
> good to collect metrics on number of queries done at various consistency 
> level on the server. See the equivalent JIRA on java driver: 
> https://datastax-oss.atlassian.net/browse/JAVA-354



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11889) LogRecord: file system race condition may cause verify() to fail

2016-08-02 Thread Stefania (JIRA)


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

Stefania commented on CASSANDRA-11889:
--

I propose the following patch for this:

||3.0||3.9||trunk||
|[patch|https://github.com/stef1927/cassandra/commits/11889-3.0]|[patch|https://github.com/stef1927/cassandra/commits/11889-3.9]|[patch|https://github.com/stef1927/cassandra/commits/11889]|
|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-11889-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-11889-3.9-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-11889-testall/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-11889-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-11889-3.9-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-11889-dtest/]|

CI still pending.

> LogRecord: file system race condition may cause verify() to fail
> 
>
> Key: CASSANDRA-11889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11889
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 3.0.x, 3.x
>
>
> The following exception was reported in CASSANDRA-11470. It occurred whilst 
> listing files with compaction in progress:
> {code}
> WARN  [CompactionExecutor:2006] 2016-05-23 18:23:31,694 
> BigTableWriter.java:171 - Writing large partition 
> test_keyspace/test_columnfamily:eda6b9c36f8df6fe596492c3438d7a38e9b109a6 
> (123663388 bytes)
> INFO  [IndexSummaryManager:1] 2016-05-23 18:24:23,731 
> IndexSummaryRedistribution.java:74 - Redistributing index summaries
> WARN  [CompactionExecutor:2006] 2016-05-23 18:24:56,669 
> BigTableWriter.java:171 - Writing large partition 
> test_keyspace/test_columnfamily:05b6b424194dd19ab7cfbcd53c4979768cd859e9 
> (256286063 bytes)
> WARN  [CompactionExecutor:2006] 2016-05-23 18:26:23,575 
> BigTableWriter.java:171 - Writing large partition 
> test_keyspace/test_columnfamily:04e9fac15552b9ae77c27a6cb8d0fd11fdcc24d7 
> (212445557 bytes)
> INFO  [CompactionExecutor:2005] 2016-05-23 18:29:26,839 
> LeveledManifest.java:437 - Adding high-level (L3) 
> BigTableReader(path='/data/cassandra/data/test_keyspace/test_columnfamily_2-d29dd71045a811e59aff6776bf484396/ma-61041-big-Data.db')
>  to candidates
> WARN  [CompactionExecutor:2006] 2016-05-23 18:30:34,154 
> BigTableWriter.java:171 - Writing large partition 
> test_keyspace/test_columnfamily:edbe6f178503be90911dbf29a55b97a4b095a9ec 
> (183852539 bytes)
> INFO  [CompactionExecutor:2006] 2016-05-23 18:31:21,080 
> LeveledManifest.java:437 - Adding high-level (L3) 
> BigTableReader(path='/data/cassandra/data/test_keyspace/test_columnfamily_2-d29dd71045a811e59aff6776bf484396/ma-61042-big-Data.db')
>  to candidates
> ERROR [metrics-graphite-reporter-1-thread-1] 2016-05-23 18:31:21,207 
> LogFile.java:173 - Unexpected files detected for sstable [ma-91034-big], 
> record 
> [REMOVE:[/data/cassandra/data/test_keyspace/test_columnfamily-3996ce80b7ac11e48a9b6776bf484396/ma-91034-big,1463992176000,8][457420186]]:
>  last update time [00:00:00] should have been [08:29:36]
> ERROR [metrics-graphite-reporter-1-thread-1] 2016-05-23 18:31:21,208 
> ScheduledReporter.java:119 - RuntimeException thrown from 
> GraphiteReporter#report. Exception was suppressed.
> java.lang.RuntimeException: Failed to list files in 
> /data/cassandra/data/test_keyspace/test_columnfamily-3996ce80b7ac11e48a9b6776bf484396
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:57)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:547)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$SSTableLister.filter(Directories.java:691)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$SSTableLister.listFiles(Directories.java:662)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$TrueFilesSizeVisitor.(Directories.java:981)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories.getTrueAllocatedSizeIn(Directories.java:893)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories.trueSnapshotsSize(Directories.java:883) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.trueSnapshotsSize(ColumnFamilyStore.java:2332)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.metrics.TableMetrics$32.getValue(TableMetr

[jira] [Commented] (CASSANDRA-12359) BlacklistingCompactionsTest.testBlacklistingWithSizeTieredCompactionStrategy is flaky

2016-08-02 Thread Stefania (JIRA)


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

Stefania commented on CASSANDRA-12359:
--

The multiplexed tests ran with the wrong commit, restarted 
[here|http://cassci.datastax.com/job/stef1927-testall-multiplex/17/].

> BlacklistingCompactionsTest.testBlacklistingWithSizeTieredCompactionStrategy 
> is flaky
> -
>
> Key: CASSANDRA-12359
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12359
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Stefania
>
> example failure:
>   
> [http://cassci.datastax.com/job/cassandra-3.9_testall/50/testReport/junit/org.apache.cassandra.db.compaction/BlacklistingCompactionsTest/testBlacklistingWithSizeTieredCompactionStrategy/]
> Google suggests that this test is somewhat flaky historically, but we don't 
> have logs from any of the older failures any more.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread mck (JIRA)


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

mck commented on CASSANDRA-12351:
-

Bisecting this brought it to this commit and issue:
{noformat}commit d3db33c008542c7044f3ed8c19f3a45679fcf52e
Author: Stefan Podkowinski 
Date:   Thu Apr 7 16:32:56 2016 +0200

Avoid read repairing purgeable tombstones

Patch by Stefan Podkowinski; reviewed by Sylvain Lebresne for 
CASSANDRA-11427{noformat}


> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: mck
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522)
>  [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
> {{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning 
> more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not 
> in 2.2.6.
> I haven't bisected the issue yet, but suspect that this is from 
> CASSANDRA-11502's patch.
> This issue was raised on the mailing list 
> [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

cassandra git commit: Update OHC to v0.4.4 (failed to load Java8 implementation ohc-core-j8)

2016-08-02 Thread snazy

Repository: cassandra
Updated Branches:
  refs/heads/trunk 8f1501d9c -> becd730ad


Update OHC to v0.4.4 (failed to load Java8 implementation ohc-core-j8)

patch by Robert Stupp; reviewed by T Jake Luciani for CASSANDRA-12133


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

Branch: refs/heads/trunk
Commit: becd730ad353cf24338ecf4670872aeac472ef43
Parents: 8f1501d
Author: Robert Stupp 
Authored: Tue Aug 2 10:50:24 2016 +0200
Committer: Robert Stupp 
Committed: Tue Aug 2 10:50:24 2016 +0200

--
 CHANGES.txt|   1 +
 build.xml  |   8 +-
 lib/licenses/ohc-0.4.3.txt | 201 
 lib/licenses/ohc-0.4.4.txt | 201 
 lib/ohc-core-0.4.3.jar | Bin 127053 -> 0 bytes
 lib/ohc-core-0.4.4.jar | Bin 0 -> 135369 bytes
 lib/ohc-core-j8-0.4.3.jar  | Bin 4995 -> 0 bytes
 lib/ohc-core-j8-0.4.4.jar  | Bin 0 -> 4995 bytes
 8 files changed, 206 insertions(+), 205 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/becd730a/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 3de3653..3e7a691 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.10
+ * Upgrade to OHC 0.4.4 (CASSANDRA-12133)
  * Add version command to cassandra-stress (CASSANDRA-12258)
  * Create compaction-stress tool (CASSANDRA-11844)
  * Garbage-collecting compaction operation and schema option (CASSANDRA-7019)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/becd730a/build.xml
--
diff --git a/build.xml b/build.xml
index 20998f2..7cdc1f2 100644
--- a/build.xml
+++ b/build.xml
@@ -437,8 +437,8 @@
 
   
   
-  
-  
+  
+  
   
   

@@ -500,8 +500,8 @@
   
 
 
-
-
+
+
 
 
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/becd730a/lib/licenses/ohc-0.4.3.txt
--
diff --git a/lib/licenses/ohc-0.4.3.txt b/lib/licenses/ohc-0.4.3.txt
deleted file mode 100644
index eb6b5d3..000
--- a/lib/licenses/ohc-0.4.3.txt
+++ /dev/null
@@ -1,201 +0,0 @@
- Apache License
-   Version 2.0, January 2004
-http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-  "License" shall mean the terms and conditions for use, reproduction,
-  and distribution as defined by Sections 1 through 9 of this document.
-
-  "Licensor" shall mean the copyright owner or entity authorized by
-  the copyright owner that is granting the License.
-
-  "Legal Entity" shall mean the union of the acting entity and all
-  other entities that control, are controlled by, or are under common
-  control with that entity. For the purposes of this definition,
-  "control" means (i) the power, direct or indirect, to cause the
-  direction or management of such entity, whether by contract or
-  otherwise, or (ii) ownership of fifty percent (50%) or more of the
-  outstanding shares, or (iii) beneficial ownership of such entity.
-
-  "You" (or "Your") shall mean an individual or Legal Entity
-  exercising permissions granted by this License.
-
-  "Source" form shall mean the preferred form for making modifications,
-  including but not limited to software source code, documentation
-  source, and configuration files.
-
-  "Object" form shall mean any form resulting from mechanical
-  transformation or translation of a Source form, including but
-  not limited to compiled object code, generated documentation,
-  and conversions to other media types.
-
-  "Work" shall mean the work of authorship, whether in Source or
-  Object form, made available under the License, as indicated by a
-  copyright notice that is included in or attached to the work
-  (an example is provided in the Appendix below).
-
-  "Derivative Works" shall mean any work, whether in Source or Object
-  form, that is based on (or derived from) the Work and for which the
-  editorial revisions, annotations, elaborations, or other modifications
-  represent, as a whole, an original work of authorship. For the purposes
-  of this License, Derivative Works shall not include works that remain
-  separable from, or

[jira] [Updated] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread mck (JIRA)


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

mck updated CASSANDRA-12351:

Description: 
After 2.2.6 the following error is thrown during startup, resulting in 
Cassandra not starting.

{noformat}
CassandraDaemon.java:644 - Exception encountered during startup
java.lang.IllegalStateException: One row required, 0 found
at 
org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
 ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at 
org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
 ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at 
org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
 ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at 
org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
 ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522) 
[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
{noformat}

In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
{{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning more 
rows. The additional rows are empty.

These rows are coming out of the row iterator post 2.2.6, where they were not 
in 2.2.6.

This issue was raised on the mailing list 
[here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].

  was:
After 2.2.6 the following error is thrown during startup, resulting in 
Cassandra not starting.

{noformat}
CassandraDaemon.java:644 - Exception encountered during startup
java.lang.IllegalStateException: One row required, 0 found
at 
org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
 ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at 
org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
 ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at 
org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
 ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at 
org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
 ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522) 
[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
{noformat}

In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
{{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning more 
rows. The additional rows are empty.

These rows are coming out of the row iterator post 2.2.6, where they were not 
in 2.2.6.

I haven't bisected the issue yet, but suspect that this is from 
CASSANDRA-11502's patch.

This issue was raised on the mailing list 
[here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].


> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: mck
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> o

[jira] [Updated] (CASSANDRA-12133) Failed to load Java8 implementation ohc-core-j8

2016-08-02 Thread Robert Stupp (JIRA)


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

Robert Stupp updated CASSANDRA-12133:
-
   Resolution: Fixed
Fix Version/s: (was: 3.0.x)
   3.10
   Status: Resolved  (was: Ready to Commit)

Thanks!
Committed as 
[becd730ad353cf24338ecf4670872aeac472ef43|https://github.com/apache/cassandra/commit/becd730ad353cf24338ecf4670872aeac472ef43]
 to [trunk|https://github.com/apache/cassandra/tree/trunk]


> Failed to load Java8 implementation ohc-core-j8
> ---
>
> Key: CASSANDRA-12133
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12133
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Ubuntu 14.04, Java 1.8.0_91
>Reporter: Mike
>Assignee: Robert Stupp
>Priority: Trivial
> Fix For: 3.10
>
>
> After enabling row cache in cassandra.yaml by setting row_cache_size_in_mb, I 
> receive this warning in system.log during startup:
> {noformat}
> WARN  [main] 2016-07-05 13:36:14,671 Uns.java:169 - Failed to load Java8 
> implementation ohc-core-j8 : java.lang.NoSuchMethodException: 
> org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12106) Add ability to blacklist a CQL partition so all requests are ignored

2016-08-02 Thread Benjamin Lerer (JIRA)


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

Benjamin Lerer commented on CASSANDRA-12106:


bq. Regarding keeping this cache b/w co-ordinator and replicas, we chose 
replica since it is more efficient to keep it there since this list can grow 
and we want to reduce the things in memory.

In my opinion, we should probably look at the pros and cons of each approach. 
Implementing the functionnalty at the coordinator level will result in a much 
smaller change. The logic will be easier to understand/maintain and there will 
less chances to let a problem slip through. 
I agree, that amount of memory used could be a problem at some point. How much 
memory do you think you will need in the worst case scenario that you have seen 
so far? Is it really unrealistic to have it at the coordinator level? 


> Add ability to blacklist a CQL partition so all requests are ignored
> 
>
> Key: CASSANDRA-12106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12106
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Geoffrey Yu
>Assignee: Geoffrey Yu
>Priority: Minor
> Fix For: 4.x
>
> Attachments: 12106-trunk.txt
>
>
> Sometimes reads/writes to a given partition may cause problems due to the 
> data present. It would be useful to have a manual way to blacklist such 
> partitions so all read and write requests to them are rejected.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12106) Add ability to blacklist a CQL partition so all requests are ignored

2016-08-02 Thread Benjamin Lerer (JIRA)


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

Benjamin Lerer updated CASSANDRA-12106:
---
Status: Open  (was: Patch Available)

Waiting for the new patch mentionned in a previous comment.

> Add ability to blacklist a CQL partition so all requests are ignored
> 
>
> Key: CASSANDRA-12106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12106
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Geoffrey Yu
>Assignee: Geoffrey Yu
>Priority: Minor
> Fix For: 4.x
>
> Attachments: 12106-trunk.txt
>
>
> Sometimes reads/writes to a given partition may cause problems due to the 
> data present. It would be useful to have a manual way to blacklist such 
> partitions so all read and write requests to them are rejected.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11126) select_distinct_with_deletions_test failing on non-vnode environments

2016-08-02 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-11126:
--

I'm sorry but that is still not really working for me. I'm able to run the 
first command you provide, but that runs all upgrade test which is useless to 
me for the sake of debugging. If I try to run only the test for that issue 
however, that doesn't seem to work:
{noformat}
$ RUN_STATIC_UPGRADE_MATRIX=true CASSANDRA_VERSION=git:trunk 
JAVA8_HOME=/usr/lib/jvm/java-8-openjdk JAVA7_HOME=/usr/lib/jvm/java-7-openjdk 
python2.7 ./run_dtests.py --vnodes false  --nose-options='-v' 
upgrade_tests/cql_tests.py:TestCQL.select_distinct_with_deletions_test  
   
About to run nosetests with config objects:
GlobalConfigObject(vnodes=False)

Running dtests with config object GlobalConfigObject(vnodes=False)
select_distinct_with_deletions_test (upgrade_tests.cql_tests.TestCQL) ... ERROR

==
ERROR: select_distinct_with_deletions_test (upgrade_tests.cql_tests.TestCQL)
--
Traceback (most recent call last):
  File "/home/pcmanus/Git/cassandra-dtest/upgrade_tests/upgrade_base.py", line 
53, in setUp
.format(self.UPGRADE_PATH.starting_version, 
self.UPGRADE_PATH.starting_meta.java_version))
AttributeError: 'NoneType' object has no attribute 'starting_version'
 >> begin captured logging << 
ccm: INFO: Fetching Cassandra updates...
dtest: DEBUG: skipping class creation, no testing of 'current' to 'current' 
(for current_2_2_x upgrade to current_3_0_x)
dtest: DEBUG: skipping class creation, no testing of 'current' to 'current' 
(for current_2_2_x upgrade to current_3_x)
dtest: DEBUG: skipping class creation, no testing of 'indev' to 'indev' (for 
indev_3_0_x upgrade to indev_3_x)
dtest: DEBUG: skipping class creation, no testing of 'indev' to 'current' (for 
indev_3_0_x upgrade to current_3_x)
dtest: DEBUG: skipping class creation, no testing of 'indev' to 'indev' (for 
indev_2_2_x upgrade to indev_3_0_x)
dtest: DEBUG: skipping class creation, no testing of 'indev' to 'current' (for 
indev_2_2_x upgrade to current_3_0_x)
dtest: DEBUG: skipping class creation, no testing of 'indev' to 'indev' (for 
indev_2_2_x upgrade to indev_3_x)
dtest: DEBUG: skipping class creation, no testing of 'indev' to 'current' (for 
indev_2_2_x upgrade to current_3_x)
dtest: DEBUG: skipping class creation as a version is undefined (this is 
normal), versions: None and _VersionMeta(name='indev_2_1_x', family='2.1.x', 
variant='indev', version='git:cassandra-2.1', min_proto_v=1, max_proto_v=3, 
java_versions=(7, 8))
dtest: DEBUG: skipping class creation as a version is undefined (this is 
normal), versions: None and _VersionMeta(name='current_2_1_x', family='2.1.x', 
variant='current', version='2.1.15', min_proto_v=1, max_proto_v=3, 
java_versions=(7, 8))
dtest: DEBUG: skipping class creation, no testing of 'indev' to 'indev' (for 
indev_2_1_x upgrade to indev_2_2_x)
dtest: DEBUG: skipping class creation, no testing of 'indev' to 'current' (for 
indev_2_1_x upgrade to current_2_2_x)
dtest: DEBUG: skipping class creation, no testing of 'indev' to 'indev' (for 
indev_2_1_x upgrade to indev_3_0_x)
dtest: DEBUG: skipping class creation, no testing of 'indev' to 'current' (for 
indev_2_1_x upgrade to current_3_0_x)
dtest: DEBUG: skipping class creation, no testing of 'indev' to 'indev' (for 
indev_2_1_x upgrade to indev_3_x)
dtest: DEBUG: skipping class creation, no testing of 'indev' to 'current' (for 
indev_2_1_x upgrade to current_3_x)
dtest: DEBUG: skipping class creation as a version is undefined (this is 
normal), versions: _VersionMeta(name='current_2_0_x', family='2.0.x', 
variant='current', version='2.0.17', min_proto_v=1, max_proto_v=2, 
java_versions=(7,)) and None
dtest: DEBUG: skipping class creation, no testing of 'current' to 'current' 
(for current_2_0_x upgrade to current_2_1_x)
dtest: DEBUG: skipping class creation, no testing of 'current' to 'current' 
(for current_2_1_x upgrade to current_2_2_x)
dtest: DEBUG: skipping class creation, no testing of 'current' to 'current' 
(for current_2_1_x upgrade to current_3_0_x)
dtest: DEBUG: skipping class creation, no testing of 'current' to 'current' 
(for current_2_1_x upgrade to current_3_x)
dtest: DEBUG: skipping class creation, no testing of 'current' to 'current' 
(for current_3_0_x upgrade to current_3_x)
- >> end captured logging << -
{noformat}
And even if this was working, it still sound like this would run the test for 
every possible branch it knows about, which would also be painful for debugging.

What is needed for debugging those upgrade test is the ability

[jira] [Commented] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-12351:
--

Have you checked this isn't already fixed by CASSANDRA-12143?

> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: mck
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522)
>  [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
> {{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning 
> more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not 
> in 2.2.6.
> This issue was raised on the mailing list 
> [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread mck (JIRA)


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

mck commented on CASSANDRA-12351:
-

No, but the patch is indeed on the same line.

It looks like it should be 

if (data != null)
data = removeDeletedCF(data, gcBefore(filter.timestamp));

instead of 

if (data != null)
data.purgeTombstones(gcBefore(filter.timestamp));

The former ensures that data becomes {{null}} when nothing remains in it (cells 
or deletion info).

> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: mck
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522)
>  [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
> {{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning 
> more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not 
> in 2.2.6.
> This issue was raised on the mailing list 
> [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread mck (JIRA)


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

mck edited comment on CASSANDRA-12351 at 8/2/16 10:24 AM:
--

No, but the patch is indeed on the same line.

It looks like it should be 
{code}if (data != null)
data = removeDeletedCF(data, gcBefore(filter.timestamp));{code}
instead of 
{code}if (data != null)
data.purgeTombstones(gcBefore(filter.timestamp));{code}

The former ensures that data becomes {{null}} when nothing remains in it (cells 
or deletion info).


was (Author: michaelsembwever):
No, but the patch is indeed on the same line.

It looks like it should be 

{codeif (data != null)
data = removeDeletedCF(data, 
gcBefore(filter.timestamp));{code

instead of 

{codeif (data != null)
data.purgeTombstones(gcBefore(filter.timestamp));{code

The former ensures that data becomes {{null}} when nothing remains in it (cells 
or deletion info).

> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: mck
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522)
>  [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
> {{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning 
> more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not 
> in 2.2.6.
> This issue was raised on the mailing list 
> [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread mck (JIRA)


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

mck edited comment on CASSANDRA-12351 at 8/2/16 10:23 AM:
--

No, but the patch is indeed on the same line.

It looks like it should be 

{codeif (data != null)
data = removeDeletedCF(data, 
gcBefore(filter.timestamp));{code

instead of 

{codeif (data != null)
data.purgeTombstones(gcBefore(filter.timestamp));{code

The former ensures that data becomes {{null}} when nothing remains in it (cells 
or deletion info).


was (Author: michaelsembwever):
No, but the patch is indeed on the same line.

It looks like it should be 

if (data != null)
data = removeDeletedCF(data, gcBefore(filter.timestamp));

instead of 

if (data != null)
data.purgeTombstones(gcBefore(filter.timestamp));

The former ensures that data becomes {{null}} when nothing remains in it (cells 
or deletion info).

> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: mck
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522)
>  [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
> {{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning 
> more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not 
> in 2.2.6.
> This issue was raised on the mailing list 
> [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread mck (JIRA)


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

mck commented on CASSANDRA-12351:
-

I'm working on a unit test based off above.

> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: mck
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522)
>  [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
> {{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning 
> more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not 
> in 2.2.6.
> This issue was raised on the mailing list 
> [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-12351:
--

It's true we should probably call {{removedDeletedCF}} but I don't think I 
understand why not doing so would break LegacySchemaTables. I mean, if 
{{removeDeleteldCF}} makes a difference compared to just {{purgeTombstones}}, 
that imply the partition is empty and has only purgeable top-level or range 
tombstones (those are the only things {{purgeTombstones}} removes). But such 
partition shouldn't create any result on the CQL front, whether or not we do 
any purging, and as {{UntypedResultSet}} uses the {{ResultSet}} processed by 
CQL, this shouldn't make any difference to 
{{createKeyspaceFromSchemaPartition}}.

Anyway, I'm tempted to just revert CASSANDRA-11427 as it should never have been 
committed in 2.2 in the first place and that's the 2nd problem it creates, but 
I'd rather understand what's going on first. Could you provide steps to 
reproduce (or, even better, a unit test or dtest to reproduce) since you seem 
to be able to?

> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: mck
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522)
>  [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
> {{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning 
> more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not 
> in 2.2.6.
> This issue was raised on the mailing list 
> [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12360) Unable to parse negative dates

2016-08-02 Thread Bryn Cooke (JIRA)

Bryn Cooke created CASSANDRA-12360:
--

 Summary: Unable to parse negative dates
 Key: CASSANDRA-12360
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12360
 Project: Cassandra
  Issue Type: Bug
Reporter: Bryn Cooke



{code}
cqlsh:date_test> DESC test;

CREATE TABLE date_test.test (
date timestamp PRIMARY KEY
) ...
cqlsh:date_test> INSERT INTO test (date) VALUES ('-0407-12-27T00:00:00Z');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Unable to 
coerce '-0407-12-27T00:00:00Z' to a formatted date (long)"
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread mck (JIRA)


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

mck commented on CASSANDRA-12351:
-

{quote}It's true we should probably call removedDeletedCF but I don't think I 
understand why not doing so would break LegacySchemaTables. I mean, if 
removeDeleteldCF makes a difference compared to just purgeTombstones, that 
imply the partition is empty and has only purgeable top-level or range 
tombstones (those are the only things purgeTombstones removes). But such 
partition shouldn't create any result on the CQL front, whether or not we do 
any purging, and as UntypedResultSet uses the ResultSet processed by CQL, this 
shouldn't make any difference to createKeyspaceFromSchemaPartition.{quote}

It makes a difference when it gets to {{readSchemaFromSystemTables(..)}} and 
doesn't skip the "empty" row because {{isEmptySchemaPartition(partition)}} only 
checks for a null cf. A quick scan through the code gave me the impression that 
{{row.cf == null}} was checked in places while {{!partition.cf.hasColumns() && 
!isMarkedForDelete()}} wasn't. 

If the code is /sensitive/ in this way maybe adding some assert statements into 
CF would be a good idea, like
{{assert hasColumns() || isMarkedForDelete()}}

> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: mck
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522)
>  [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
> {{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning 
> more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not 
> in 2.2.6.
> This issue was raised on the mailing list 
> [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread mck (JIRA)


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

mck edited comment on CASSANDRA-12351 at 8/2/16 11:21 AM:
--

{quote}It's true we should probably call removedDeletedCF but I don't think I 
understand why not doing so would break LegacySchemaTables. I mean, if 
removeDeleteldCF makes a difference compared to just purgeTombstones, that 
imply the partition is empty and has only purgeable top-level or range 
tombstones (those are the only things purgeTombstones removes). But such 
partition shouldn't create any result on the CQL front, whether or not we do 
any purging, and as UntypedResultSet uses the ResultSet processed by CQL, this 
shouldn't make any difference to createKeyspaceFromSchemaPartition.{quote}

It makes a difference when it gets to {{readSchemaFromSystemTables(..)}} and 
doesn't skip the "empty" row because {{isEmptySchemaPartition(partition)}} only 
checks for a null cf. A quick scan through the code gave me the impression that 
{{row.cf == null}} was checked in places while {{!partition.cf.hasColumns() && 
!isMarkedForDelete()}} wasn't. 

If the code is /sensitive/ in this way maybe adding some assert statements into 
CFS would be a good idea, like
{{assert cf == null || cf.hasColumns() || cf.isMarkedForDelete()}}


was (Author: michaelsembwever):
{quote}It's true we should probably call removedDeletedCF but I don't think I 
understand why not doing so would break LegacySchemaTables. I mean, if 
removeDeleteldCF makes a difference compared to just purgeTombstones, that 
imply the partition is empty and has only purgeable top-level or range 
tombstones (those are the only things purgeTombstones removes). But such 
partition shouldn't create any result on the CQL front, whether or not we do 
any purging, and as UntypedResultSet uses the ResultSet processed by CQL, this 
shouldn't make any difference to createKeyspaceFromSchemaPartition.{quote}

It makes a difference when it gets to {{readSchemaFromSystemTables(..)}} and 
doesn't skip the "empty" row because {{isEmptySchemaPartition(partition)}} only 
checks for a null cf. A quick scan through the code gave me the impression that 
{{row.cf == null}} was checked in places while {{!partition.cf.hasColumns() && 
!isMarkedForDelete()}} wasn't. 

If the code is /sensitive/ in this way maybe adding some assert statements into 
CF would be a good idea, like
{{assert hasColumns() || isMarkedForDelete()}}

> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: mck
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522)
>  [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
> {{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning 
> more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not 
> in 2.2.6.
> This issue was raised on the mailing list 
> [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.146973321478

[jira] [Commented] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread mck (JIRA)


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

mck commented on CASSANDRA-12351:
-

{quote}If the code is /sensitive/ in this way maybe adding some assert 
statements into CFS would be a good idea, like
assert cf == null || cf.hasColumns() || cf.isMarkedForDelete(){quote}

I take that back. This code is all over the place. It's a shame that CF can 
have multiple states representing the same thing.

I can apply the patch, along with a unit test. But a number of tests in 
ColumnFamilyStoreTest needs adjustment.
I can apply a different patch, one that improves 
{{isEmptySchemaPartition(partition)}}.
Or you [~slebresne] can revert CASSANDRA-11427.

> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: mck
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522)
>  [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
> {{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning 
> more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not 
> in 2.2.6.
> This issue was raised on the mailing list 
> [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread mck (JIRA)


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

mck edited comment on CASSANDRA-12351 at 8/2/16 11:38 AM:
--

{quote}If the code is /sensitive/ in this way maybe adding some assert 
statements into CFS would be a good idea, like
assert cf == null || cf.hasColumns() || cf.isMarkedForDelete(){quote}

I take that back. The code is all over the place. It's a shame that CF can have 
multiple states representing the same thing.

I can apply the patch, along with a unit test. But a number of tests in 
ColumnFamilyStoreTest needs adjustment.
I can apply a different patch, one that improves 
{{isEmptySchemaPartition(partition)}}.
Or you [~slebresne] can revert CASSANDRA-11427.


was (Author: michaelsembwever):
{quote}If the code is /sensitive/ in this way maybe adding some assert 
statements into CFS would be a good idea, like
assert cf == null || cf.hasColumns() || cf.isMarkedForDelete(){quote}

I take that back. This code is all over the place. It's a shame that CF can 
have multiple states representing the same thing.

I can apply the patch, along with a unit test. But a number of tests in 
ColumnFamilyStoreTest needs adjustment.
I can apply a different patch, one that improves 
{{isEmptySchemaPartition(partition)}}.
Or you [~slebresne] can revert CASSANDRA-11427.

> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: mck
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522)
>  [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
> {{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning 
> more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not 
> in 2.2.6.
> This issue was raised on the mailing list 
> [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread mck (JIRA)


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

mck updated CASSANDRA-12351:

Attachment: 12351-2.2.txt

> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: mck
> Attachments: 12351-2.2.txt
>
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522)
>  [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
> {{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning 
> more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not 
> in 2.2.6.
> This issue was raised on the mailing list 
> [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread mck (JIRA)


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

mck commented on CASSANDRA-12351:
-

{quote}I can apply the patch, along with a unit test. But a number of tests in 
ColumnFamilyStoreTest needs adjustment.{quote}
Attached for this is the patch 12351-2.2.txt 

Waiting to hear which approach is to be taken.

> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: mck
> Attachments: 12351-2.2.txt
>
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522)
>  [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
> {{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning 
> more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not 
> in 2.2.6.
> This issue was raised on the mailing list 
> [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CASSANDRA-10664) Fix failing tests

2016-08-02 Thread Joshua McKenzie (JIRA)


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

Joshua McKenzie resolved CASSANDRA-10664.
-
   Resolution: Fixed
Fix Version/s: (was: 3.0.x)

> Fix failing tests
> -
>
> Key: CASSANDRA-10664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10664
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sylvain Lebresne
>  Labels: dtest
>
> This is the continuation of CASSANDRA-10166, just a meta-ticket to group all 
> tickets related to fixing any unit test or dtest.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12361) dtest failure in cql_tests.MiscellaneousCQLTester.prepared_statement_invalidation_test

2016-08-02 Thread Sean McCarthy (JIRA)

Sean McCarthy created CASSANDRA-12361:
-

 Summary: dtest failure in 
cql_tests.MiscellaneousCQLTester.prepared_statement_invalidation_test
 Key: CASSANDRA-12361
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12361
 Project: Cassandra
  Issue Type: Test
Reporter: Sean McCarthy
Assignee: DS Test Eng
 Attachments: node1.log

example failure:

http://cassci.datastax.com/job/cassandra-2.1_dtest/497/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test

{code}
Stacktrace

  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
  File "/home/automaton/cassandra-dtest/cql_tests.py", line 481, in 
prepared_statement_invalidation_test
result = session.execute(wildcard_prepared.bind(None))
  File "cassandra/cluster.py", line 1961, in cassandra.cluster.Session.execute 
(cassandra/cluster.c:34076)
return self.execute_async(query, parameters, trace, custom_payload, 
timeout, execution_profile).result()
  File "cassandra/cluster.py", line 3649, in 
cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69755)
raise self._final_exception
"Cannot read past the end of the file
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12361) dtest failure in cql_tests.MiscellaneousCQLTester.prepared_statement_invalidation_test

2016-08-02 Thread Sean McCarthy (JIRA)


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

Sean McCarthy updated CASSANDRA-12361:
--
Description: 
example failure:

http://cassci.datastax.com/job/cassandra-2.1_dtest/497/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test

{code}
Stacktrace

  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
  File "/home/automaton/cassandra-dtest/cql_tests.py", line 481, in 
prepared_statement_invalidation_test
result = session.execute(wildcard_prepared.bind(None))
  File "cassandra/cluster.py", line 1961, in cassandra.cluster.Session.execute 
(cassandra/cluster.c:34076)
return self.execute_async(query, parameters, trace, custom_payload, 
timeout, execution_profile).result()
  File "cassandra/cluster.py", line 3649, in 
cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69755)
raise self._final_exception
"Cannot read past the end of the file
{code}

Related failures:
http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/250/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/

  was:
example failure:

http://cassci.datastax.com/job/cassandra-2.1_dtest/497/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test

{code}
Stacktrace

  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
  File "/home/automaton/cassandra-dtest/cql_tests.py", line 481, in 
prepared_statement_invalidation_test
result = session.execute(wildcard_prepared.bind(None))
  File "cassandra/cluster.py", line 1961, in cassandra.cluster.Session.execute 
(cassandra/cluster.c:34076)
return self.execute_async(query, parameters, trace, custom_payload, 
timeout, execution_profile).result()
  File "cassandra/cluster.py", line 3649, in 
cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69755)
raise self._final_exception
"Cannot read past the end of the file
{code}


> dtest failure in 
> cql_tests.MiscellaneousCQLTester.prepared_statement_invalidation_test
> --
>
> Key: CASSANDRA-12361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12361
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: DS Test Eng
>  Labels: dtest
> Attachments: node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/497/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/cql_tests.py", line 481, in 
> prepared_statement_invalidation_test
> result = session.execute(wildcard_prepared.bind(None))
>   File "cassandra/cluster.py", line 1961, in 
> cassandra.cluster.Session.execute (cassandra/cluster.c:34076)
> return self.execute_async(query, parameters, trace, custom_payload, 
> timeout, execution_profile).result()
>   File "cassandra/cluster.py", line 3649, in 
> cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69755)
> raise self._final_exception
> "Cannot read past the end of the file
> {code}
> Related failures:
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/250/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12039) Add an index callback to be notified post bootstrap and before joining the ring

2016-08-02 Thread Sergio Bossa (JIRA)


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

Sergio Bossa commented on CASSANDRA-12039:
--

I'm writing dtests for all cases requiring a call to the pre-join task, and I 
noticed the following:

1) There's a bootstrap test ({{bootstrap_on_write_survey_test}}) that 
explicitly verifies the bootstrap state is left in progress after survey mode, 
so it seems to me we can actually rely on it to signal the bootstrap status on 
joining; pinging again [~brandon.williams] for feedback.

2) There's one more problem related to calling the pre-join task when joining 
*without* bootstrapping; in such case, the node doesn't wait for the migrations 
to complete (that is, {{MigrationManager#waitUntilReadyForBootstrap()}} is 
called only if bootstrapping), so it misses to wait for the new schema 
containing the column family, and no task is invoked. Should we run the 
{{MigrationManager}} checks regardless if the node is actually streaming or not 
(I'd say so)? /cc [~beobal] [~iamaleksey]

> Add an index callback to be notified post bootstrap and before joining the 
> ring
> ---
>
> Key: CASSANDRA-12039
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12039
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Sergio Bossa
>Assignee: Sergio Bossa
>
> Custom index implementations might need to be notified when the node finishes 
> bootstrapping in order to execute some blocking tasks before the node itself 
> goes into NORMAL state.
> This is a proposal to add such functionality, which should roughly require 
> the following:
> 1) Add a {{getPostBootstrapTask}} callback to the {{Index}} interface.
> 2) Add an {{executePostBootstrapBlockingTasks}} method to 
> {{SecondaryIndexManager}} calling into the previously mentioned callback.
> 3) Hook that into {{StorageService#joinTokenRing}}.
> Thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12361) dtest failure in cql_tests.MiscellaneousCQLTester.prepared_statement_invalidation_test

2016-08-02 Thread Sean McCarthy (JIRA)


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

Sean McCarthy updated CASSANDRA-12361:
--
Description: 
example failure:

http://cassci.datastax.com/job/cassandra-2.1_dtest/497/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test

{code}
Stacktrace

  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
  File "/home/automaton/cassandra-dtest/cql_tests.py", line 481, in 
prepared_statement_invalidation_test
result = session.execute(wildcard_prepared.bind(None))
  File "cassandra/cluster.py", line 1961, in cassandra.cluster.Session.execute 
(cassandra/cluster.c:34076)
return self.execute_async(query, parameters, trace, custom_payload, 
timeout, execution_profile).result()
  File "cassandra/cluster.py", line 3649, in 
cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69755)
raise self._final_exception
"Cannot read past the end of the file
{code}

Related failures:
http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/250/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/
http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/270/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/

  was:
example failure:

http://cassci.datastax.com/job/cassandra-2.1_dtest/497/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test

{code}
Stacktrace

  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
  File "/home/automaton/cassandra-dtest/cql_tests.py", line 481, in 
prepared_statement_invalidation_test
result = session.execute(wildcard_prepared.bind(None))
  File "cassandra/cluster.py", line 1961, in cassandra.cluster.Session.execute 
(cassandra/cluster.c:34076)
return self.execute_async(query, parameters, trace, custom_payload, 
timeout, execution_profile).result()
  File "cassandra/cluster.py", line 3649, in 
cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69755)
raise self._final_exception
"Cannot read past the end of the file
{code}

Related failures:
http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/250/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/


> dtest failure in 
> cql_tests.MiscellaneousCQLTester.prepared_statement_invalidation_test
> --
>
> Key: CASSANDRA-12361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12361
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: DS Test Eng
>  Labels: dtest
> Attachments: node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/497/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/cql_tests.py", line 481, in 
> prepared_statement_invalidation_test
> result = session.execute(wildcard_prepared.bind(None))
>   File "cassandra/cluster.py", line 1961, in 
> cassandra.cluster.Session.execute (cassandra/cluster.c:34076)
> return self.execute_async(query, parameters, trace, custom_payload, 
> timeout, execution_profile).result()
>   File "cassandra/cluster.py", line 3649, in 
> cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69755)
> raise self._final_exception
> "Cannot read past the end of the file
> {code}
> Related failures:
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/250/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/
> http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/270/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12361) dtest failure in cql_tests.MiscellaneousCQLTester.prepared_statement_invalidation_test

2016-08-02 Thread Sean McCarthy (JIRA)


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

Sean McCarthy updated CASSANDRA-12361:
--
Description: 
example failure:

http://cassci.datastax.com/job/cassandra-2.1_dtest/497/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test

{code}
Stacktrace

  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
  File "/home/automaton/cassandra-dtest/cql_tests.py", line 481, in 
prepared_statement_invalidation_test
result = session.execute(wildcard_prepared.bind(None))
  File "cassandra/cluster.py", line 1961, in cassandra.cluster.Session.execute 
(cassandra/cluster.c:34076)
return self.execute_async(query, parameters, trace, custom_payload, 
timeout, execution_profile).result()
  File "cassandra/cluster.py", line 3649, in 
cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69755)
raise self._final_exception
"Cannot read past the end of the file
{code}

Related failures:
http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/250/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/
http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/270/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/
http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/380/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/

  was:
example failure:

http://cassci.datastax.com/job/cassandra-2.1_dtest/497/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test

{code}
Stacktrace

  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
  File "/home/automaton/cassandra-dtest/cql_tests.py", line 481, in 
prepared_statement_invalidation_test
result = session.execute(wildcard_prepared.bind(None))
  File "cassandra/cluster.py", line 1961, in cassandra.cluster.Session.execute 
(cassandra/cluster.c:34076)
return self.execute_async(query, parameters, trace, custom_payload, 
timeout, execution_profile).result()
  File "cassandra/cluster.py", line 3649, in 
cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69755)
raise self._final_exception
"Cannot read past the end of the file
{code}

Related failures:
http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/250/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/
http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/270/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/


> dtest failure in 
> cql_tests.MiscellaneousCQLTester.prepared_statement_invalidation_test
> --
>
> Key: CASSANDRA-12361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12361
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: DS Test Eng
>  Labels: dtest
> Attachments: node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/497/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/cql_tests.py", line 481, in 
> prepared_statement_invalidation_test
> result = session.execute(wildcard_prepared.bind(None))
>   File "cassandra/cluster.py", line 1961, in 
> cassandra.cluster.Session.execute (cassandra/cluster.c:34076)
> return self.execute_async(query, parameters, trace, custom_payload, 
> timeout, execution_profile).result()
>   File "cassandra/cluster.py", line 3649, in 
> cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69755)
> raise self._final_exception
> "Cannot read past the end of the file
> {code}
> Related failures:
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/250/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/
> http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/270/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/
> http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/380/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12323) dtest failure in compaction_test.TestCompaction_with_DateTieredCompactionStrategy.bloomfilter_size_test

2016-08-02 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson commented on CASSANDRA-12323:
-

the failure was due to the node having too many sstables after compaction

and the reason for that seems to be that the first 2 sstables were created 
before 00:00, the other 3 were created after, and it looks like they end up in 
different windows with DTCS when that happens.

Patch to factor in number of sstables 
[here|https://github.com/krummas/cassandra-dtest/commits/marcuse/12323]

Test run 
[here|https://cassci.datastax.com/view/Dev/view/krummas/job/krummas-marcuse-3.9-dtest/]

> dtest failure in 
> compaction_test.TestCompaction_with_DateTieredCompactionStrategy.bloomfilter_size_test
> ---
>
> Key: CASSANDRA-12323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12323
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Craig Kodman
>Assignee: Marcus Eriksson
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.9_novnode_dtest/19/testReport/compaction_test/TestCompaction_with_DateTieredCompactionStrategy/bloomfilter_size_test
> 500352 not less than or equal to 15



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12323) dtest failure in compaction_test.TestCompaction_with_DateTieredCompactionStrategy.bloomfilter_size_test

2016-08-02 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson updated CASSANDRA-12323:

Status: Patch Available  (was: Open)

> dtest failure in 
> compaction_test.TestCompaction_with_DateTieredCompactionStrategy.bloomfilter_size_test
> ---
>
> Key: CASSANDRA-12323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12323
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Craig Kodman
>Assignee: Marcus Eriksson
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.9_novnode_dtest/19/testReport/compaction_test/TestCompaction_with_DateTieredCompactionStrategy/bloomfilter_size_test
> 500352 not less than or equal to 15



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12362) dtest failure in upgrade_tests.paging_test.TestPagingDatasetChangesNodes2RF1_Upgrade_current_3_x_To_indev_3_x.test_row_TTL_expiry_during_paging

2016-08-02 Thread Sean McCarthy (JIRA)

Sean McCarthy created CASSANDRA-12362:
-

 Summary: dtest failure in 
upgrade_tests.paging_test.TestPagingDatasetChangesNodes2RF1_Upgrade_current_3_x_To_indev_3_x.test_row_TTL_expiry_during_paging
 Key: CASSANDRA-12362
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12362
 Project: Cassandra
  Issue Type: Test
Reporter: Sean McCarthy
Assignee: DS Test Eng
 Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
node2_debug.log, node2_gc.log

example failure:

http://cassci.datastax.com/job/trunk_dtest_upgrade/5/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes2RF1_Upgrade_current_3_x_To_indev_3_x/test_row_TTL_expiry_during_paging

{code}
Stacktrace

  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
  File "/home/automaton/cassandra-dtest/upgrade_tests/paging_test.py", line 
1217, in test_row_TTL_expiry_during_paging
self.assertEqual(pf.pagecount(), 3)
  File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
assertion_func(first, second, msg=msg)
  File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual
raise self.failureException(msg)
"2 != 3
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12363) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_0_x_To_indev_3_x.list_test

2016-08-02 Thread Sean McCarthy (JIRA)

Sean McCarthy created CASSANDRA-12363:
-

 Summary: dtest failure in 
upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_0_x_To_indev_3_x.list_test
 Key: CASSANDRA-12363
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12363
 Project: Cassandra
  Issue Type: Test
Reporter: Sean McCarthy
Assignee: DS Test Eng
 Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log

example failure:

http://cassci.datastax.com/job/trunk_dtest_upgrade/5/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_0_x_To_indev_3_x/list_test

{code}
Stacktrace

  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
  File "/home/automaton/cassandra-dtest/upgrade_tests/cql_tests.py", line 1375, 
in list_test
assert_one(cursor, "SELECT tags FROM user", [['foo', 'bar', 'foo', 
'foobar']])
  File "/home/automaton/cassandra-dtest/assertions.py", line 124, in assert_one
assert list_res == [expected], "Expected {} from {}, but got 
{}".format([expected], query, list_res)
"Expected [[['foo', 'bar', 'foo', 'foobar']]] from SELECT tags FROM user, but 
got [[[u'foo', u'foo', u'bar', u'foo', u'foobar']]]
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12364) dtest failure in upgrade_tests.paging_test.TestPagingDatasetChangesNodes3RF3_Upgrade_current_3_x_To_indev_3_x.test_cell_TTL_expiry_during_paging

2016-08-02 Thread Sean McCarthy (JIRA)

Sean McCarthy created CASSANDRA-12364:
-

 Summary: dtest failure in 
upgrade_tests.paging_test.TestPagingDatasetChangesNodes3RF3_Upgrade_current_3_x_To_indev_3_x.test_cell_TTL_expiry_during_paging
 Key: CASSANDRA-12364
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12364
 Project: Cassandra
  Issue Type: Test
Reporter: Sean McCarthy
Assignee: DS Test Eng
 Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log

example failure:

http://cassci.datastax.com/job/trunk_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_Upgrade_current_3_x_To_indev_3_x/test_cell_TTL_expiry_during_paging

{code}
Error Message

Unexpected error in log, see stdout
{code}

{code}
Standard Output

http://git-wip-us.apache.org/repos/asf/cassandra.git 
git:5051c0f6eb3f984600600c9577d6b5ece9038c74
Unexpected error in node1 log, error: 
ERROR [InternalResponseStage:4] 2016-07-28 03:23:02,097 
CassandraDaemon.java:217 - Exception in thread 
Thread[InternalResponseStage:4,5,main]
java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut 
down
at 
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
 ~[apache-cassandra-3.7.jar:3.7]
at 
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) 
~[na:1.8.0_51]
at 
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.ColumnFamilyStore.waitForFlushes(ColumnFamilyStore.java:930)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.ColumnFamilyStore.forceFlush(ColumnFamilyStore.java:892)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.lambda$flush$1(SchemaKeyspace.java:279)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace$$Lambda$200/2113926365.accept(Unknown
 Source) ~[na:na]
at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_51]
at 
org.apache.cassandra.schema.SchemaKeyspace.flush(SchemaKeyspace.java:279) 
~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1271)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1253)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.service.MigrationTask$1.response(MigrationTask.java:92) 
~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:53)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
~[apache-cassandra-3.7.jar:3.7]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_51]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12364) dtest failure in upgrade_tests.paging_test.TestPagingDatasetChangesNodes3RF3_Upgrade_current_3_x_To_indev_3_x.test_cell_TTL_expiry_during_paging

2016-08-02 Thread Sean McCarthy (JIRA)


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

Sean McCarthy updated CASSANDRA-12364:
--
Description: 
example failure:

http://cassci.datastax.com/job/trunk_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_Upgrade_current_3_x_To_indev_3_x/test_cell_TTL_expiry_during_paging

{code}
Error Message

Unexpected error in log, see stdout
{code}

{code}
Standard Output

http://git-wip-us.apache.org/repos/asf/cassandra.git 
git:5051c0f6eb3f984600600c9577d6b5ece9038c74
Unexpected error in node1 log, error: 
ERROR [InternalResponseStage:4] 2016-07-28 03:23:02,097 
CassandraDaemon.java:217 - Exception in thread 
Thread[InternalResponseStage:4,5,main]
java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut 
down
at 
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
 ~[apache-cassandra-3.7.jar:3.7]
at 
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) 
~[na:1.8.0_51]
at 
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.ColumnFamilyStore.waitForFlushes(ColumnFamilyStore.java:930)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.ColumnFamilyStore.forceFlush(ColumnFamilyStore.java:892)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.lambda$flush$1(SchemaKeyspace.java:279)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace$$Lambda$200/2113926365.accept(Unknown
 Source) ~[na:na]
at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_51]
at 
org.apache.cassandra.schema.SchemaKeyspace.flush(SchemaKeyspace.java:279) 
~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1271)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1253)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.service.MigrationTask$1.response(MigrationTask.java:92) 
~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:53)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
~[apache-cassandra-3.7.jar:3.7]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_51]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
{code}

Related failures:
http://cassci.datastax.com/job/trunk_dtest_upgrade/11/testReport/upgrade_tests.paging_test/TestPagingWithDeletionsNodes3RF3_Upgrade_current_3_x_To_indev_3_x/test_ttl_deletions/

  was:
example failure:

http://cassci.datastax.com/job/trunk_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_Upgrade_current_3_x_To_indev_3_x/test_cell_TTL_expiry_during_paging

{code}
Error Message

Unexpected error in log, see stdout
{code}

{code}
Standard Output

http://git-wip-us.apache.org/repos/asf/cassandra.git 
git:5051c0f6eb3f984600600c9577d6b5ece9038c74
Unexpected error in node1 log, error: 
ERROR [InternalResponseStage:4] 2016-07-28 03:23:02,097 
CassandraDaemon.java:217 - Exception in thread 
Thread[InternalResponseStage:4,5,main]
java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut 
down
at 
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
 ~[apache-cassandra-3.7.jar:3.7]
at 
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) 
~[na:1.8.0_51]
at 
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.ColumnFamilyStore.waitForFlushes(ColumnFamilyStore.java:930)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.ColumnFamilyStore.forceFlush(ColumnFamilyStore.java:892)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.lambda$flush$1(SchemaKeyspace.java:279)
 ~[apache-cassandra-3.7.jar:3.7]

[jira] [Updated] (CASSANDRA-12364) dtest failure in upgrade_tests.paging_test.TestPagingDatasetChangesNodes3RF3_Upgrade_current_3_x_To_indev_3_x.test_cell_TTL_expiry_during_paging

2016-08-02 Thread Sean McCarthy (JIRA)


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

Sean McCarthy updated CASSANDRA-12364:
--
Description: 
example failure:

http://cassci.datastax.com/job/trunk_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_Upgrade_current_3_x_To_indev_3_x/test_cell_TTL_expiry_during_paging

{code}
Error Message

Unexpected error in log, see stdout
{code}

{code}
Standard Output

http://git-wip-us.apache.org/repos/asf/cassandra.git 
git:5051c0f6eb3f984600600c9577d6b5ece9038c74
Unexpected error in node1 log, error: 
ERROR [InternalResponseStage:4] 2016-07-28 03:23:02,097 
CassandraDaemon.java:217 - Exception in thread 
Thread[InternalResponseStage:4,5,main]
java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut 
down
at 
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
 ~[apache-cassandra-3.7.jar:3.7]
at 
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) 
~[na:1.8.0_51]
at 
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.ColumnFamilyStore.waitForFlushes(ColumnFamilyStore.java:930)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.ColumnFamilyStore.forceFlush(ColumnFamilyStore.java:892)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.lambda$flush$1(SchemaKeyspace.java:279)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace$$Lambda$200/2113926365.accept(Unknown
 Source) ~[na:na]
at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_51]
at 
org.apache.cassandra.schema.SchemaKeyspace.flush(SchemaKeyspace.java:279) 
~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1271)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1253)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.service.MigrationTask$1.response(MigrationTask.java:92) 
~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:53)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
~[apache-cassandra-3.7.jar:3.7]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_51]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
{code}

Related failures:
http://cassci.datastax.com/job/trunk_dtest_upgrade/11/testReport/upgrade_tests.paging_test/TestPagingWithDeletionsNodes3RF3_Upgrade_current_3_x_To_indev_3_x/test_ttl_deletions/
http://cassci.datastax.com/job/trunk_dtest_upgrade/12/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x/static_columns_with_distinct_test/

  was:
example failure:

http://cassci.datastax.com/job/trunk_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_Upgrade_current_3_x_To_indev_3_x/test_cell_TTL_expiry_during_paging

{code}
Error Message

Unexpected error in log, see stdout
{code}

{code}
Standard Output

http://git-wip-us.apache.org/repos/asf/cassandra.git 
git:5051c0f6eb3f984600600c9577d6b5ece9038c74
Unexpected error in node1 log, error: 
ERROR [InternalResponseStage:4] 2016-07-28 03:23:02,097 
CassandraDaemon.java:217 - Exception in thread 
Thread[InternalResponseStage:4,5,main]
java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut 
down
at 
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
 ~[apache-cassandra-3.7.jar:3.7]
at 
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) 
~[na:1.8.0_51]
at 
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.ColumnFamilyStore.waitForFlushes(ColumnFamilyStore.java:930)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.ColumnFamilyStore.forceFlush(ColumnFamilySt

[jira] [Updated] (CASSANDRA-12364) dtest failure in upgrade_tests.paging_test.TestPagingDatasetChangesNodes3RF3_Upgrade_current_3_x_To_indev_3_x.test_cell_TTL_expiry_during_paging

2016-08-02 Thread Sean McCarthy (JIRA)


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

Sean McCarthy updated CASSANDRA-12364:
--
Description: 
example failure:

http://cassci.datastax.com/job/trunk_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_Upgrade_current_3_x_To_indev_3_x/test_cell_TTL_expiry_during_paging

{code}
Error Message

Unexpected error in log, see stdout
{code}

{code}
Standard Output

http://git-wip-us.apache.org/repos/asf/cassandra.git 
git:5051c0f6eb3f984600600c9577d6b5ece9038c74
Unexpected error in node1 log, error: 
ERROR [InternalResponseStage:4] 2016-07-28 03:23:02,097 
CassandraDaemon.java:217 - Exception in thread 
Thread[InternalResponseStage:4,5,main]
java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut 
down
at 
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
 ~[apache-cassandra-3.7.jar:3.7]
at 
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) 
~[na:1.8.0_51]
at 
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.ColumnFamilyStore.waitForFlushes(ColumnFamilyStore.java:930)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.ColumnFamilyStore.forceFlush(ColumnFamilyStore.java:892)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.lambda$flush$1(SchemaKeyspace.java:279)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace$$Lambda$200/2113926365.accept(Unknown
 Source) ~[na:na]
at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_51]
at 
org.apache.cassandra.schema.SchemaKeyspace.flush(SchemaKeyspace.java:279) 
~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1271)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1253)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.service.MigrationTask$1.response(MigrationTask.java:92) 
~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:53)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
~[apache-cassandra-3.7.jar:3.7]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_51]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
{code}

Related failures:
http://cassci.datastax.com/job/trunk_dtest_upgrade/11/testReport/upgrade_tests.paging_test/TestPagingWithDeletionsNodes3RF3_Upgrade_current_3_x_To_indev_3_x/test_ttl_deletions/
http://cassci.datastax.com/job/trunk_dtest_upgrade/12/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x/static_columns_with_distinct_test/
http://cassci.datastax.com/job/trunk_dtest_upgrade/12/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x/refuse_in_with_indexes_test/

  was:
example failure:

http://cassci.datastax.com/job/trunk_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_Upgrade_current_3_x_To_indev_3_x/test_cell_TTL_expiry_during_paging

{code}
Error Message

Unexpected error in log, see stdout
{code}

{code}
Standard Output

http://git-wip-us.apache.org/repos/asf/cassandra.git 
git:5051c0f6eb3f984600600c9577d6b5ece9038c74
Unexpected error in node1 log, error: 
ERROR [InternalResponseStage:4] 2016-07-28 03:23:02,097 
CassandraDaemon.java:217 - Exception in thread 
Thread[InternalResponseStage:4,5,main]
java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut 
down
at 
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
 ~[apache-cassandra-3.7.jar:3.7]
at 
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) 
~[na:1.8.0_51]
at 
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.Colum

[jira] [Updated] (CASSANDRA-12361) dtest failure in cql_tests.MiscellaneousCQLTester.prepared_statement_invalidation_test

2016-08-02 Thread Sean McCarthy (JIRA)


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

Sean McCarthy updated CASSANDRA-12361:
--
Description: 
example failure:

http://cassci.datastax.com/job/cassandra-2.1_dtest/497/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test

{code}
Stacktrace

  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
  File "/home/automaton/cassandra-dtest/cql_tests.py", line 481, in 
prepared_statement_invalidation_test
result = session.execute(wildcard_prepared.bind(None))
  File "cassandra/cluster.py", line 1961, in cassandra.cluster.Session.execute 
(cassandra/cluster.c:34076)
return self.execute_async(query, parameters, trace, custom_payload, 
timeout, execution_profile).result()
  File "cassandra/cluster.py", line 3649, in 
cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69755)
raise self._final_exception
"Cannot read past the end of the file
{code}

Related failures:
http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/250/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/
http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/270/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/
http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/380/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/
http://cassci.datastax.com/job/cassandra-3.9_novnode_dtest/25/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/

  was:
example failure:

http://cassci.datastax.com/job/cassandra-2.1_dtest/497/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test

{code}
Stacktrace

  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
  File "/home/automaton/cassandra-dtest/cql_tests.py", line 481, in 
prepared_statement_invalidation_test
result = session.execute(wildcard_prepared.bind(None))
  File "cassandra/cluster.py", line 1961, in cassandra.cluster.Session.execute 
(cassandra/cluster.c:34076)
return self.execute_async(query, parameters, trace, custom_payload, 
timeout, execution_profile).result()
  File "cassandra/cluster.py", line 3649, in 
cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69755)
raise self._final_exception
"Cannot read past the end of the file
{code}

Related failures:
http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/250/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/
http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/270/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/
http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/380/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/


> dtest failure in 
> cql_tests.MiscellaneousCQLTester.prepared_statement_invalidation_test
> --
>
> Key: CASSANDRA-12361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12361
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: DS Test Eng
>  Labels: dtest
> Attachments: node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/497/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/cql_tests.py", line 481, in 
> prepared_statement_invalidation_test
> result = session.execute(wildcard_prepared.bind(None))
>   File "cassandra/cluster.py", line 1961, in 
> cassandra.cluster.Session.execute (cassandra/cluster.c:34076)
> return self.execute_async(query, parameters, trace, custom_payload, 
> timeout, execution_profile).result()
>   File "cassandra/cluster.py", line 3649, in 
> cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69755)
> raise self._final_exception
> "Cannot read past the end of the file
> {code}
> Related failures:
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/250/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/
> http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/270/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/
> http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/380/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/
> http://cassci.datastax.com/job/cassandra-3.9_novnode_dtest/25/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12264) dtest failure in repair_tests.incremental_repair_test.TestIncRepair.sstable_marking_test

2016-08-02 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson updated CASSANDRA-12264:

Status: Patch Available  (was: Open)

happens because node3 (which we are repairing) has not yet learned about 
keyspace1.standard1

Patch [here|https://github.com/krummas/cassandra-dtest/commits/marcuse/12264] 
to wait until the schema has propagated

> dtest failure in 
> repair_tests.incremental_repair_test.TestIncRepair.sstable_marking_test
> 
>
> Key: CASSANDRA-12264
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12264
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Marcus Eriksson
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.9_dtest/15/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_marking_test
> {code}
> Error Message
> 'Repaired at: 0' unexpectedly found in 'SSTable: 
> {code}
> Related failure:
> http://cassci.datastax.com/job/trunk_dtest/1315/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_marking_test/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10848) Upgrade paging dtests involving deletion flap on CassCI

2016-08-02 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-10848:
--

As the test we're talking about here are paging tests, one thing that could be 
worth a double check is CASSANDRA-10880. That is, we should make sure that 
during upgrades from 2.X to 3.0.x, we make sure the native protocol version is 
fixed to version 3 (we should not be using version 4 *even* when talking to 3.0 
nodes, and this until the upgrade is over). If it's not guaranteed by the 
tests, bad things will happen, including server side error that would break 
query and get the {{Requested pages were not delivered before timeout}} error 
above.

I'm mentioning that because I ran into this with another test today, so it 
seems that by default the python driver will try to connect with the max 
possible version to each node. I'm not familiar enough with the upgrade test 
code enough to say if it fixes the protocol version or not, but if it doesn't, 
it should.

> Upgrade paging dtests involving deletion flap on CassCI
> ---
>
> Key: CASSANDRA-10848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10848
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: DS Test Eng
>  Labels: dtest
> Fix For: 3.0.x, 3.x
>
>
> A number of dtests in the {{upgrade_tests.paging_tests}} that involve 
> deletion flap with the following error:
> {code}
> Requested pages were not delivered before timeout.
> {code}
> This may just be an effect of CASSANDRA-10730, but it's worth having a look 
> at separately. Here are some examples of tests flapping in this way:



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[1/3] cassandra git commit: Revert CASSANDRA-11427 because of CASSANDRA-12351 (CASSANDRA-12143).

2016-08-02 Thread slebresne

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 25159c388 -> f28631e0c
  refs/heads/cassandra-3.0 c6cb31e5f -> 5acfce666


Revert CASSANDRA-11427 because of CASSANDRA-12351 (CASSANDRA-12143).


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

Branch: refs/heads/cassandra-2.2
Commit: f28631e0cf1bc6cb6a1bdf7a4fa1f4af720a77b6
Parents: 25159c3
Author: Sylvain Lebresne 
Authored: Tue Aug 2 15:53:19 2016 +0200
Committer: Sylvain Lebresne 
Committed: Tue Aug 2 15:53:19 2016 +0200

--
 CHANGES.txt | 1 +
 src/java/org/apache/cassandra/db/ColumnFamilyStore.java | 4 
 2 files changed, 1 insertion(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f28631e0/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index c18bad7..6f709f7 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.8
+ * Revert CASSANDRA-11427 (CASSANDRA-12351)
  * Wait for tracing events before returning response and query at same 
consistency level client side (CASSANDRA-11465)
  * cqlsh copyutil should get host metadata by connected address 
(CASSANDRA-11979)
  * Fixed cqlshlib.test.remove_test_db (CASSANDRA-12214)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f28631e0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java 
b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index ff63163..d0cb200 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@ -2346,10 +2346,6 @@ public class ColumnFamilyStore implements 
ColumnFamilyStoreMBean
 removeDroppedColumns(data);
 }
 
-// remove purgable tombstones from result - see CASSANDRA-11427
-if (data != null)
-data.purgeTombstones(gcBefore(filter.timestamp));
-
 rows.add(new Row(rawRow.key, data));
 if (!ignoreTombstonedPartitions || 
!data.hasOnlyTombstones(filter.timestamp))
 matched++;

[3/3] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

2016-08-02 Thread slebresne

Merge branch 'cassandra-2.2' into cassandra-3.0

* cassandra-2.2:
  Revert CASSANDRA-11427 because of CASSANDRA-12351 (CASSANDRA-12143).


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

Branch: refs/heads/cassandra-3.0
Commit: 5acfce66601c76cc280e2a05562415948bd3a538
Parents: c6cb31e f28631e
Author: Sylvain Lebresne 
Authored: Tue Aug 2 15:54:55 2016 +0200
Committer: Sylvain Lebresne 
Committed: Tue Aug 2 15:54:55 2016 +0200

--

--

[2/3] cassandra git commit: Revert CASSANDRA-11427 because of CASSANDRA-12351 (CASSANDRA-12143).

2016-08-02 Thread slebresne

Revert CASSANDRA-11427 because of CASSANDRA-12351 (CASSANDRA-12143).


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

Branch: refs/heads/cassandra-3.0
Commit: f28631e0cf1bc6cb6a1bdf7a4fa1f4af720a77b6
Parents: 25159c3
Author: Sylvain Lebresne 
Authored: Tue Aug 2 15:53:19 2016 +0200
Committer: Sylvain Lebresne 
Committed: Tue Aug 2 15:53:19 2016 +0200

--
 CHANGES.txt | 1 +
 src/java/org/apache/cassandra/db/ColumnFamilyStore.java | 4 
 2 files changed, 1 insertion(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f28631e0/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index c18bad7..6f709f7 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.8
+ * Revert CASSANDRA-11427 (CASSANDRA-12351)
  * Wait for tracing events before returning response and query at same 
consistency level client side (CASSANDRA-11465)
  * cqlsh copyutil should get host metadata by connected address 
(CASSANDRA-11979)
  * Fixed cqlshlib.test.remove_test_db (CASSANDRA-12214)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f28631e0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java 
b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index ff63163..d0cb200 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@ -2346,10 +2346,6 @@ public class ColumnFamilyStore implements 
ColumnFamilyStoreMBean
 removeDroppedColumns(data);
 }
 
-// remove purgable tombstones from result - see CASSANDRA-11427
-if (data != null)
-data.purgeTombstones(gcBefore(filter.timestamp));
-
 rows.add(new Row(rawRow.key, data));
 if (!ignoreTombstonedPartitions || 
!data.hasOnlyTombstones(filter.timestamp))
 matched++;

[jira] [Commented] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-12351:
--

Thanks for the analysis and patch, but 2 bugs due to CASSANDRA-11427, which is 
minor in the first place, is way above my comfort level so reverted the whole 
patch in commit f28631e0cf1bc6cb6a1bdf7a4fa1f4af720a77b6. I'd be happy if you 
can confirm this fix your reproduction steps, but closing due to the revert in 
the meantime.

> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: mck
> Attachments: 12351-2.2.txt
>
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522)
>  [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
> {{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning 
> more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not 
> in 2.2.6.
> This issue was raised on the mailing list 
> [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces

2016-08-02 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne resolved CASSANDRA-12351.
--
   Resolution: Fixed
 Assignee: Sylvain Lebresne  (was: mck)
Fix Version/s: 2.2.8

> IllegalStateException: empty rows returned when reading 
> system.schema_keyspaces
> ---
>
> Key: CASSANDRA-12351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: mck
>Assignee: Sylvain Lebresne
> Fix For: 2.2.8
>
> Attachments: 12351-2.2.txt
>
>
> After 2.2.6 the following error is thrown during startup, resulting in 
> Cassandra not starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
>  ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) 
> ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522)
>  [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) 
> [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to 
> {{getSchemaPartitionsForTable(KEYSPACES)}} is now (since 2.2.6) returning 
> more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not 
> in 2.2.6.
> This issue was raised on the mailing list 
> [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3c776766150.5940472.1469733214785.javamail.ya...@mail.yahoo.com%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11828) Commit log needs to track unflushed intervals rather than positions

2016-08-02 Thread Branimir Lambov (JIRA)


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

Branimir Lambov commented on CASSANDRA-11828:
-

Thank you for the thorough review and the good suggestions. Applied them as a 
new commit in the 3.0 version:
|[3.0|https://github.com/blambov/cassandra/tree/11828-revert-compaction-wait-3.0]|[utest|http://cassci.datastax.com/job/blambov-11828-revert-compaction-wait-3.0-testall/]|[dtest|http://cassci.datastax.com/job/blambov-11828-revert-compaction-wait-3.0-dtest/]|
except removing the synchronization from {{IntegerIterval.Set.add}} as the 
individual interval class is thread-safe and hence the consistency is better if 
the set class also is (also, this is a longer-running operation so 
synchronization is preferable to compare-and-set). Additionally untied 
{{IntervalSet}} from {{ReplayPosition}} and did a couple of smaller cleanups. 
Please take another look.

On the topic of where it should be applied, I agree it is a better idea to 
leave it out of 2.x. I wouldn't completely revert CASSANDRA-11448 -- it is 
still preferable to die/stop the transports on error, but we shouldn't be 
passing control on to the post-flush. I will prepare a patch that does this 
next.

> Commit log needs to track unflushed intervals rather than positions
> ---
>
> Key: CASSANDRA-11828
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11828
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> In CASSANDRA-11448 in an effort to give a more thorough handling of flush 
> errors I have introduced a possible correctness bug with disk failure policy 
> ignore if a flush fails with an error:
> - we report the error but continue
> - we correctly do not update the commit log with the flush position
> - but we allow the post-flush executor to resume
> - a successful later flush can thus move the log's clear position beyond the 
> data from the failed flush
> - the log will then delete segment(s) that contain unflushed data.
> After CASSANDRA-9669 it is relatively easy to fix this problem by making the 
> commit log track sets of intervals of unflushed data (as described in 
> CASSANDRA-8496).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11828) Commit log needs to track unflushed intervals rather than positions

2016-08-02 Thread Branimir Lambov (JIRA)


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

Branimir Lambov updated CASSANDRA-11828:

Status: Patch Available  (was: Awaiting Feedback)

> Commit log needs to track unflushed intervals rather than positions
> ---
>
> Key: CASSANDRA-11828
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11828
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> In CASSANDRA-11448 in an effort to give a more thorough handling of flush 
> errors I have introduced a possible correctness bug with disk failure policy 
> ignore if a flush fails with an error:
> - we report the error but continue
> - we correctly do not update the commit log with the flush position
> - but we allow the post-flush executor to resume
> - a successful later flush can thus move the log's clear position beyond the 
> data from the failed flush
> - the log will then delete segment(s) that contain unflushed data.
> After CASSANDRA-9669 it is relatively easy to fix this problem by making the 
> commit log track sets of intervals of unflushed data (as described in 
> CASSANDRA-8496).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11126) select_distinct_with_deletions_test failing on non-vnode environments

2016-08-02 Thread Jim Witschey (JIRA)


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

Jim Witschey commented on CASSANDRA-11126:
--

Note that the commands I provided end with the names of the tests to run:

{code}
... 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_2_x_To_indev_3_0_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_2_x_To_indev_3_x.select_distinct_with_deletions_test
{code}

Those classes (e.g. {{TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x}}) 
are generated at runtime. {{TestCQL}} is a base class that is not configured to 
run. I'll file a PR to improve error reporting in this case.

> select_distinct_with_deletions_test failing on non-vnode environments
> -
>
> Key: CASSANDRA-11126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11126
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
>  Labels: dtest
> Fix For: 3.0.x
>
>
> Looks like this was fixed in CASSANDRA-10762, but not for non-vnode 
> environments:
> {code}
> $ DISABLE_VNODES=yes KEEP_TEST_DIR=yes CASSANDRA_VERSION=git:cassandra-3.0 
> PRINT_DEBUG=true nosetests -s -v 
> upgrade_tests/cql_tests.py:TestCQLNodes2RF1.select_distinct_with_deletions_test
> select_distinct_with_deletions_test 
> (upgrade_tests.cql_tests.TestCQLNodes2RF1) ... cluster ccm directory: 
> /tmp/dtest-UXb0un
> http://git-wip-us.apache.org/repos/asf/cassandra.git git:cassandra-3.0
> Custom init_config not found. Setting defaults.
> Done setting configuration options:
> {   'num_tokens': None,
> 'phi_convict_threshold': 5,
> 'range_request_timeout_in_ms': 1,
> 'read_request_timeout_in_ms': 1,
> 'request_timeout_in_ms': 1,
> 'truncate_request_timeout_in_ms': 1,
> 'write_request_timeout_in_ms': 1}
> getting default job version for 3.0.3
> UpgradePath(starting_version='binary:2.2.3', upgrade_version=None)
> starting from 2.2.3
> upgrading to {'install_dir': 
> '/home/ryan/.ccm/repository/gitCOLONcassandra-3.0'}
> Querying upgraded node
> FAIL
> ==
> FAIL: select_distinct_with_deletions_test 
> (upgrade_tests.cql_tests.TestCQLNodes2RF1)
> --
> Traceback (most recent call last):
>   File "/home/ryan/git/datastax/cassandra-dtest/upgrade_tests/cql_tests.py", 
> line 3360, in select_distinct_with_deletions_test
> self.assertEqual(9, len(rows))
> AssertionError: 9 != 8
>  >> begin captured logging << 
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-UXb0un
> dtest: DEBUG: Custom init_config not found. Setting defaults.
> dtest: DEBUG: Done setting configuration options:
> {   'num_tokens': None,
> 'phi_convict_threshold': 5,
> 'range_request_timeout_in_ms': 1,
> 'read_request_timeout_in_ms': 1,
> 'request_timeout_in_ms': 1,
> 'truncate_request_timeout_in_ms': 1,
> 'write_request_timeout_in_ms': 1}
> dtest: DEBUG: getting default job version for 3.0.3
> dtest: DEBUG: UpgradePath(starting_version='binary:2.2.3', 
> upgrade_version=None)
> dtest: DEBUG: starting from 2.2.3
> dtest: DEBUG: upgrading to {'install_dir': 
> '/home/ryan/.ccm/repository/gitCOLONcassandra-3.0'}
> dtest: DEBUG: Querying upgraded node
> - >> end captured logging << -
> --
> Ran 1 test in 56.022s
> FAILED (failures=1)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10707) Add support for Group By to Select statement

2016-08-02 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-10707:
--

Last version mostly look good. The main thing I still don't like is the 
{{filterOnReplica}} method: I feel it's easy to misuse and doesn't feel 
particulary natural. Thinking about this, I feel the underlying issue we're 
trying to solve is more general: the {{DataLimits}} holds state (for paging and 
grouping) which somewhat assumes things are queried sequentially (and in 
order). However, when we do range queries and send queries in parallel to 
nodes, that's not true anymore (except maybe for the first range sent), at 
least not for the queries sent to replica (we still process them in order on 
the coordinator). So anyway, I think a better way to handle this is to 
acknowledge that fact in {{StorageProxy.getRangeSlice}} and drop any state from 
the sub-range commands sent in parallel. I've tried such change in the branch 
attached below (which is also rebased).

The branch also include a commit with a few nits, mostly around comments. Feel 
free to ignore some of it if you don't like it.

| [10707-trunk|https://github.com/pcmanus/cassandra/commits/10707-trunk] | 
[utests|http://cassci.datastax.com/job/pcmanus-10707-trunk-testall] | 
[dtests|http://cassci.datastax.com/job/pcmanus-10707-trunk-dtest] |

I'll note that the dtest run has failures, but this is a ongoing problem with 
CI today. Random tests fail with {{Host has been marked down or removed}} but 
you get that on today trunk run as well: 
http://cassci.datastax.com/view/trunk/job/trunk_dtest/1322/

Anyway, if we can agree on those 2 small commits, then I'm +1 (though we might 
want to wait on CI to stabilize on dtests to make sure).

> Add support for Group By to Select statement
> 
>
> Key: CASSANDRA-10707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10707
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 3.x
>
>
> Now that Cassandra support aggregate functions, it makes sense to support 
> {{GROUP BY}} on the {{SELECT}} statements.
> It should be possible to group either at the partition level or at the 
> clustering column level.
> {code}
> SELECT partitionKey, max(value) FROM myTable GROUP BY partitionKey;
> SELECT partitionKey, clustering0, clustering1, max(value) FROM myTable GROUP 
> BY partitionKey, clustering0, clustering1; 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12236) RTE from new CDC column breaks in flight queries.

2016-08-02 Thread Aleksey Yeschenko (JIRA)


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

Aleksey Yeschenko updated CASSANDRA-12236:
--
Fix Version/s: (was: 3.x)
   3.9
   3.8

> RTE from new CDC column breaks in flight queries.
> -
>
> Key: CASSANDRA-12236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12236
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Sylvain Lebresne
> Fix For: 3.8, 3.9
>
> Attachments: 12236.txt
>
>
> This RTE is not harmless. It will cause the internode connection to break 
> which will cause all in flight requests between these nodes to die/timeout.
> {noformat}
> - Due to changes in schema migration handling and the storage format 
> after 3.0, you will
>   see error messages such as:
>  "java.lang.RuntimeException: Unknown column cdc during 
> deserialization"
>   in your system logs on a mixed-version cluster during upgrades. This 
> error message
>   is harmless and due to the 3.8 nodes having cdc added to their schema 
> tables while
>   the <3.8 nodes do not. This message should cease once all nodes are 
> upgraded to 3.8.
>   As always, refrain from schema changes during cluster upgrades.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12127) Queries with empty ByteBuffer values in clustering column restrictions fail for non-composite compact tables

2016-08-02 Thread Benjamin Lerer (JIRA)


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

Benjamin Lerer commented on CASSANDRA-12127:


I will try to make {{scrub}} able to correct that type of problems. 

> Queries with empty ByteBuffer values in clustering column restrictions fail 
> for non-composite compact tables
> 
>
> Key: CASSANDRA-12127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12127
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
> Attachments: 12127.txt
>
>
> For the following table:
> {code}
> CREATE TABLE myTable (pk int,
>   c blob,
>   value int,
>   PRIMARY KEY (pk, c)) WITH COMPACT STORAGE;
> INSERT INTO myTable (pk, c, value) VALUES (1, textAsBlob('1'), 1);
> INSERT INTO myTable (pk, c, value) VALUES (1, textAsBlob('2'), 2);
> {code}
> The query: {{SELECT * FROM myTable WHERE pk = 1 AND c > textAsBlob('');}}
> Will result in the following Exception:
> {code}
> java.lang.ClassCastException: 
> org.apache.cassandra.db.composites.Composites$EmptyComposite cannot be cast 
> to org.apache.cassandra.db.composites.CellName
>   at 
> org.apache.cassandra.db.composites.AbstractCellNameType.cellFromByteBuffer(AbstractCellNameType.java:188)
>   at 
> org.apache.cassandra.db.composites.AbstractSimpleCellNameType.makeCellName(AbstractSimpleCellNameType.java:125)
>   at 
> org.apache.cassandra.db.composites.AbstractCellNameType.makeCellName(AbstractCellNameType.java:254)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.makeExclusiveSliceBound(SelectStatement.java:1206)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.applySliceRestriction(SelectStatement.java:1214)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1292)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1259)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:299)
>   [...]
> {code}
> The query: {{SELECT * FROM myTable WHERE pk = 1 AND c < textAsBlob('');}}
> Will return 2 rows instead of 0.
> The query: {{SELECT * FROM myTable WHERE pk = 1 AND c = textAsBlob('');}}
> {code}
> java.lang.AssertionError
>   at 
> org.apache.cassandra.db.composites.SimpleDenseCellNameType.create(SimpleDenseCellNameType.java:60)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.addSelectedColumns(SelectStatement.java:853)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.getRequestedColumns(SelectStatement.java:846)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.makeFilter(SelectStatement.java:583)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:383)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.getPageableCommand(SelectStatement.java:253)
>   [...]
> {code}
> I checked 2.0 and {{SELECT * FROM myTable  WHERE pk = 1 AND c > 
> textAsBlob('');}} works properly but {{SELECT * FROM myTable WHERE pk = 1 AND 
> c < textAsBlob('');}} return the same wrong results than in 2.1.
> The {{SELECT * FROM myTable WHERE pk = 1 AND c = textAsBlob('');}} is 
> rejected if a clear error message: {{Invalid empty value for clustering 
> column of COMPACT TABLE}}.
> As it is not possible to insert an empty ByteBuffer value within the 
> clustering column of a non-composite compact tables those queries do not
> have a lot of meaning. {{SELECT * FROM myTable WHERE pk = 1 AND c < 
> textAsBlob('');}} and {{SELECT * FROM myTable WHERE pk = 1 AND c = 
> textAsBlob('');}} will return nothing
> and {{SELECT * FROM myTable WHERE pk = 1 AND c > textAsBlob('');}} will 
> return the entire partition (pk = 1).
> In my opinion those queries should probably all be rejected as it seems that 
> the fact that {{SELECT * FROM myTable  WHERE pk = 1 AND c > textAsBlob('');}} 
> was accepted in {{2.0}} was due to a bug.
> I am of course open to discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11914) Provide option for cassandra-stress to dump all settings

2016-08-02 Thread T Jake Luciani (JIRA)


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

T Jake Luciani commented on CASSANDRA-11914:


I think (a) is fine since you run the command after the report anyway.

I also think this should be on by default since it provides a lot of value.  

One other thing I noticed is for the java driver it doesn't print all the 
options like the max connections per host which is also important.

> Provide option for cassandra-stress to dump all settings
> 
>
> Key: CASSANDRA-11914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11914
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Ben Slater
>Assignee: Ben Slater
>Priority: Minor
> Fix For: 3.x
>
>
> cassandra-stress has quite a lot of default settings and settings that are 
> derived as side effects of explicit options. For people learning the tool and 
> saving a clear record of what was run, I think it would be useful if there 
> was an option to have the tool print all its settings at the start of a run.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12228) Write performance regression in 3.x vs 3.0

2016-08-02 Thread T Jake Luciani (JIRA)


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

T Jake Luciani commented on CASSANDRA-12228:


I'm good with that, I'll wait to see what [~krummas] thinks

> Write performance regression in 3.x vs 3.0
> --
>
> Key: CASSANDRA-12228
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12228
> Project: Cassandra
>  Issue Type: Bug
>Reporter: T Jake Luciani
>Assignee: Ariel Weisberg
>Priority: Minor
> Fix For: 3.9
>
>
> I've been tracking down a performance issue in trunk vs cassandra-3.0 branch.
> I think I've found it.  CASSANDRA-6696 changed the default memtable flush 
> default to 1 vs the min of 2 in cassandra-3.0.
> I don't see any technical reason for this and we should add back the min of 2 
> sstable flushers per disk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12228) Write performance regression in 3.x vs 3.0

2016-08-02 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson updated CASSANDRA-12228:

Reviewer: Marcus Eriksson

> Write performance regression in 3.x vs 3.0
> --
>
> Key: CASSANDRA-12228
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12228
> Project: Cassandra
>  Issue Type: Bug
>Reporter: T Jake Luciani
>Assignee: Ariel Weisberg
>Priority: Minor
> Fix For: 3.9
>
>
> I've been tracking down a performance issue in trunk vs cassandra-3.0 branch.
> I think I've found it.  CASSANDRA-6696 changed the default memtable flush 
> default to 1 vs the min of 2 in cassandra-3.0.
> I don't see any technical reason for this and we should add back the min of 2 
> sstable flushers per disk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-7190) Add schema to snapshot manifest

2016-08-02 Thread Aleksey Yeschenko (JIRA)


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

Aleksey Yeschenko commented on CASSANDRA-7190:
--

[~kohlisankalp] We are generally only contributing fixes to 3.0.x now. That 
said, you could view the original issue - CASSANDRA-11416 - as a 
8099-regression, and in absence of another way to ignore unknown columns on 
restore, treat this is a bug fix and commit to 3.0. It's also a really low-risk 
change that doesn't modify almost any of the existing code.

We've had this conversation with Jeremiah. So, no, it's not too late. I'll 
backport unless there is strong disagreement from somebody.

> Add schema to snapshot manifest
> ---
>
> Key: CASSANDRA-7190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Jonathan Ellis
>Assignee: Alex Petrov
>Priority: Minor
>  Labels: client-impacting, doc-impacting, lhf
> Fix For: 3.10
>
>
> followup from CASSANDRA-6326



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12228) Write performance regression in 3.x vs 3.0

2016-08-02 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson commented on CASSANDRA-12228:
-

Since 6696 the configuration sets how many flush writers there should be *per 
data directory* - so factoring in the number of data directories in the 
calculation is probably wrong (ie, with 10 data directories and 2 memtable 
flush writers you would get 20 threads actually doing writing to disk and 2 
threads waiting on the writing, meaning we can flush 2 memtables concurrently)



> Write performance regression in 3.x vs 3.0
> --
>
> Key: CASSANDRA-12228
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12228
> Project: Cassandra
>  Issue Type: Bug
>Reporter: T Jake Luciani
>Assignee: Ariel Weisberg
>Priority: Minor
> Fix For: 3.9
>
>
> I've been tracking down a performance issue in trunk vs cassandra-3.0 branch.
> I think I've found it.  CASSANDRA-6696 changed the default memtable flush 
> default to 1 vs the min of 2 in cassandra-3.0.
> I don't see any technical reason for this and we should add back the min of 2 
> sstable flushers per disk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12236) RTE from new CDC column breaks in flight queries.

2016-08-02 Thread Aleksey Yeschenko (JIRA)


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

Aleksey Yeschenko commented on CASSANDRA-12236:
---

Alright.

Two issues:
1. {{SimpleBuilders#AbstractBuilder#nowInSec() method has an invalid argument 
({{int ttl}} instead of {{int nowInSec}}), making the method a no-op
2. SimpleBuilders#RowBuilder#add() in the {{SET}} case in the for loop is using 
the incorrect variable in {{toByteBuffer()}} call ({{value}} instead of {{elt}})

One nit: the change in MigrationManager is contaminating git blame, no need for 
it

One subjective preference: not a fan of {{addNoOverride()}} name. Maybe just 
replace with {{append()}}?

Otherwise LGTM conditional on tests passing.

> RTE from new CDC column breaks in flight queries.
> -
>
> Key: CASSANDRA-12236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12236
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Sylvain Lebresne
> Fix For: 3.x
>
> Attachments: 12236.txt
>
>
> This RTE is not harmless. It will cause the internode connection to break 
> which will cause all in flight requests between these nodes to die/timeout.
> {noformat}
> - Due to changes in schema migration handling and the storage format 
> after 3.0, you will
>   see error messages such as:
>  "java.lang.RuntimeException: Unknown column cdc during 
> deserialization"
>   in your system logs on a mixed-version cluster during upgrades. This 
> error message
>   is harmless and due to the 3.8 nodes having cdc added to their schema 
> tables while
>   the <3.8 nodes do not. This message should cease once all nodes are 
> upgraded to 3.8.
>   As always, refrain from schema changes during cluster upgrades.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12228) Write performance regression in 3.x vs 3.0

2016-08-02 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson edited comment on CASSANDRA-12228 at 8/2/16 2:43 PM:
-

Since 6696 the configuration sets how many flush writers there should be *per 
data directory* - so factoring in the number of data directories in the 
calculation is probably wrong (ie, with 10 data directories and 2 memtable 
flush writers you would get 20 threads actually doing writing to disk and 2 
threads waiting on the writing, meaning we can flush 2 memtables concurrently)

edit: re-read your yaml comment where you explain exactly what I wrote above :) 
- but why would we want more threads per data directory if we have more data 
directories?


was (Author: krummas):
Since 6696 the configuration sets how many flush writers there should be *per 
data directory* - so factoring in the number of data directories in the 
calculation is probably wrong (ie, with 10 data directories and 2 memtable 
flush writers you would get 20 threads actually doing writing to disk and 2 
threads waiting on the writing, meaning we can flush 2 memtables concurrently)



> Write performance regression in 3.x vs 3.0
> --
>
> Key: CASSANDRA-12228
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12228
> Project: Cassandra
>  Issue Type: Bug
>Reporter: T Jake Luciani
>Assignee: Ariel Weisberg
>Priority: Minor
> Fix For: 3.9
>
>
> I've been tracking down a performance issue in trunk vs cassandra-3.0 branch.
> I think I've found it.  CASSANDRA-6696 changed the default memtable flush 
> default to 1 vs the min of 2 in cassandra-3.0.
> I don't see any technical reason for this and we should add back the min of 2 
> sstable flushers per disk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12140) dtest failure in materialized_views_test.TestMaterializedViews.add_write_survey_node_after_mv_test

2016-08-02 Thread Craig Kodman (JIRA)


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

Craig Kodman updated CASSANDRA-12140:
-
Description: 
example failure:

http://cassci.datastax.com/job/trunk_novnode_dtest/409/testReport/materialized_views_test/TestMaterializedViews/add_write_survey_node_after_mv_test

Failed on CassCI build trunk_novnode_dtest #409

{code}
Standard Output

Unexpected error in node4 log, error: 
ERROR [main] 2016-06-27 15:28:13,139 MigrationManager.java:164 - Migration task 
failed to complete
{code}

http://cassci.datastax.com/job/trunk_novnode_dtest/432/testReport/materialized_views_test/TestMaterializedViews/add_dc_after_mv_simple_replication_test/

  was:
example failure:

http://cassci.datastax.com/job/trunk_novnode_dtest/409/testReport/materialized_views_test/TestMaterializedViews/add_write_survey_node_after_mv_test

Failed on CassCI build trunk_novnode_dtest #409

{code}
Standard Output

Unexpected error in node4 log, error: 
ERROR [main] 2016-06-27 15:28:13,139 MigrationManager.java:164 - Migration task 
failed to complete
{code}


> dtest failure in 
> materialized_views_test.TestMaterializedViews.add_write_survey_node_after_mv_test
> --
>
> Key: CASSANDRA-12140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12140
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Carl Yeksigian
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log, 
> node4.log, node4_debug.log, node4_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/409/testReport/materialized_views_test/TestMaterializedViews/add_write_survey_node_after_mv_test
> Failed on CassCI build trunk_novnode_dtest #409
> {code}
> Standard Output
> Unexpected error in node4 log, error: 
> ERROR [main] 2016-06-27 15:28:13,139 MigrationManager.java:164 - Migration 
> task failed to complete
> {code}
> http://cassci.datastax.com/job/trunk_novnode_dtest/432/testReport/materialized_views_test/TestMaterializedViews/add_dc_after_mv_simple_replication_test/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12236) RTE from new CDC column breaks in flight queries.

2016-08-02 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-12236:
--

Pushed a commit with fix for those and re-started the tests. I did got a run of 
upgrade test to finish previously and there was still 72 failures. I start 
looking at the reports and it's not immediately clear than any of those is due 
to this issue, but at the same time the reports aren't full of details in many 
cases (if we have a node logs, I'm not aware of it). It could be worth noting 
there is an overwhelming number of paging tests fails, and it doesn't sound 
like paging tests would more sensible to this than other (I've hinted at some 
possible explanation for paging upgrade test failures on CASSANDRA-10848 but 
I'm not even sure of that), but I'm fishing a bit here.

In any case, I think we want to do this change as it was never intended to ship 
columns for which we had no values, but this is probably not the end of our 
upgrade test problems.

bq. One nit: the change in MigrationManager is contaminating git blame, no need 
for it

Not sure to follow that one. Even if the change wasn't pulling the 
{{Collections.singletonList()}} call out, which I happen to think is slightly 
cleaner (and thus prefer over {{git blame}} concerns), the code would still 
need to call the {{build()}} method so the pollution would be the same. I'm 
surely missing your point though.

> RTE from new CDC column breaks in flight queries.
> -
>
> Key: CASSANDRA-12236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12236
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Sylvain Lebresne
> Fix For: 3.8, 3.9
>
> Attachments: 12236.txt
>
>
> This RTE is not harmless. It will cause the internode connection to break 
> which will cause all in flight requests between these nodes to die/timeout.
> {noformat}
> - Due to changes in schema migration handling and the storage format 
> after 3.0, you will
>   see error messages such as:
>  "java.lang.RuntimeException: Unknown column cdc during 
> deserialization"
>   in your system logs on a mixed-version cluster during upgrades. This 
> error message
>   is harmless and due to the 3.8 nodes having cdc added to their schema 
> tables while
>   the <3.8 nodes do not. This message should cease once all nodes are 
> upgraded to 3.8.
>   As always, refrain from schema changes during cluster upgrades.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12236) RTE from new CDC column breaks in flight queries.

2016-08-02 Thread Aleksey Yeschenko (JIRA)


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

Aleksey Yeschenko commented on CASSANDRA-12236:
---

bq. Not sure to follow that one

My eyes failed me, never mind.

bq.  I did got a run of upgrade test to finish previously and there was still 
72 failures. 

Absolute most of them have been failing since before CDC AFAIK, not related to 
this ticket, and it will take a while to address them (likely not before 3.10).

> RTE from new CDC column breaks in flight queries.
> -
>
> Key: CASSANDRA-12236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12236
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Sylvain Lebresne
> Fix For: 3.8, 3.9
>
> Attachments: 12236.txt
>
>
> This RTE is not harmless. It will cause the internode connection to break 
> which will cause all in flight requests between these nodes to die/timeout.
> {noformat}
> - Due to changes in schema migration handling and the storage format 
> after 3.0, you will
>   see error messages such as:
>  "java.lang.RuntimeException: Unknown column cdc during 
> deserialization"
>   in your system logs on a mixed-version cluster during upgrades. This 
> error message
>   is harmless and due to the 3.8 nodes having cdc added to their schema 
> tables while
>   the <3.8 nodes do not. This message should cease once all nodes are 
> upgraded to 3.8.
>   As always, refrain from schema changes during cluster upgrades.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12365) Document cassandra stress

2016-08-02 Thread Christopher Batey (JIRA)

Christopher Batey created CASSANDRA-12365:
-

 Summary: Document cassandra stress
 Key: CASSANDRA-12365
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12365
 Project: Cassandra
  Issue Type: Improvement
  Components: Documentation and Website
Reporter: Christopher Batey
Assignee: Christopher Batey
Priority: Minor


I've started on this so creating a ticket to avoid duplicate work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12140) dtest failure in materialized_views_test.TestMaterializedViews.add_write_survey_node_after_mv_test

2016-08-02 Thread Craig Kodman (JIRA)


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

Craig Kodman updated CASSANDRA-12140:
-
Description: 
example failure:

http://cassci.datastax.com/job/trunk_novnode_dtest/409/testReport/materialized_views_test/TestMaterializedViews/add_write_survey_node_after_mv_test

Failed on CassCI build trunk_novnode_dtest #409

{code}
Standard Output

Unexpected error in node4 log, error: 
ERROR [main] 2016-06-27 15:28:13,139 MigrationManager.java:164 - Migration task 
failed to complete
{code}

http://cassci.datastax.com/job/trunk_novnode_dtest/432/testReport/materialized_views_test/TestMaterializedViews/add_dc_after_mv_simple_replication_test/

http://cassci.datastax.com/job/trunk_offheap_dtest/309/testReport/materialized_views_test/TestMaterializedViews/add_dc_after_mv_network_replication_test/

http://cassci.datastax.com/job/trunk_offheap_dtest/309/testReport/materialized_views_test/TestMaterializedViews/add_dc_after_mv_network_replication_test/



  was:
example failure:

http://cassci.datastax.com/job/trunk_novnode_dtest/409/testReport/materialized_views_test/TestMaterializedViews/add_write_survey_node_after_mv_test

Failed on CassCI build trunk_novnode_dtest #409

{code}
Standard Output

Unexpected error in node4 log, error: 
ERROR [main] 2016-06-27 15:28:13,139 MigrationManager.java:164 - Migration task 
failed to complete
{code}

http://cassci.datastax.com/job/trunk_novnode_dtest/432/testReport/materialized_views_test/TestMaterializedViews/add_dc_after_mv_simple_replication_test/


> dtest failure in 
> materialized_views_test.TestMaterializedViews.add_write_survey_node_after_mv_test
> --
>
> Key: CASSANDRA-12140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12140
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Carl Yeksigian
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log, 
> node4.log, node4_debug.log, node4_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/409/testReport/materialized_views_test/TestMaterializedViews/add_write_survey_node_after_mv_test
> Failed on CassCI build trunk_novnode_dtest #409
> {code}
> Standard Output
> Unexpected error in node4 log, error: 
> ERROR [main] 2016-06-27 15:28:13,139 MigrationManager.java:164 - Migration 
> task failed to complete
> {code}
> http://cassci.datastax.com/job/trunk_novnode_dtest/432/testReport/materialized_views_test/TestMaterializedViews/add_dc_after_mv_simple_replication_test/
> http://cassci.datastax.com/job/trunk_offheap_dtest/309/testReport/materialized_views_test/TestMaterializedViews/add_dc_after_mv_network_replication_test/
> http://cassci.datastax.com/job/trunk_offheap_dtest/309/testReport/materialized_views_test/TestMaterializedViews/add_dc_after_mv_network_replication_test/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12140) dtest failure in materialized_views_test.TestMaterializedViews.add_write_survey_node_after_mv_test

2016-08-02 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-12140:
--

For what it's worth, it could be the same than CASSANDRA-12364, since the later 
happens on the {{MigrationTask}}.

> dtest failure in 
> materialized_views_test.TestMaterializedViews.add_write_survey_node_after_mv_test
> --
>
> Key: CASSANDRA-12140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12140
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Carl Yeksigian
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log, 
> node4.log, node4_debug.log, node4_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/409/testReport/materialized_views_test/TestMaterializedViews/add_write_survey_node_after_mv_test
> Failed on CassCI build trunk_novnode_dtest #409
> {code}
> Standard Output
> Unexpected error in node4 log, error: 
> ERROR [main] 2016-06-27 15:28:13,139 MigrationManager.java:164 - Migration 
> task failed to complete
> {code}
> http://cassci.datastax.com/job/trunk_novnode_dtest/432/testReport/materialized_views_test/TestMaterializedViews/add_dc_after_mv_simple_replication_test/
> http://cassci.datastax.com/job/trunk_offheap_dtest/309/testReport/materialized_views_test/TestMaterializedViews/add_dc_after_mv_network_replication_test/
> http://cassci.datastax.com/job/trunk_offheap_dtest/309/testReport/materialized_views_test/TestMaterializedViews/add_dc_after_mv_network_replication_test/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CASSANDRA-12267) dtest failure in materialized_views_test.TestMaterializedViews.add_dc_after_mv_simple_replication_test

2016-08-02 Thread Craig Kodman (JIRA)


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

Craig Kodman resolved CASSANDRA-12267.
--
Resolution: Duplicate

> dtest failure in 
> materialized_views_test.TestMaterializedViews.add_dc_after_mv_simple_replication_test
> --
>
> Key: CASSANDRA-12267
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12267
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: DS Test Eng
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log, 
> node4.log, node4_debug.log, node4_gc.log, node5.log, node5_debug.log, 
> node5_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/432/testReport/materialized_views_test/TestMaterializedViews/add_dc_after_mv_simple_replication_test
> {code}
> Standard Output
> Unexpected error in node4 log, error: 
> ERROR [main] 2016-07-21 01:57:17,951 MigrationManager.java:164 - Migration 
> task failed to complete
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CASSANDRA-12164) dtest failure in materialized_views_test.TestMaterializedViews.add_dc_after_mv_network_replication_test

2016-08-02 Thread Craig Kodman (JIRA)


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

Craig Kodman resolved CASSANDRA-12164.
--
Resolution: Fixed

> dtest failure in 
> materialized_views_test.TestMaterializedViews.add_dc_after_mv_network_replication_test
> ---
>
> Key: CASSANDRA-12164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12164
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: DS Test Eng
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log, 
> node4.log, node4_debug.log, node4_gc.log, node5.log, node5_debug.log, 
> node5_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/309/testReport/materialized_views_test/TestMaterializedViews/add_dc_after_mv_network_replication_test
> Failed on CassCI build trunk_offheap_dtest #309
> {code}
> Standard Output
> Unexpected error in node4 log, error: 
> ERROR [main] 2016-07-06 19:21:26,631 MigrationManager.java:164 - Migration 
> task failed to complete
> {code}
> Related failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/423/testReport/materialized_views_test/TestMaterializedViews/add_node_after_mv_test/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12364) dtest failure in upgrade_tests.paging_test.TestPagingDatasetChangesNodes3RF3_Upgrade_current_3_x_To_indev_3_x.test_cell_TTL_expiry_during_paging

2016-08-02 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-12364:
--

The stack says that an internal schema propagation message raced with a node 
shutting down. We can {{ColumnFamilyStore.waitForFlushes}} to catch the 
exception, check we do are shutting down, and ignore the problem otherwise, and 
we probably should, but it's not the first time we see that kind of exception 
and it's never more than an annoyance (we're only ever shutting down pools on 
shutdown, as we should, and Cassandra being fault-tolerant, it's never a 
problem that something else race with such shutdown), so I wonder if the test 
framework shouldn't do an exception for that specific exception (it can always 
report it on the standard output, but provided that happens while shutting down 
a node (or during test teardown() in particular), it's probably ok to ignore 
it).

> dtest failure in 
> upgrade_tests.paging_test.TestPagingDatasetChangesNodes3RF3_Upgrade_current_3_x_To_indev_3_x.test_cell_TTL_expiry_during_paging
> 
>
> Key: CASSANDRA-12364
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12364
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: DS Test Eng
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_Upgrade_current_3_x_To_indev_3_x/test_cell_TTL_expiry_during_paging
> {code}
> Error Message
> Unexpected error in log, see stdout
> {code}
> {code}
> Standard Output
> http://git-wip-us.apache.org/repos/asf/cassandra.git 
> git:5051c0f6eb3f984600600c9577d6b5ece9038c74
> Unexpected error in node1 log, error: 
> ERROR [InternalResponseStage:4] 2016-07-28 03:23:02,097 
> CassandraDaemon.java:217 - Exception in thread 
> Thread[InternalResponseStage:4,5,main]
> java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut 
> down
>   at 
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
>  ~[apache-cassandra-3.7.jar:3.7]
>   at 
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) 
> ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) 
> ~[na:1.8.0_51]
>   at 
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
>  ~[apache-cassandra-3.7.jar:3.7]
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.waitForFlushes(ColumnFamilyStore.java:930)
>  ~[apache-cassandra-3.7.jar:3.7]
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.forceFlush(ColumnFamilyStore.java:892)
>  ~[apache-cassandra-3.7.jar:3.7]
>   at 
> org.apache.cassandra.schema.SchemaKeyspace.lambda$flush$1(SchemaKeyspace.java:279)
>  ~[apache-cassandra-3.7.jar:3.7]
>   at 
> org.apache.cassandra.schema.SchemaKeyspace$$Lambda$200/2113926365.accept(Unknown
>  Source) ~[na:na]
>   at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_51]
>   at 
> org.apache.cassandra.schema.SchemaKeyspace.flush(SchemaKeyspace.java:279) 
> ~[apache-cassandra-3.7.jar:3.7]
>   at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1271)
>  ~[apache-cassandra-3.7.jar:3.7]
>   at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1253)
>  ~[apache-cassandra-3.7.jar:3.7]
>   at 
> org.apache.cassandra.service.MigrationTask$1.response(MigrationTask.java:92) 
> ~[apache-cassandra-3.7.jar:3.7]
>   at 
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:53)
>  ~[apache-cassandra-3.7.jar:3.7]
>   at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
> ~[apache-cassandra-3.7.jar:3.7]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_51]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
> {code}
> Related failures:
> http://cassci.datastax.com/job/trunk_dtest_upgrade/11/testReport/upgrade_tests.paging_test/Tes

cassandra git commit: ninja: use commons-lang3

2016-08-02 Thread yukim

Repository: cassandra
Updated Branches:
  refs/heads/trunk becd730ad -> 20baafdeb


ninja: use commons-lang3


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

Branch: refs/heads/trunk
Commit: 20baafdeb01dcb5878ac193e5f1c31c4e4522274
Parents: becd730
Author: Yuki Morishita 
Authored: Tue Aug 2 10:59:44 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Aug 2 10:59:58 2016 -0500

--
 .../apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/20baafde/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java 
b/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java
index 1cc303c..7f50a03 100644
--- a/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java
+++ b/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java
@@ -22,7 +22,7 @@ import java.io.FilenameFilter;
 import java.io.IOException;
 
 import com.google.common.io.Files;
-import org.apache.commons.lang.ArrayUtils;
+import org.apache.commons.lang3.ArrayUtils;
 import org.junit.After;
 import org.junit.AfterClass;
 import org.junit.Before;

[jira] [Commented] (CASSANDRA-9608) Support Java 9

2016-08-02 Thread Robert Stupp (JIRA)


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

Robert Stupp commented on CASSANDRA-9608:
-

There's a potential blocker for us in Java9:
We rely on {{sun.nio.ch.DirectBuffer.cleaner().clean()}} to free memory mapped 
files (and also off heap memory, but that's handled in a different ticket).
{{DirectBuffer.cleaner()}} before Java 9 is returns a {{sun.misc.Cleaner}}, but 
Java 9 returns {{jdk.internal.ref.Cleaner}} - this makes it very hard to 
maintain Java 8 and Java 9 compatibility. We have to use this ugly thing, 
because we do not want to want for some garbage collection to occur to free 
mmap'd regions or free off heap memory.

> Support Java 9
> --
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
>  Issue Type: Task
>Reporter: Robert Stupp
>Priority: Minor
>
> This ticket is intended to group all issues found to support Java 9 in the 
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved. 
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +  
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods 
> {{monitorEnter}} + {{monitorExit}}. These methods are used by 
> {{o.a.c.utils.concurrent.Locks}} which is only used by 
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early 
> development phase.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12039) Add an index callback to be notified post bootstrap and before joining the ring

2016-08-02 Thread Brandon Williams (JIRA)


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

Brandon Williams commented on CASSANDRA-12039:
--

Write survey mode works exactly like bootstrap, it just never sets the 
completed flag, so nodes continue to forward 'extra' writes to it, but then 
later if you decide the node should join you can do so with nodetool.  Or if 
you decide it's bad, you can just kill it, since it never became a full member 
of the ring.

> Add an index callback to be notified post bootstrap and before joining the 
> ring
> ---
>
> Key: CASSANDRA-12039
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12039
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Sergio Bossa
>Assignee: Sergio Bossa
>
> Custom index implementations might need to be notified when the node finishes 
> bootstrapping in order to execute some blocking tasks before the node itself 
> goes into NORMAL state.
> This is a proposal to add such functionality, which should roughly require 
> the following:
> 1) Add a {{getPostBootstrapTask}} callback to the {{Index}} interface.
> 2) Add an {{executePostBootstrapBlockingTasks}} method to 
> {{SecondaryIndexManager}} calling into the previously mentioned callback.
> 3) Hook that into {{StorageService#joinTokenRing}}.
> Thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12366) Fix compaction throttle

2016-08-02 Thread T Jake Luciani (JIRA)

T Jake Luciani created CASSANDRA-12366:
--

 Summary: Fix compaction throttle
 Key: CASSANDRA-12366
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12366
 Project: Cassandra
  Issue Type: Bug
  Components: Compaction
Reporter: T Jake Luciani
Assignee: T Jake Luciani
 Fix For: 3.x


Compaction throttling is broken in the following ways:

  * It throttles bytes read after compression
  * Compaction creates multiple scanners which share the rate limiter causing 
too much throttling
  * It bears no resemblance to the reported compaction time remaining 
calculation (Bytes of source sstables processed since start of compaction)

To fix this we need to simplify the throttling to be only at the 
CompactionIterator level.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12366) Fix compaction throttle

2016-08-02 Thread T Jake Luciani (JIRA)


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

T Jake Luciani updated CASSANDRA-12366:
---
Description: 
Compaction throttling is broken in the following ways:

  * It throttles bytes read after being decompressed
  * Compaction creates multiple scanners which share the rate limiter causing 
too much throttling
  * It bears no resemblance to the reported compaction time remaining 
calculation (Bytes of source sstables processed since start of compaction)

To fix this we need to simplify the throttling to be only at the 
CompactionIterator level.

  was:
Compaction throttling is broken in the following ways:

  * It throttles bytes read after compression
  * Compaction creates multiple scanners which share the rate limiter causing 
too much throttling
  * It bears no resemblance to the reported compaction time remaining 
calculation (Bytes of source sstables processed since start of compaction)

To fix this we need to simplify the throttling to be only at the 
CompactionIterator level.


> Fix compaction throttle
> ---
>
> Key: CASSANDRA-12366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12366
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
> Fix For: 3.x
>
>
> Compaction throttling is broken in the following ways:
>   * It throttles bytes read after being decompressed
>   * Compaction creates multiple scanners which share the rate limiter causing 
> too much throttling
>   * It bears no resemblance to the reported compaction time remaining 
> calculation (Bytes of source sstables processed since start of compaction)
> To fix this we need to simplify the throttling to be only at the 
> CompactionIterator level.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12360) Unable to parse negative dates

2016-08-02 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna edited comment on CASSANDRA-12360 at 8/2/16 5:00 PM:
--

{code}
cqlsh:jeremy> create table jeremy.testdate (d date primary key);
cqlsh:jeremy> INSERT INTO testdate (d) VALUES ('-0407-12-27T00:00:00Z');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Unable to 
coerce '-0407-12-27T00:00:00Z' to a formatted date (long)"
{code}

The {{date}} type should be able to go to negative values to accommodate BC 
years but it looks like we have a bug.


was (Author: jeromatron):
{code}
[cqlsh:jeremy> create table jeremy.testdate (d date primary key);
cqlsh:jeremy> INSERT INTO testdate (d) VALUES ('-0407-12-27T00:00:00Z');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Unable to 
coerce '-0407-12-27T00:00:00Z' to a formatted date (long)"
{code}

The {{date}} type should be able to go to negative values to accommodate BC 
years but it looks like we have a bug.

> Unable to parse negative dates
> --
>
> Key: CASSANDRA-12360
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12360
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Bryn Cooke
>
> {code}
> cqlsh:date_test> DESC test;
> CREATE TABLE date_test.test (
> date timestamp PRIMARY KEY
> ) ...
> cqlsh:date_test> INSERT INTO test (date) VALUES ('-0407-12-27T00:00:00Z');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Unable 
> to coerce '-0407-12-27T00:00:00Z' to a formatted date (long)"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12360) Unable to parse negative dates

2016-08-02 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna commented on CASSANDRA-12360:
--

{code}
[cqlsh:jeremy> create table jeremy.testdate (d date primary key);
cqlsh:jeremy> INSERT INTO testdate (d) VALUES ('-0407-12-27T00:00:00Z');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Unable to 
coerce '-0407-12-27T00:00:00Z' to a formatted date (long)"
{code}

The {{date}} type should be able to go to negative values to accommodate BC 
years but it looks like we have a bug.

> Unable to parse negative dates
> --
>
> Key: CASSANDRA-12360
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12360
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Bryn Cooke
>
> {code}
> cqlsh:date_test> DESC test;
> CREATE TABLE date_test.test (
> date timestamp PRIMARY KEY
> ) ...
> cqlsh:date_test> INSERT INTO test (date) VALUES ('-0407-12-27T00:00:00Z');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Unable 
> to coerce '-0407-12-27T00:00:00Z' to a formatted date (long)"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11356) EC2MRS ignores broadcast_rpc_address setting in cassandra.yaml

2016-08-02 Thread Paulo Motta (JIRA)


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

Paulo Motta commented on CASSANDRA-11356:
-

On EC2 users need to choose which {{rpc_address}} to broadcast to other nodes: 
if the private IP or the public IP (since both are routable to the private IF). 
 Before CASSANDRA-5899 it broadcasted {{rpc_address}} which defaulted to 
{{listen_address}}, which was typically set to private IP on EC2 deployments. 
CASSANDRA-5899 added ability to choose which IP to broadcast via the 
{{broadcast_rpc_address}}, but it also changed {{Ec2MultiRegionSnitch}} to 
*always* broadcast the public IP, regardless of {{broadcast_rpc_address}}, what 
makes impossible for nodes to advertise their private IP for client connections 
if they want to.

This patch updates {{Ec2MultiRegionSnitch}} to only set 
{{broadcast_rpc_address}} to the public IP if this property is unset, allowing 
operators to overide this to the private IP if they want to. 

Before {{DatabaseDescriptor}} was setting {{broadcastRpcAddress = rpcAddress}}, 
so it was impossible to know if {{broadcastRpcAddress == null}} in order to 
decide whether or not to override the property on {{Ec2MultiRegionSnitch}}, so 
I modified all uses of {{DatabaseDescriptor.getBroadcastRpcAddress()}} to use 
{{FBUtilities.getBroadcastRpcAddress()}} instead which will fallback to 
{{DatabaseDescriptor.getRpcAddress()}} if 
{{DatabaseDescriptor.getBroadcastRpcAddress() == null}}.

Patch and tests available below:

||2.2||3.0||3.9||trunk||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...pauloricardomg:2.2-11356]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:3.0-11356]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.9...pauloricardomg:3.9-11356]|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:trunk-11356]|
|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-11356-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-11356-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.9-11356-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-11356-testall/lastCompletedBuild/testReport/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-11356-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-11356-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.9-11356-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-11356-dtest/lastCompletedBuild/testReport/]|

Could you have a look [~thobbs]? Thanks!

> EC2MRS ignores broadcast_rpc_address setting in cassandra.yaml
> --
>
> Key: CASSANDRA-11356
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11356
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Thanh
>Assignee: Paulo Motta
> Fix For: 2.2.x, 3.x
>
>
> EC2MRS ignores broadcast_rpc_address setting in cassandra.yaml.  This is 
> problematic for those users who were using EC2MRS with an internal 
> rpc_address before the change introduced in 
> [CASSANDRA-5899|https://issues.apache.org/jira/browse/CASSANDRA-5899], 
> because the change results in EC2MRS always using the public ip regardless of 
> what the user has set for broadcast_rpc_address.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11356) EC2MRS ignores broadcast_rpc_address setting in cassandra.yaml

2016-08-02 Thread Paulo Motta (JIRA)


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

Paulo Motta updated CASSANDRA-11356:

Status: Patch Available  (was: Open)

> EC2MRS ignores broadcast_rpc_address setting in cassandra.yaml
> --
>
> Key: CASSANDRA-11356
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11356
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Thanh
>Assignee: Paulo Motta
> Fix For: 2.2.x, 3.x
>
>
> EC2MRS ignores broadcast_rpc_address setting in cassandra.yaml.  This is 
> problematic for those users who were using EC2MRS with an internal 
> rpc_address before the change introduced in 
> [CASSANDRA-5899|https://issues.apache.org/jira/browse/CASSANDRA-5899], 
> because the change results in EC2MRS always using the public ip regardless of 
> what the user has set for broadcast_rpc_address.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12352) dtest failure in upgrade_tests.storage_engine_upgrade_test.TestLoadLaCompactSStables.sstableloader_compression_snappy_to_snappy_test

2016-08-02 Thread Russ Hatch (JIRA)


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

Russ Hatch updated CASSANDRA-12352:
---
Description: 
These are all similar looking test failures, which appear to be timeout issues 
of some kind.
{noformat}('Unable to connect to any servers', {'127.0.0.1': 
OperationTimedOut('errors=Timed out creating connection (10 seconds), 
last_host=None',)}){noformat}


http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.storage_engine_upgrade_test/TestLoadLaCompactSStables/sstableloader_compression_snappy_to_snappy_test

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.storage_engine_upgrade_test/TestLoadLaSStables/sstableloader_compression_deflate_to_deflate_test/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDataNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x/test_paging_across_multi_wide_rows/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDataNodes3RF3_Upgrade_current_2_1_x_To_indev_3_0_x/test_paging_across_multi_wide_rows/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingSizeNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x/test_undefined_page_size_default/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_Upgrade_current_2_1_x_To_indev_3_0_x/test_cell_TTL_expiry_during_paging/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingSizeNodes2RF1_Upgrade_current_2_2_x_To_indev_3_0_x/test_undefined_page_size_default/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes2RF1_Upgrade_current_3_0_x_To_indev_3_0_x/test_cell_TTL_expiry_during_paging/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x/test_row_TTL_expiry_during_paging/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.storage_engine_upgrade_test/TestBootstrapAfterUpgrade/upgrade_with_unclustered_CQL_table_test/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_2_x_To_indev_3_0_x/range_tombstones_compaction_test/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_3_0_x_To_indev_3_0_x/bug_5732_test/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_2_x_To_indev_3_0_x/collection_flush_test/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_3_0_x_To_indev_3_0_x/large_count_test/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x/conditional_delete_test/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x/range_tombstones_compaction_test/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingWithDeletionsNodes2RF1_Upgrade_current_2_2_x_To_indev_3_0_x/test_failure_threshold_deletions/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingWithDeletionsNodes2RF1_Upgrade_current_3_0_x_To_indev_3_0_x/test_ttl_deletions/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x/limit_multiget_test/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_1_x_To_indev_3_0_x/limit_multiget_test/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_Upgrade_current_2_2_x_To_indev_3_0_x/test_data_change_impacting_later_page/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_2_x_To_indev_3_0_x/expanded_list_item_conditional_test/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_2_x_To_indev_3_0_x/no_range_ghost_test/

http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x/limit_compact_table_test/

htt

[jira] [Issue Comment Deleted] (CASSANDRA-12352) dtest failure in upgrade_tests.storage_engine_upgrade_test.TestLoadLaCompactSStables.sstableloader_compression_snappy_to_snappy_test

2016-08-02 Thread Russ Hatch (JIRA)


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

Russ Hatch updated CASSANDRA-12352:
---
Comment: was deleted

(was: [~craig.kodman] could you clarify what the Decription above means? Are 
those all failures for this issue?)

> dtest failure in 
> upgrade_tests.storage_engine_upgrade_test.TestLoadLaCompactSStables.sstableloader_compression_snappy_to_snappy_test
> 
>
> Key: CASSANDRA-12352
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12352
> Project: Cassandra
>  Issue Type: Test
>Reporter: Craig Kodman
>Assignee: DS Test Eng
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log
>
>
> These are all similar looking test failures, which appear to be timeout 
> issues of some kind.
> {noformat}('Unable to connect to any servers', {'127.0.0.1': 
> OperationTimedOut('errors=Timed out creating connection (10 seconds), 
> last_host=None',)}){noformat}
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.storage_engine_upgrade_test/TestLoadLaCompactSStables/sstableloader_compression_snappy_to_snappy_test
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.storage_engine_upgrade_test/TestLoadLaSStables/sstableloader_compression_deflate_to_deflate_test/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDataNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x/test_paging_across_multi_wide_rows/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDataNodes3RF3_Upgrade_current_2_1_x_To_indev_3_0_x/test_paging_across_multi_wide_rows/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingSizeNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x/test_undefined_page_size_default/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_Upgrade_current_2_1_x_To_indev_3_0_x/test_cell_TTL_expiry_during_paging/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingSizeNodes2RF1_Upgrade_current_2_2_x_To_indev_3_0_x/test_undefined_page_size_default/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes2RF1_Upgrade_current_3_0_x_To_indev_3_0_x/test_cell_TTL_expiry_during_paging/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x/test_row_TTL_expiry_during_paging/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.storage_engine_upgrade_test/TestBootstrapAfterUpgrade/upgrade_with_unclustered_CQL_table_test/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_2_x_To_indev_3_0_x/range_tombstones_compaction_test/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_3_0_x_To_indev_3_0_x/bug_5732_test/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_2_x_To_indev_3_0_x/collection_flush_test/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_3_0_x_To_indev_3_0_x/large_count_test/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x/conditional_delete_test/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x/range_tombstones_compaction_test/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingWithDeletionsNodes2RF1_Upgrade_current_2_2_x_To_indev_3_0_x/test_failure_threshold_deletions/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingWithDeletionsNodes2RF1_Upgrade_current_3_0_x_To_indev_3_0_x/test_ttl_deletions/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x/limit_multiget_test/
> http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_1_x_To_i

[jira] [Commented] (CASSANDRA-12335) Super columns are broken after upgrading to 3.0

2016-08-02 Thread Aleksey Yeschenko (JIRA)


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

Aleksey Yeschenko commented on CASSANDRA-12335:
---

The first issue is that we have a bug in 
{{LegacySchemaMigrator::calculateIsDense()}} that does not correctly recognise 
the denseness of the table. Fixing it is unfortunately not enough, however. The 
returned resultset is still incorrect, exposing the internal super column map. 
I believe {{compound}} flag should also be set here, as the full 2.1 comparator 
is compound. But even with that, the internal column is still being exposed, 
but the {{value}} column is null. At least {{SelectStatement}} needs to be 
modified as well.


2.1, correct output:

{noformat}
cqlsh:test> select * from "Sites";

key  | column1| column2 | value
--++-+--
 0x53696d6f6e | 0x61747472 |name | 0x53696d6f6e
 0x426f62 | 0x61747472 |name | 0x426f62
{noformat}

3.0 HEAD:

{noformat}
cqlsh:test> select * from "Sites";

 key  | column1|
--++
 0x53696d6f6e | 0x000461747472046e616d6500 | {'name': 0x53696d6f6e}
 0x426f62 | 0x000461747472046e616d6500 | {'name': 0x426f62}
{noformat}

3.0, with {{dense}} flag correctly preserved:

{noformat}
cqlsh:test> select * from "Sites";

 key  | column1| column2 |  
  | value
--++-++---
 0x53696d6f6e | 0x000461747472046e616d6500 |null | {'name': 
0x53696d6f6e} |  null
 0x426f62 | 0x000461747472046e616d6500 |null | {'name': 
0x426f62} |  null
{noformat}

3.0, with both {{dense}} and {{compound}} flags preserved:

{noformat}
cqlsh:test> select * from "Sites";

 key  | column1| column2 || value
--++-++---
 0x53696d6f6e | 0x61747472 |name | {'name': 0x53696d6f6e} |  null
 0x426f62 | 0x61747472 |name | {'name': 0x426f62} |  null
{noformat}

[~slebresne] do you mind having a look?

> Super columns are broken after upgrading to 3.0
> ---
>
> Key: CASSANDRA-12335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12335
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Jeremiah Jordan
>Assignee: Aleksey Yeschenko
> Fix For: 3.0.x, 3.x
>
>
> Super Columns are broken after upgrading to cassandra-3.0 HEAD.  The below 
> script shows this.
> 2.1 cli output for get:
> {code}
> [default@test] get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8;
> => (name=name, value=Bob, timestamp=1469724504357000)
> {code}
> cqlsh:
> {code}
> [default@test]
>  key  | blobAsText(column1)
> --+-
>  0x53696d6f6e |attr
>  0x426f62 |attr
> {code}
> 3.0 cli:
> {code}
> [default@unknown] use test;
> unconfigured table schema_columnfamilies
> [default@test] get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8;
> null
> [default@test]
> {code}
> cqlsh:
> {code}
>  key  | system.blobastext(column1)
> --+--
>  0x53696d6f6e | \x00\x04attr\x00\x00\x04name\x00
>  0x426f62 | \x00\x04attr\x00\x00\x04name\x00
> {code}
> Run this from a directory with cassandra-3.0 checked out and compiled
> {code}
> ccm create -n 2 -v 2.1.14 testsuper
> echo "### Starting 2.1 ###"
> ccm start
> MYFILE=`mktemp`
> echo "create keyspace test with placement_strategy = 
> 'org.apache.cassandra.locator.SimpleStrategy' and strategy_options = 
> {replication_factor:2};
> use test;
> create column family Sites with column_type = 'Super' and comparator = 
> 'BytesType' and subcomparator='UTF8Type';
> set Sites[utf8('Simon')][utf8('attr')]['name'] = utf8('Simon');
> set Sites[utf8('Bob')][utf8('attr')]['name'] = utf8('Bob');
> get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8;" > $MYFILE
> ~/.ccm/repository/2.1.14/bin/cassandra-cli < $MYFILE
> rm $MYFILE
> ~/.ccm/repository/2.1.14/bin/nodetool -p 7100 flush
> ~/.ccm/repository/2.1.14/bin/nodetool -p 7200 flush
> ccm stop
> # run from cassandra-3.0 checked out and compiled
> ccm setdir
> echo "### Starting Current Directory 
> ###"
> ccm start
> ./bin/nodetool -p 7100 upgradesstables
> ./bin/nodetool -p 7200 upgradesstables
> ./bin/nodetool -p 7100 enablethrift
> ./bin/nodetool -p 7200 enablethrift
> MYFILE=`mktemp`
> echo "use test;
> get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8;" > $MYFILE
> ~/.ccm/repository/2.1.14/bin/

[jira] [Commented] (CASSANDRA-12228) Write performance regression in 3.x vs 3.0

2016-08-02 Thread Ariel Weisberg (JIRA)


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

Ariel Weisberg commented on CASSANDRA-12228:


I think the default can be really simple. If there are multiple data 
directories use a value of 1 so concurrency will be # of data directories and 
there will be a single memtable flush. If there is a single directory set it to 
2 so there can be two concurrent memtable flushes to the single data directory.

If the user specifies a # of concurrent memtable flushes we honor that by 
providing enough threads to wait on the flushes as well as enough threads per 
disk that each memtable can flush concurrently.

I pushed an updated version reflecting this change. There is also a commit that 
removes memtable_cleanup_threshold.



> Write performance regression in 3.x vs 3.0
> --
>
> Key: CASSANDRA-12228
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12228
> Project: Cassandra
>  Issue Type: Bug
>Reporter: T Jake Luciani
>Assignee: Ariel Weisberg
>Priority: Minor
> Fix For: 3.9
>
>
> I've been tracking down a performance issue in trunk vs cassandra-3.0 branch.
> I think I've found it.  CASSANDRA-6696 changed the default memtable flush 
> default to 1 vs the min of 2 in cassandra-3.0.
> I don't see any technical reason for this and we should add back the min of 2 
> sstable flushers per disk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12335) Super columns are broken after upgrading to 3.0

2016-08-02 Thread Aleksey Yeschenko (JIRA)


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

Aleksey Yeschenko updated CASSANDRA-12335:
--
Assignee: Sylvain Lebresne  (was: Aleksey Yeschenko)

> Super columns are broken after upgrading to 3.0
> ---
>
> Key: CASSANDRA-12335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12335
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Jeremiah Jordan
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.x
>
>
> Super Columns are broken after upgrading to cassandra-3.0 HEAD.  The below 
> script shows this.
> 2.1 cli output for get:
> {code}
> [default@test] get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8;
> => (name=name, value=Bob, timestamp=1469724504357000)
> {code}
> cqlsh:
> {code}
> [default@test]
>  key  | blobAsText(column1)
> --+-
>  0x53696d6f6e |attr
>  0x426f62 |attr
> {code}
> 3.0 cli:
> {code}
> [default@unknown] use test;
> unconfigured table schema_columnfamilies
> [default@test] get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8;
> null
> [default@test]
> {code}
> cqlsh:
> {code}
>  key  | system.blobastext(column1)
> --+--
>  0x53696d6f6e | \x00\x04attr\x00\x00\x04name\x00
>  0x426f62 | \x00\x04attr\x00\x00\x04name\x00
> {code}
> Run this from a directory with cassandra-3.0 checked out and compiled
> {code}
> ccm create -n 2 -v 2.1.14 testsuper
> echo "### Starting 2.1 ###"
> ccm start
> MYFILE=`mktemp`
> echo "create keyspace test with placement_strategy = 
> 'org.apache.cassandra.locator.SimpleStrategy' and strategy_options = 
> {replication_factor:2};
> use test;
> create column family Sites with column_type = 'Super' and comparator = 
> 'BytesType' and subcomparator='UTF8Type';
> set Sites[utf8('Simon')][utf8('attr')]['name'] = utf8('Simon');
> set Sites[utf8('Bob')][utf8('attr')]['name'] = utf8('Bob');
> get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8;" > $MYFILE
> ~/.ccm/repository/2.1.14/bin/cassandra-cli < $MYFILE
> rm $MYFILE
> ~/.ccm/repository/2.1.14/bin/nodetool -p 7100 flush
> ~/.ccm/repository/2.1.14/bin/nodetool -p 7200 flush
> ccm stop
> # run from cassandra-3.0 checked out and compiled
> ccm setdir
> echo "### Starting Current Directory 
> ###"
> ccm start
> ./bin/nodetool -p 7100 upgradesstables
> ./bin/nodetool -p 7200 upgradesstables
> ./bin/nodetool -p 7100 enablethrift
> ./bin/nodetool -p 7200 enablethrift
> MYFILE=`mktemp`
> echo "use test;
> get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8;" > $MYFILE
> ~/.ccm/repository/2.1.14/bin/cassandra-cli < $MYFILE
> rm $MYFILE
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

1 2 >

1 - 100 of 181 matches

Mail list logo