date:20170125


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

Jeff Jirsa updated CASSANDRA-13114:
---
Assignee: Stefan Podkowinski

> 3.0.x: update netty
> ---
>
> Key: CASSANDRA-13114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13114
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van der Woerdt
>Assignee: Stefan Podkowinski
> Attachments: 13114_netty-4.0.43_2.x-3.0.patch, 
> 13114_netty-4.0.43_3.11.patch
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-12032 updated netty for 
> Cassandra 3.8, but this wasn't backported. Netty 4.0.23, which ships with 
> Cassandra 3.0.x, has some serious bugs around memory handling for SSL 
> connections.
> It would be nice if both were updated to 4.0.42, a version released this year.
> 4.0.23 makes it impossible for me to run SSL, because nodes run out of memory 
> every ~30 minutes. This was fixed in 4.0.27.



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

[jira] [Issue Comment Deleted] (CASSANDRA-12694) PAXOS Update Corrupted empty row exception


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

Jeff Jirsa updated CASSANDRA-12694:
---
Comment: was deleted

(was: FYI, this commit ( 
https://github.com/apache/cassandra/commit/d9b06e8af41c42244f76058641aeecda53a9bf75
 ) didn't have the CHANGES.txt entry and used an incorrect JIRA number.
)

> PAXOS Update Corrupted empty row exception
> --
>
> Key: CASSANDRA-12694
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12694
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: 3 node cluster using RF=3 running on cassandra 3.7
>Reporter: Cameron Zemek
>Assignee: Alex Petrov
> Fix For: 3.0.11, 3.10
>
>
> {noformat}
> cqlsh> create table test.test (test_id TEXT, last_updated TIMESTAMP, 
> message_id TEXT, PRIMARY KEY(test_id));
> update test.test set last_updated = 1474494363669 where test_id = 'test1' if 
> message_id = null;
> {noformat}
> Then nodetool flush on the all 3 nodes.
> {noformat}
> cqlsh> update test.test set last_updated = 1474494363669 where test_id = 
> 'test1' if message_id = null;
> ServerError: 
> {noformat}
> From cassandra log
> {noformat}
> ERROR [SharedPool-Worker-1] 2016-09-23 12:09:13,179 Message.java:611 - 
> Unexpected exception during request; channel = [id: 0x7a22599e, 
> L:/127.0.0.1:9042 - R:/127.0.0.1:58297]
> java.io.IOError: java.io.IOException: Corrupt empty row found in unfiltered 
> partition
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:224)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:212)
>  ~[main/:na]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:125)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:249)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:87) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.ReadResponse$DataResponse.digest(ReadResponse.java:192)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.DigestResolver.resolve(DigestResolver.java:80) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:139) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1714)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1663) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1604) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1523) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readOne(StorageProxy.java:1497) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readOne(StorageProxy.java:1491) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:249) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:441)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:416)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:208)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:239) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:224) 
> ~[main/:na]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
>  [main/:na]
> {noformat}



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

[jira] [Commented] (CASSANDRA-12694) PAXOS Update Corrupted empty row exception


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

Jeff Jirsa commented on CASSANDRA-12694:


FYI, this commit ( 
https://github.com/apache/cassandra/commit/d9b06e8af41c42244f76058641aeecda53a9bf75
 ) didn't have the CHANGES.txt entry and used an incorrect JIRA number.


> PAXOS Update Corrupted empty row exception
> --
>
> Key: CASSANDRA-12694
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12694
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: 3 node cluster using RF=3 running on cassandra 3.7
>Reporter: Cameron Zemek
>Assignee: Alex Petrov
> Fix For: 3.0.11, 3.10
>
>
> {noformat}
> cqlsh> create table test.test (test_id TEXT, last_updated TIMESTAMP, 
> message_id TEXT, PRIMARY KEY(test_id));
> update test.test set last_updated = 1474494363669 where test_id = 'test1' if 
> message_id = null;
> {noformat}
> Then nodetool flush on the all 3 nodes.
> {noformat}
> cqlsh> update test.test set last_updated = 1474494363669 where test_id = 
> 'test1' if message_id = null;
> ServerError: 
> {noformat}
> From cassandra log
> {noformat}
> ERROR [SharedPool-Worker-1] 2016-09-23 12:09:13,179 Message.java:611 - 
> Unexpected exception during request; channel = [id: 0x7a22599e, 
> L:/127.0.0.1:9042 - R:/127.0.0.1:58297]
> java.io.IOError: java.io.IOException: Corrupt empty row found in unfiltered 
> partition
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:224)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:212)
>  ~[main/:na]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:125)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:249)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:87) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.ReadResponse$DataResponse.digest(ReadResponse.java:192)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.DigestResolver.resolve(DigestResolver.java:80) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:139) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1714)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1663) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1604) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1523) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readOne(StorageProxy.java:1497) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readOne(StorageProxy.java:1491) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:249) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:441)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:416)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:208)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:239) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:224) 
> ~[main/:na]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
>  [main/:na]
> {noformat}



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

[jira] [Commented] (CASSANDRA-12867) Batch with multiple conditional updates for the same partition causes AssertionError


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

Jeff Jirsa commented on CASSANDRA-12867:


[~KurtG] - Just to clarify - the description says that this is reproduced AND 
fixed in 3.0.10.

The commit is a week before 3.0.10 was cut, so this was a regression from 3.0.9 
that was fixed before 3.0.10 actually shipped, correct?


> Batch with multiple conditional updates for the same partition causes 
> AssertionError
> 
>
> Key: CASSANDRA-12867
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12867
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Kurt Greaves
>Assignee: Sylvain Lebresne
>Priority: Critical
> Fix For: 3.0.10, 3.10
>
> Attachments: 12867-3.0.patch
>
>
> Reproduced in 3.0.10 and 3.10. Used to work in 3.0.9 and earlier. Bug was 
> introduced in CASSANDRA-12060.
> The following causes an AssertionError:
> {code}
> CREATE KEYSPACE test WITH replication = { 'class' : 'SimpleStrategy', 
> 'replication_factor' : 1 };
> create table test.test (id int PRIMARY KEY, val text);
> BEGIN BATCH INSERT INTO test.test (id, val) VALUES (999, 'aaa') IF NOT 
> EXISTS; INSERT INTO test.test (id, val) VALUES (999, 'ccc') IF NOT EXISTS; 
> APPLY BATCH ;
> {code}
> Stack trace is as follows:
> {code}
> ERROR [Native-Transport-Requests-2] 2016-10-31 04:16:44,231 Message.java:622 
> - Unexpected exception during request; channel = [id: 0x176e1c04, 
> L:/127.0.0.1:9042 - R:/127.0.0.1:59743]
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.setConditionsForRow(CQL3CasRequest.java:138)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.addExistsCondition(CQL3CasRequest.java:104)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.addNotExist(CQL3CasRequest.java:84)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.IfNotExistsCondition.addConditionsTo(IfNotExistsCondition.java:28)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.addConditions(ModificationStatement.java:482)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.makeCasRequest(BatchStatement.java:434)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.executeWithConditions(BatchStatement.java:379)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:358)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:346)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:341)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:218)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:249) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:234) 
> ~[main/:na]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:516)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:409)
>  [main/:na]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_102]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [main/:na]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102]
> {code}
> The problem is that previous will receive a value after the first statement 
> in the batch is evaluated in BatchStatement.makeCasRequest. I can't see any 
> reason why we have this assertion, it seems to me that it's

[jira] [Commented] (CASSANDRA-12694) PAXOS Update Corrupted empty row exception

2017-01-25 Thread Ben Slater (JIRA)


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

Ben Slater commented on CASSANDRA-12694:


I am on leave until Monday 30 Jan. If you need an immediate response please 
contact [1]sa...@instaclustr.com or [2]supp...@instaclustr.com as appropriate. 
For less urgent queries, I will be checking email every couple of days and 
respond or redirect. Cheers Ben Slater Instaclustr

--
Ben SlaterChief Product Officer[3]Instaclustr: Cassandra + Spark - 
Managed | Consulting | Support[4]www.instaclustr.com


[1] mailto:sa...@instaclustr.com
[2] mailto:supp...@instaclustr.com
[3] https://www.instaclustr.com
[4] http://www.instaclustr.com


> PAXOS Update Corrupted empty row exception
> --
>
> Key: CASSANDRA-12694
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12694
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: 3 node cluster using RF=3 running on cassandra 3.7
>Reporter: Cameron Zemek
>Assignee: Alex Petrov
> Fix For: 3.0.11, 3.10
>
>
> {noformat}
> cqlsh> create table test.test (test_id TEXT, last_updated TIMESTAMP, 
> message_id TEXT, PRIMARY KEY(test_id));
> update test.test set last_updated = 1474494363669 where test_id = 'test1' if 
> message_id = null;
> {noformat}
> Then nodetool flush on the all 3 nodes.
> {noformat}
> cqlsh> update test.test set last_updated = 1474494363669 where test_id = 
> 'test1' if message_id = null;
> ServerError: 
> {noformat}
> From cassandra log
> {noformat}
> ERROR [SharedPool-Worker-1] 2016-09-23 12:09:13,179 Message.java:611 - 
> Unexpected exception during request; channel = [id: 0x7a22599e, 
> L:/127.0.0.1:9042 - R:/127.0.0.1:58297]
> java.io.IOError: java.io.IOException: Corrupt empty row found in unfiltered 
> partition
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:224)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:212)
>  ~[main/:na]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:125)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:249)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:87) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.ReadResponse$DataResponse.digest(ReadResponse.java:192)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.DigestResolver.resolve(DigestResolver.java:80) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:139) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1714)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1663) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1604) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1523) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readOne(StorageProxy.java:1497) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readOne(StorageProxy.java:1491) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:249) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:441)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:416)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:208)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:239) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:224) 
> ~[main/:na]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
>  [main/:na]
> at 
>

[jira] [Updated] (CASSANDRA-12694) PAXOS Update Corrupted empty row exception


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

Jeff Jirsa updated CASSANDRA-12694:
---
Reproduced In: 3.7, 3.0.10  (was: 3.7)

> PAXOS Update Corrupted empty row exception
> --
>
> Key: CASSANDRA-12694
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12694
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: 3 node cluster using RF=3 running on cassandra 3.7
>Reporter: Cameron Zemek
>Assignee: Alex Petrov
> Fix For: 3.0.11, 3.10
>
>
> {noformat}
> cqlsh> create table test.test (test_id TEXT, last_updated TIMESTAMP, 
> message_id TEXT, PRIMARY KEY(test_id));
> update test.test set last_updated = 1474494363669 where test_id = 'test1' if 
> message_id = null;
> {noformat}
> Then nodetool flush on the all 3 nodes.
> {noformat}
> cqlsh> update test.test set last_updated = 1474494363669 where test_id = 
> 'test1' if message_id = null;
> ServerError: 
> {noformat}
> From cassandra log
> {noformat}
> ERROR [SharedPool-Worker-1] 2016-09-23 12:09:13,179 Message.java:611 - 
> Unexpected exception during request; channel = [id: 0x7a22599e, 
> L:/127.0.0.1:9042 - R:/127.0.0.1:58297]
> java.io.IOError: java.io.IOException: Corrupt empty row found in unfiltered 
> partition
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:224)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:212)
>  ~[main/:na]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:125)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:249)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:87) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.ReadResponse$DataResponse.digest(ReadResponse.java:192)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.DigestResolver.resolve(DigestResolver.java:80) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:139) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1714)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1663) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1604) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1523) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readOne(StorageProxy.java:1497) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readOne(StorageProxy.java:1491) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:249) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:441)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:416)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:208)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:239) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:224) 
> ~[main/:na]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
>  [main/:na]
> {noformat}



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

[jira] [Updated] (CASSANDRA-9530) SSTable corruption can trigger OOM


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

Jeff Jirsa updated CASSANDRA-9530:
--
Description: 
If a sstable is corrupted so that the length of a given value is bogus, we'll 
still happily try to allocate a buffer of that bogus size to read the value, 
which can easily lead to an OOM.

We should probably protect against this. In practice, a given value can be so 
big since it's limited by the protocol frame size in the first place. Maybe we 
could add a max_value_size_in_mb setting and we'd considered a sstable 
corrupted if it was containing a value bigger than that.

I'll note that this ticket would be a good occasion to improve 
{{BlacklistingCompactionsTest}}. Typically, it currently generate empty values 
which makes it pretty much impossible to get the problem described here. And as 
described in CASSANDRA-9478, it also doesn't test properly for thing like early 
opening of compaction results. We could try to randomize as much of the 
parameters of this test as possible to make it more likely to catch any type of 
corruption that could happen.


  was:
If a sstable is corrupted so that the length of a given is bogus, we'll still 
happily try to allocate a buffer of that bogus size to read the value, which 
can easily lead to an OOM.

We should probably protect against this. In practice, a given value can be so 
big since it's limited by the protocol frame size in the first place. Maybe we 
could add a max_value_size_in_mb setting and we'd considered a sstable 
corrupted if it was containing a value bigger than that.

I'll note that this ticket would be a good occasion to improve 
{{BlacklistingCompactionsTest}}. Typically, it currently generate empty values 
which makes it pretty much impossible to get the problem described here. And as 
described in CASSANDRA-9478, it also doesn't test properly for thing like early 
opening of compaction results. We could try to randomize as much of the 
parameters of this test as possible to make it more likely to catch any type of 
corruption that could happen.



> SSTable corruption can trigger OOM
> --
>
> Key: CASSANDRA-9530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9530
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Sylvain Lebresne
>Assignee: Alex Petrov
> Fix For: 3.0.7, 3.7, 3.8
>
>
> If a sstable is corrupted so that the length of a given value is bogus, we'll 
> still happily try to allocate a buffer of that bogus size to read the value, 
> which can easily lead to an OOM.
> We should probably protect against this. In practice, a given value can be so 
> big since it's limited by the protocol frame size in the first place. Maybe 
> we could add a max_value_size_in_mb setting and we'd considered a sstable 
> corrupted if it was containing a value bigger than that.
> I'll note that this ticket would be a good occasion to improve 
> {{BlacklistingCompactionsTest}}. Typically, it currently generate empty 
> values which makes it pretty much impossible to get the problem described 
> here. And as described in CASSANDRA-9478, it also doesn't test properly for 
> thing like early opening of compaction results. We could try to randomize as 
> much of the parameters of this test as possible to make it more likely to 
> catch any type of corruption that could happen.



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

[jira] [Commented] (CASSANDRA-13004) Corruption while adding a column to a table

2017-01-25 Thread Stanislav Vishnevskiy (JIRA)


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

Stanislav Vishnevskiy commented on CASSANDRA-13004:
---

[~jjirsa] We read and write at LOCAL_QUORUM. We don't remember if it corrupted 
the same way on each node, but we couldn't read it correctly with LOCAL_ONE 
when we tried. We have since fixed this data by rewriting it.

> Corruption while adding a column to a table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stanislav Vishnevskiy
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map,
> permission_overwrites map,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x05\xe8A\x00\x00\x00\x04\x10\x02\x00\x00\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00
>  
> \x08\x01\x00\x00\x00\x04\xc4\xb4(\x00\xff\xff\xff\xff\x00\x00\x00O[f\x80Q\x07general\x05\xf8G\xc5\xffI\x98\xc4\xb4(\x00\xf8O[f\x80Q\x00\x00\x00\x02\x04\xf8O[f\x80Q\x00\xf8G\xc5\xffI\x98\x01\x00\x00\xf8O[f\x80Q\x00\x00\x00\x00\xf8G\xc5\xffI\x97\xc4\xb4(\x06\x00\xf8O\x7fe\x1fm\x08\x03\x00\x00\x00\x01\x00\x00\x00\x00\x04\x00\x00\x00\x00'
> {code}
> And then in cqlsh when trying to read the row we got this. 
> {code:none}
> /usr/bin/cqlsh.py:632: DateOverFlowWarning: Some timestamps are larger than 
> Python datetime can represent. Timestamps are displayed in milliseconds from 
> epoch.
> Traceback (most recent call last):
>   File "/usr/bin/cqlsh.py", line 1301, in perform_simple_statement
> result = future.result()
>   File 
>

[jira] [Commented] (CASSANDRA-13004) Corruption while adding a column to a table


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

Jeff Jirsa commented on CASSANDRA-13004:


[~stanislav] or [~jhg] - can you confirm what CL you used to read and write 
data? Do you happen to know if your data was corrupt on more than one node?


> Corruption while adding a column to a table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stanislav Vishnevskiy
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map,
> permission_overwrites map,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x05\xe8A\x00\x00\x00\x04\x10\x02\x00\x00\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00
>  
> \x08\x01\x00\x00\x00\x04\xc4\xb4(\x00\xff\xff\xff\xff\x00\x00\x00O[f\x80Q\x07general\x05\xf8G\xc5\xffI\x98\xc4\xb4(\x00\xf8O[f\x80Q\x00\x00\x00\x02\x04\xf8O[f\x80Q\x00\xf8G\xc5\xffI\x98\x01\x00\x00\xf8O[f\x80Q\x00\x00\x00\x00\xf8G\xc5\xffI\x97\xc4\xb4(\x06\x00\xf8O\x7fe\x1fm\x08\x03\x00\x00\x00\x01\x00\x00\x00\x00\x04\x00\x00\x00\x00'
> {code}
> And then in cqlsh when trying to read the row we got this. 
> {code:none}
> /usr/bin/cqlsh.py:632: DateOverFlowWarning: Some timestamps are larger than 
> Python datetime can represent. Timestamps are displayed in milliseconds from 
> epoch.
> Traceback (most recent call last):
>   File "/usr/bin/cqlsh.py", line 1301, in perform_simple_statement
> result = future.result()
>   File 
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.5.0.post0-d8d0456.zip/cassandra-driver-3.5.0.post0-d8d0456/cassandra/cluster.py",
>  line 3650, in result
>

[jira] [Updated] (CASSANDRA-13157) reduce overheads of tracing

2017-01-25 Thread sankalp kohli (JIRA)


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

sankalp kohli updated CASSANDRA-13157:
--
Summary: reduce overheads of tracing  (was: reuce overheads of tracing)

> reduce overheads of tracing
> ---
>
> Key: CASSANDRA-13157
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13157
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Sam Overton
>Assignee: Sam Overton
>
> Currently we store a string description for every trace line of every request 
> that gets traced, and this adds a completely unnecessary memory and IO 
> overhead. We could just store a minimal representation of the measurements 
> and join them with the human-readable descriptions later on.



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

[jira] [Commented] (CASSANDRA-9988) Introduce leaf-only iterator


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

Jay Zhuang commented on CASSANDRA-9988:
---

Thanks Benedict for your quick response. I updated the patch with your comment.

[~jasobrown] would you please review the patch?

> Introduce leaf-only iterator
> 
>
> Key: CASSANDRA-9988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9988
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
>  Labels: patch
> Fix For: 4.0
>
> Attachments: 9988-trunk-new.txt, 9988-trunk-new-update.txt, 
> trunk-9988.txt
>
>
> In many cases we have small btrees, small enough to fit in a single leaf 
> page. In this case it _may_ be more efficient to specialise our iterator.



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

[jira] [Comment Edited] (CASSANDRA-9988) Introduce leaf-only iterator


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

Jay Zhuang edited comment on CASSANDRA-9988 at 1/25/17 9:42 PM:


Thanks Benedict for your quick response. I updated the 
[patch|https://github.com/cooldoger/cassandra/commit/d2e4621542149c68b23cb36d83289d92d722f9a0]
 with your comment.

[~jasobrown] would you please review the patch?


was (Author: jay.zhuang):
Thanks Benedict for your quick response. I updated the patch with your comment.

[~jasobrown] would you please review the patch?

> Introduce leaf-only iterator
> 
>
> Key: CASSANDRA-9988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9988
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
>  Labels: patch
> Fix For: 4.0
>
> Attachments: 9988-trunk-new.txt, 9988-trunk-new-update.txt, 
> trunk-9988.txt
>
>
> In many cases we have small btrees, small enough to fit in a single leaf 
> page. In this case it _may_ be more efficient to specialise our iterator.



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

[jira] [Updated] (CASSANDRA-9988) Introduce leaf-only iterator


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

Jay Zhuang updated CASSANDRA-9988:
--
Attachment: 9988-trunk-new-update.txt

> Introduce leaf-only iterator
> 
>
> Key: CASSANDRA-9988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9988
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
>  Labels: patch
> Fix For: 4.0
>
> Attachments: 9988-trunk-new.txt, 9988-trunk-new-update.txt, 
> trunk-9988.txt
>
>
> In many cases we have small btrees, small enough to fit in a single leaf 
> page. In this case it _may_ be more efficient to specialise our iterator.



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

[jira] [Created] (CASSANDRA-13157) reuce overheads of tracing

Sam Overton created CASSANDRA-13157:
---

 Summary: reuce overheads of tracing
 Key: CASSANDRA-13157
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13157
 Project: Cassandra
  Issue Type: Improvement
  Components: Observability
Reporter: Sam Overton
Assignee: Sam Overton


Currently we store a string description for every trace line of every request 
that gets traced, and this adds a completely unnecessary memory and IO 
overhead. We could just store a minimal representation of the measurements and 
join them with the human-readable descriptions later on.




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

[jira] [Updated] (CASSANDRA-13155) Allow tracing at the CFS level


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

Sam Overton updated CASSANDRA-13155:

Description: If we have a misbehaving host, then it would be useful to 
enable sampled tracing at the CFS layer on just that host so that we can 
investigate queries landing on that replica, rather than just queries passing 
through as a coordinator as is currently possible.  (was: If we have a 
misbehaving host, then it would
be useful to enable sampled tracing at the CFS layer on just that host so that
we can investigate queries landing on that replica, rather than just queries
passing through as a coordinator as is currently possible.)

> Allow tracing at the CFS level
> --
>
> Key: CASSANDRA-13155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13155
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Sam Overton
>Assignee: Sam Overton
>
> If we have a misbehaving host, then it would be useful to enable sampled 
> tracing at the CFS layer on just that host so that we can investigate queries 
> landing on that replica, rather than just queries passing through as a 
> coordinator as is currently possible.



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

[jira] [Updated] (CASSANDRA-13154) Add trace_probability as a CF level property


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

Sam Overton updated CASSANDRA-13154:

Description: 
Include trace_probability as a CF level property, so sampled tracing can be 
enabled on a per-CF basis, cluster-wide, by changing the CF property.



  was:
Include trace_probability as a CF level property, so sampled tracing can be
enabled on a per-CF basis, cluster-wide, by changing the CF property.




> Add trace_probability as a CF level property
> 
>
> Key: CASSANDRA-13154
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13154
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Observability
>Reporter: Sam Overton
>Assignee: Sam Overton
>
> Include trace_probability as a CF level property, so sampled tracing can be 
> enabled on a per-CF basis, cluster-wide, by changing the CF property.



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

[jira] [Updated] (CASSANDRA-13156) Introduce an interface to tracing for determining whether a query should be traced


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

Sam Overton updated CASSANDRA-13156:

Description: This is a similar idea to CASSANDRA-9193 but following the 
same pattern that we have for IAuthenticator, IEndpointSnitch, 
ConfigurationLoader et al. where the intention is that useful default 
implementations are provided, but abstracted in such a way that custom 
implementations can be written for deployments where a specific type of 
functionality is required. This would then allow solutions such as 
CASSANDRA-11012 without any specific support needing to be written in 
Cassandra.  (was: This is a similar idea to CASSANDRA-9193
but following the same pattern that we have for IAuthenticator,
IEndpointSnitch, ConfigurationLoader et al. where the intention is that useful
default implementations are provided, but abstracted in such a way that custom
implementations can be written for deployments where a specific type of
functionality is required. This would then allow solutions such as
CASSANDRA-11012 without any specific support needing to be written in
Cassandra.)

> Introduce an interface to tracing for determining whether a query should be 
> traced
> --
>
> Key: CASSANDRA-13156
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13156
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Observability
>Reporter: Sam Overton
>Assignee: Sam Overton
>
> This is a similar idea to CASSANDRA-9193 but following the same pattern that 
> we have for IAuthenticator, IEndpointSnitch, ConfigurationLoader et al. where 
> the intention is that useful default implementations are provided, but 
> abstracted in such a way that custom implementations can be written for 
> deployments where a specific type of functionality is required. This would 
> then allow solutions such as CASSANDRA-11012 without any specific support 
> needing to be written in Cassandra.



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

[jira] [Created] (CASSANDRA-13156) Introduce an interface to tracing for determining whether a query should be traced

Sam Overton created CASSANDRA-13156:
---

 Summary: Introduce an interface to tracing for determining whether 
a query should be traced
 Key: CASSANDRA-13156
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13156
 Project: Cassandra
  Issue Type: New Feature
  Components: Observability
Reporter: Sam Overton
Assignee: Sam Overton


This is a similar idea to CASSANDRA-9193
but following the same pattern that we have for IAuthenticator,
IEndpointSnitch, ConfigurationLoader et al. where the intention is that useful
default implementations are provided, but abstracted in such a way that custom
implementations can be written for deployments where a specific type of
functionality is required. This would then allow solutions such as
CASSANDRA-11012 without any specific support needing to be written in
Cassandra.



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

[jira] [Created] (CASSANDRA-13155) Allow tracing at the CFS level

Sam Overton created CASSANDRA-13155:
---

 Summary: Allow tracing at the CFS level
 Key: CASSANDRA-13155
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13155
 Project: Cassandra
  Issue Type: Improvement
  Components: Observability
Reporter: Sam Overton
Assignee: Sam Overton


If we have a misbehaving host, then it would
be useful to enable sampled tracing at the CFS layer on just that host so that
we can investigate queries landing on that replica, rather than just queries
passing through as a coordinator as is currently possible.



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

[jira] [Created] (CASSANDRA-13154) Add trace_probability as a CF level property

Sam Overton created CASSANDRA-13154:
---

 Summary: Add trace_probability as a CF level property
 Key: CASSANDRA-13154
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13154
 Project: Cassandra
  Issue Type: New Feature
  Components: Observability
Reporter: Sam Overton
Assignee: Sam Overton


Include trace_probability as a CF level property, so sampled tracing can be
enabled on a per-CF basis, cluster-wide, by changing the CF property.





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

[jira] [Commented] (CASSANDRA-13114) 3.0.x: update netty

2017-01-25 Thread Norman Maurer (JIRA)


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

Norman Maurer commented on CASSANDRA-13114:
---

[~spo...@gmail.com] nope just upgrade to 4.0.43. FTW ;) That said we will 
release 4.0.44.Final end of this week or next week latest.

> 3.0.x: update netty
> ---
>
> Key: CASSANDRA-13114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13114
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van der Woerdt
> Attachments: 13114_netty-4.0.43_2.x-3.0.patch, 
> 13114_netty-4.0.43_3.11.patch
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-12032 updated netty for 
> Cassandra 3.8, but this wasn't backported. Netty 4.0.23, which ships with 
> Cassandra 3.0.x, has some serious bugs around memory handling for SSL 
> connections.
> It would be nice if both were updated to 4.0.42, a version released this year.
> 4.0.23 makes it impossible for me to run SSL, because nodes run out of memory 
> every ~30 minutes. This was fixed in 4.0.27.



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

[jira] [Commented] (CASSANDRA-9988) Introduce leaf-only iterator

2017-01-25 Thread Benedict (JIRA)


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

Benedict commented on CASSANDRA-9988:
-

Sorry Jay, not anytime soon.  I no longer work actively on the project and am 
rather busy; you should look for one of the full-time contributors to lend a 
hand getting this merged.

I took a quick peek, and I'll note (without commenting on the quality of the 
code itself) for any potential reviewers out there that the patch looks to be 
in a good shape generally, so I shouldn't expect it to be an onerous review.

I did notice that in LeafBtree... line 108-109 are probably redundant, assuming 
line 106 does its job

> Introduce leaf-only iterator
> 
>
> Key: CASSANDRA-9988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9988
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
>  Labels: patch
> Fix For: 4.0
>
> Attachments: 9988-trunk-new.txt, trunk-9988.txt
>
>
> In many cases we have small btrees, small enough to fit in a single leaf 
> page. In this case it _may_ be more efficient to specialise our iterator.



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

[jira] [Commented] (CASSANDRA-9988) Introduce leaf-only iterator


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

Jay Zhuang commented on CASSANDRA-9988:
---

[~benedict] would you please review the patch?

> Introduce leaf-only iterator
> 
>
> Key: CASSANDRA-9988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9988
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
>  Labels: patch
> Fix For: 4.0
>
> Attachments: 9988-trunk-new.txt, trunk-9988.txt
>
>
> In many cases we have small btrees, small enough to fit in a single leaf 
> page. In this case it _may_ be more efficient to specialise our iterator.



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

[jira] [Comment Edited] (CASSANDRA-12510) Disallow decommission when number of replicas will drop below configured RF

2017-01-25 Thread Nick Bailey (JIRA)


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

Nick Bailey edited comment on CASSANDRA-12510 at 1/25/17 5:40 PM:
--

Removing the no argument version of decommission here was a breaking API change 
that we should have done in a major release (which tick tock makes weird but 
still). This is more of an informational comment than anything because I'm not 
sure it's worth fixing now, but just a reminder to keep an eye out for breaking 
JMX changes.

*edit: should have been done in a major release and probably marked as 
deprecated first.


was (Author: nickmbailey):
Removing the no argument version of decommission here was a breaking API change 
that we should have done in a major release (which tick tock makes weird but 
still). This is more of an informational comment than anything because I'm not 
sure it's worth fixing now, but just a reminder to keep an eye out for breaking 
JMX changes.

> Disallow decommission when number of replicas will drop below configured RF
> ---
>
> Key: CASSANDRA-12510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12510
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Streaming and Messaging
> Environment: C* version 3.3
>Reporter: Atin Sood
>Assignee: Kurt Greaves
>Priority: Minor
>  Labels: lhf
> Fix For: 3.12
>
> Attachments: 12510-3.x.patch, 12510-3.x-v2.patch
>
>
> Steps to replicate :
> - Create a 3 node cluster in DC1 and create a keyspace test_keyspace with 
> table test_table with replication strategy NetworkTopologyStrategy , DC1=3 . 
> Populate some data into this table.
> - Add 5 more nodes to this cluster, but in DC2. Also do not alter the 
> keyspace to add the new DC2 to replication (this is intentional and the 
> reason why the bug shows up). So the desc keyspace should still list 
> NetworkTopologyStrategy with DC1=3 as RF
> - As expected, this will now be a 8 node cluster with 3 nodes in DC1 and 5 in 
> DC2
> - Now start decommissioning the nodes in DC1. Note that the decommission runs 
> fine on all the 3 nodes, but since the new nodes are in DC2 and the RF for 
> keyspace is restricted to DC1, the new 5 nodes won't get any data.
> - You will now end with the 5 node cluster which has no data from the 
> decommissioned 3 nodes and hence ending up in data loss
> I do understand that this problem could have been avoided if we perform an 
> alter stmt and add DC2 replication before adding the 5 nodes. But the fact 
> that decommission ran fine on the 3 nodes on DC1 without complaining that 
> there were no nodes to stream its data seems a little discomforting. 



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

[jira] [Commented] (CASSANDRA-12510) Disallow decommission when number of replicas will drop below configured RF

2017-01-25 Thread Nick Bailey (JIRA)


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

Nick Bailey commented on CASSANDRA-12510:
-

Removing the no argument version of decommission here was a breaking API change 
that we should have done in a major release (which tick tock makes weird but 
still). This is more of an informational comment than anything because I'm not 
sure it's worth fixing now, but just a reminder to keep an eye out for breaking 
JMX changes.

> Disallow decommission when number of replicas will drop below configured RF
> ---
>
> Key: CASSANDRA-12510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12510
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Streaming and Messaging
> Environment: C* version 3.3
>Reporter: Atin Sood
>Assignee: Kurt Greaves
>Priority: Minor
>  Labels: lhf
> Fix For: 3.12
>
> Attachments: 12510-3.x.patch, 12510-3.x-v2.patch
>
>
> Steps to replicate :
> - Create a 3 node cluster in DC1 and create a keyspace test_keyspace with 
> table test_table with replication strategy NetworkTopologyStrategy , DC1=3 . 
> Populate some data into this table.
> - Add 5 more nodes to this cluster, but in DC2. Also do not alter the 
> keyspace to add the new DC2 to replication (this is intentional and the 
> reason why the bug shows up). So the desc keyspace should still list 
> NetworkTopologyStrategy with DC1=3 as RF
> - As expected, this will now be a 8 node cluster with 3 nodes in DC1 and 5 in 
> DC2
> - Now start decommissioning the nodes in DC1. Note that the decommission runs 
> fine on all the 3 nodes, but since the new nodes are in DC2 and the RF for 
> keyspace is restricted to DC1, the new 5 nodes won't get any data.
> - You will now end with the 5 node cluster which has no data from the 
> decommissioned 3 nodes and hence ending up in data loss
> I do understand that this problem could have been avoided if we perform an 
> alter stmt and add DC2 replication before adding the 5 nodes. But the fact 
> that decommission ran fine on the 3 nodes on DC1 without complaining that 
> there were no nodes to stream its data seems a little discomforting. 



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

[jira] [Updated] (CASSANDRA-13135) Forced termination of repair session leaves repair jobs running

2017-01-25 Thread Joshua McKenzie (JIRA)


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

Joshua McKenzie updated CASSANDRA-13135:

Reviewer: Joel Knighton

> Forced termination of repair session leaves repair jobs running
> ---
>
> Key: CASSANDRA-13135
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13135
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> Forced termination of repair session (by failure detector or jmx) keeps 
> repair jobs running that the session created after session is terminated.
> This can cause increase in repair time by those unnecessary works left in 
> repair job queue.



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

[jira] [Commented] (CASSANDRA-10689) java.lang.OutOfMemoryError: Direct buffer memory

2017-01-25 Thread Jacob Willoughby (JIRA)


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

Jacob Willoughby commented on CASSANDRA-10689:
--

Maybe unrelated, but these are in the log as well when it happens:

{noformat}
system.log.1.zip:ERROR [Reference-Reaper:1] 2017-01-24 19:45:25,314 
Ref.java:207 - LEAK DETECTED: a reference 
(org.apache.cassandra.utils.concurrent.Ref$State@3f6a149a) to class 
org.apache.cassandra.io.util.ChannelProxy$Cleanup@1636104455:/data/cassandra/data/Objects/Objects-11baea008ccf11e6be00d321fe82b612/lb-97928-big-Data.db
 was not released before the reference was garbage collected
system.log.1.zip:ERROR [Reference-Reaper:1] 2017-01-24 19:45:25,314 
Ref.java:207 - LEAK DETECTED: a reference 
(org.apache.cassandra.utils.concurrent.Ref$State@7d709f32) to class 
org.apache.cassandra.io.util.ChannelProxy$Cleanup@414312072:/data/cassandra/data/Objects/Objects-11baea008ccf11e6be00d321fe82b612/lb-97928-big-Index.db
 was not released before the reference was garbage collected
system.log.1.zip:ERROR [Reference-Reaper:1] 2017-01-24 19:45:25,314 
Ref.java:207 - LEAK DETECTED: a reference 
(org.apache.cassandra.utils.concurrent.Ref$State@7790ffc0) to class 
org.apache.cassandra.io.util.ChannelProxy$Cleanup@823819508:/data/cassandra/data/Objects/Objects-11baea008ccf11e6be00d321fe82b612/lb-101661-big-Data.db
 was not released before the reference was garbage collected
{noformat}

> java.lang.OutOfMemoryError: Direct buffer memory
> 
>
> Key: CASSANDRA-10689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10689
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mlowicki
>
> {code}
> ERROR [SharedPool-Worker-63] 2015-11-11 17:53:16,161 
> JVMStabilityInspector.java:117 - JVM state determined to be unstable.  
> Exiting forcefully due to:
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:658) ~[na:1.7.0_80]
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123) 
> ~[na:1.7.0_80]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:306) 
> ~[na:1.7.0_80]
> at sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:174) 
> ~[na:1.7.0_80]
> at sun.nio.ch.IOUtil.read(IOUtil.java:195) ~[na:1.7.0_80]
> at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:149) 
> ~[na:1.7.0_80]
> at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.decompressChunk(CompressedRandomAccessReader.java:104)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.reBuffer(CompressedRandomAccessReader.java:81)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]  
> at 
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:310)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.io.util.PoolingSegmentedFile.getSegment(PoolingSegmentedFile.java:64)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.io.sstable.SSTableReader.getFileDataInput(SSTableReader.java:1894)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.columniterator.IndexedSliceReader.setToRowStart(IndexedSliceReader.java:107)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.columniterator.IndexedSliceReader.(IndexedSliceReader.java:83)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.createReader(SSTableSliceIterator.java:65)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.(SSTableSliceIterator.java:42)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:246)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:62)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:270)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:62)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1994)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1837)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:353) 
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
>

[jira] [Updated] (CASSANDRA-12735) org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out

2017-01-25 Thread Sam Tunnicliffe (JIRA)


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

Sam Tunnicliffe updated CASSANDRA-12735:

Assignee: (was: Sam Tunnicliffe)

> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out
> -
>
> Key: CASSANDRA-12735
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12735
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Core
> Environment: Python 2.7.11, Datastax Cassandra 3.7.0  
>Reporter: Rajesh Radhakrishnan
> Fix For: 3.7
>
>
> We got a cluster of two nodes running Cassandra.3.7.0 and using client 
> running Python 2.7.11 injecting lot of data from maybe 100 or so jobs. 
> --
> Cache setting can be seen from system.log:
> INFO  [main] 2016-09-30 15:12:50,002 AuthCache.java:172 - (Re)initializing 
> CredentialsCache (validity period/update interval/max entries) 
> (2000/2000/1000)
> INFO  [SharedPool-Worker-1] 2016-09-30 15:15:09,561 AuthCache.java:172 - 
> (Re)initializing PermissionsCache (validity period/update interval/max 
> entries) (1/1/1000)
> INFO  [SharedPool-Worker-1] 2016-09-30 15:15:24,319 AuthCache.java:172 - 
> (Re)initializing RolesCache (validity period/update interval/max entries) 
> (5000/5000/1000)
> ===
> But I am getting the following exception :
> ERROR [SharedPool-Worker-90] 2016-09-30 15:17:20,883 ErrorMessage.java:338 - 
> Unexpected exception during request
> com.google.common.util.concurrent.UncheckedExecutionException: 
> com.google.common.util.concurrent.UncheckedExecutionException: 
> java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 0 responses.
>   at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203) 
> ~[guava-18.0.jar:na]
>   at com.google.common.cache.LocalCache.get(LocalCache.java:3937) 
> ~[guava-18.0.jar:na]
>   at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3941) 
> ~[guava-18.0.jar:na]
>   at 
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4824)
>  ~[guava-18.0.jar:na]
>   at org.apache.cassandra.auth.AuthCache.get(AuthCache.java:108) 
> ~[apache-cassandra-3.7.0.jar:3.7.0]
>   at 
> org.apache.cassandra.auth.PermissionsCache.getPermissions(PermissionsCache.java:45)
>  ~[apache-cassandra-3.7.0.jar:3.7.0]
>   at 
> org.apache.cassandra.auth.AuthenticatedUser.getPermissions(AuthenticatedUser.java:104)
>  ~[apache-cassandra-3.7.0.jar:3.7.0]
>   at 
> org.apache.cassandra.service.ClientState.authorize(ClientState.java:375) 
> ~[apache-cassandra-3.7.0.jar:3.7.0]
>   at 
> org.apache.cassandra.service.ClientState.checkPermissionOnResourceChain(ClientState.java:308)
>  ~[apache-cassandra-3.7.0.jar:3.7.0]
>   at 
> org.apache.cassandra.service.ClientState.ensureHasPermission(ClientState.java:285)
>  ~[apache-cassandra-3.7.0.jar:3.7.0]
>   at 
> org.apache.cassandra.service.ClientState.hasAccess(ClientState.java:272) 
> ~[apache-cassandra-3.7.0.jar:3.7.0]
>   at 
> org.apache.cassandra.service.ClientState.hasColumnFamilyAccess(ClientState.java:256)
>  ~[apache-cassandra-3.7.0.jar:3.7.0]
>   at 
> org.apache.cassandra.cql3.statements.ModificationStatement.checkAccess(ModificationStatement.java:211)
>  ~[apache-cassandra-3.7.0.jar:3.7.0]
>   at 
> org.apache.cassandra.cql3.statements.BatchStatement.checkAccess(BatchStatement.java:137)
>  ~[apache-cassandra-3.7.0.jar:3.7.0]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processBatch(QueryProcessor.java:502)
>  ~[apache-cassandra-3.7.0.jar:3.7.0]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processBatch(QueryProcessor.java:495)
>  ~[apache-cassandra-3.7.0.jar:3.7.0]
>   at 
> org.apache.cassandra.transport.messages.BatchMessage.execute(BatchMessage.java:217)
>  ~[apache-cassandra-3.7.0.jar:3.7.0]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
>  [apache-cassandra-3.7.0.jar:3.7.0]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
>  [apache-cassandra-3.7.0.jar:3.7.0]
>   at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
>  [netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
>

[jira] [Updated] (CASSANDRA-13153) Reappeared Data when Mixing Incremental and Full Repairs

2017-01-25 Thread Amanda Debrot (JIRA)

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

Amanda Debrot updated CASSANDRA-13153:
--
Description:
This happens for both LeveledCompactionStrategy and
SizeTieredCompactionStrategy. I've only tested it on Cassandra version 2.2 but
it most likely also affects all Cassandra versions with incremental repair -
like 2.1 and 3.0.

When mixing incremental and full repairs, there are a few scenarios where the
Data SSTable is marked as unrepaired and the Tombstone SSTable is marked as
repaired. Then if it is past gc_grace, and the tombstone and data has been
compacted out on other replicas, the next incremental repair will push the Data
to other replicas without the tombstone.

Simplified scenario:
3 node cluster with RF=3
Intial config:
Node 1 has data and tombstone in separate SSTables.
Node 2 has data and no tombstone.
Node 3 has data and tombstone in separate SSTables.

Incremental repair (nodetool repair -pr) is run every day so now we have
tombstone on each node.
Some minor compactions have happened since so data and tombstone get merged to
1 SSTable on Nodes 1 and 3.
Node 1 had a minor compaction that merged data with tombstone. 1
SSTable with tombstone.
Node 2 has data and tombstone in separate SSTables.
Node 3 had a minor compaction that merged data with tombstone. 1
SSTable with tombstone.

Incremental repairs keep running every day.
Full repairs run weekly (nodetool repair -full -pr).
Now there are 2 scenarios where the Data SSTable will get marked as
"Unrepaired" while Tombstone SSTable will get marked as "Repaired".

Scenario 1:
Since the Data and Tombstone SSTable have been marked as "Repaired" and
anticompacted, they have had minor compactions with other SSTables containing
keys from other ranges. During full repair, if the last node to run it doesn't
own this particular key in it's partitioner range, the Data and Tombstone
SSTable will get anticompacted and marked as "Unrepaired". Now in the next
incremental repair, if the Data SSTable is involved in a minor compaction
during the repair but the Tombstone SSTable is not, the resulting compacted
SSTable will be marked "Unrepaired" and Tombstone SSTable is marked "Repaired".

Scenario 2:
Only the Data SSTable had minor compaction with other SSTables
containing keys from other ranges after being marked as "Repaired". The
Tombstone SSTable was never involved in a minor compaction so therefore all
keys in that SSTable belong to 1 particular partitioner range. During full
repair, if the last node to run it doesn't own this particular key in it's
partitioner range, the Data SSTable will get anticompacted and marked as
"Unrepaired". The Tombstone SSTable stays marked as Repaired.

Then it’s past gc_grace. Since Node’s #1 and #3 only have 1 SSTable for that
key, the tombstone will get compacted out.
Node 1 has nothing.
Node 2 has data (in unrepaired SSTable) and tombstone (in repaired
SSTable) in separate SSTables.
Node 3 has nothing.

Now when the next incremental repair runs, it will only use the Data SSTable to
build the merkle tree since the tombstone SSTable is flagged as repaired and
data SSTable is marked as unrepaired. And the data will get repaired against
the other two nodes.
Node 1 has data.
Node 2 has data and tombstone in separate SSTables and levels.
Node 3 has data.
If a read request hits Node 1 and 3, it will return data. If it hits 1 and 2,
or 2 and 3, however, it would return no data.

Tested this with single range tokens for simplicity.

was:
This happens for both LeveledCompactionStrategy and
SizeTieredCompactionStrategy. I've only tested it on Cassandra version 2.2 but
it most likely also affects all Cassandra versions with incremental repair -
like 2.1 and 3.0.

Simplified scenario:
3 node cluster with RF=3
Intial config:
Node 1 has data and tombstone in separate SSTables.
Node 2 has data and no tombstone.
Node 3 has data and tombstone in separate SSTables.

[jira] [Updated] (CASSANDRA-13153) Reappeared Data when Mixing Incremental and Full Repairs

2017-01-25 Thread Amanda Debrot (JIRA)

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

Simplified scenario:
3 node cluster with RF=3
Intial config:
Node 1 has data and tombstone in separate SSTables.
Node 2 has data and no tombstone.
Node 3 has data and tombstone in separate SSTables.

Now when the next incremental repair runs, it will only use the Data SSTable to
build the merkle tree since the tombstone SSTable is flagged as repaired and
data SSTable is marked as unrepaired. And the data will get repaired against
the other two nodes.
Node 1 has data.
Node 2 has data and tombstone in separate SSTables.
Node 3 has data.
If a read request hits Node 1 and 3, it will return data. If it hits 1 and 2,
or 2 and 3, however, it would return no data.

Tested this with single range tokens for simplicity.

Simplified scenario:
3 node cluster with RF=3
Intial config:
Node 1 has data and tombstone in separate SSTables.
Node 2 has data and no tombstone.
Node 3 has data and tombstone in separate SSTables.

[jira] [Created] (CASSANDRA-13153) Reappeared Data when Mixing Incremental and Full Repairs

2017-01-25 Thread Amanda Debrot (JIRA)

Amanda Debrot created CASSANDRA-13153:
-

 Summary: Reappeared Data when Mixing Incremental and Full Repairs
 Key: CASSANDRA-13153
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13153
 Project: Cassandra
  Issue Type: Bug
  Components: Compaction, Tools
 Environment: Apache Cassandra 2.2
Reporter: Amanda Debrot
 Attachments: log-Reappeared-Data.txt, 
Step-by-Step-Simulate-Reappeared-Data.txt

This happens for both LeveledCompactionStrategy and 
SizeTieredCompactionStrategy.  I've only tested it on Cassandra version 2.2 but 
it most likely also affects all Cassandra versions with incremental repair - 
like 2.1 and 3.0.

When mixing incremental and full repairs, there are a few scenarios where the 
Data SSTable is marked as unrepaired and the Tombstone SSTable is marked as 
repaired.  Then if it is past gc_grace, and the tombstone and data has been 
compacted out on other replicas, the next incremental repair will push the Data 
to other replicas without the tombstone.

Simplified scenario:
3 node cluster with RF=3
Intial config:
Node 1 has data and tombstone in separate SSTables.
Node 2 has data and no tombstone.
Node 3 has data and tombstone in separate SSTables.

Incremental repair (nodetool repair -pr) is run every day so now we have 
tombstone on each node.
Some minor compactions have happened since so data and tombstone get merged to 
1 SSTable on Nodes 1 and 3.
Node 1 had a minor compaction that merged data with tombstone. 1 
SSTable with tombstone.
Node 2 has data and tombstone in separate SSTables.
Node 3 had a minor compaction that merged data with tombstone. 1 
SSTable with tombstone.

Incremental repairs keep running every day.
Full repairs run weekly (nodetool repair -full -pr). 
Now there are 2 scenarios where the Data SSTable will get marked as 
"Unrepaired" while Tombstone SSTable will get marked as "Repaired".

Scenario 1:
Since the Data and Tombstone SSTable have been marked as "Repaired" and 
anticompacted, they have had minor compactions with other SSTables containing 
keys from other ranges.  During full repair, if the last node to run it doesn't 
own this particular key in it's partitioner range, the Data and Tombstone 
SSTable will get anticompacted and marked as "Unrepaired".  Now in the next 
incremental repair, if the Data SSTable is involved in a minor compaction 
during the repair but the Tombstone SSTable is not, the resulting compacted 
SSTable will be marked "Unrepaired" and Tombstone SSTable is marked "Repaired".

Scenario 2:
Only the Data SSTable had minor compaction with other SSTables 
containing keys from other ranges after being marked as "Repaired".  The 
Tombstone SSTable was never involved in a minor compaction so therefore all 
keys in that SSTable belong to 1 particular partitioner range. During full 
repair, if the last node to run it doesn't own this particular key in it's 
partitioner range, the Data SSTable will get anticompacted and marked as 
"Unrepaired".   The Tombstone SSTable stays marked as Repaired.

Then it’s past gc_grace.  Since Node’s #1 and #3 only have 1 SSTable for that 
key, the tombstone will get compacted out.
Node 1 has nothing.
Node 2 has data (in unrepaired SSTable) and tombstone (in repaired 
SSTable) in separate SSTables and levels.
Node 3 has nothing.

Now when the next incremental repair runs, it will only use the Data SSTable to 
build the merkle tree since the tombstone SSTable is flagged as repaired and 
data SSTable is marked as unrepaired.  And the data will get repaired against 
the other two nodes.
Node 1 has data.
Node 2 has data and tombstone in separate SSTables and levels.
Node 3 has data.
If a read request hits Node 1 and 3, it will return data.  If it hits 1 and 2, 
or 2 and 3, however, it would return no data.

Tested this with single range tokens for simplicity.




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

[jira] [Updated] (CASSANDRA-13114) 3.0.x: update netty


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

Stefan Podkowinski updated CASSANDRA-13114:
---
Attachment: 13114_netty-4.0.43_3.11.patch
13114_netty-4.0.43_2.x-3.0.patch

> 3.0.x: update netty
> ---
>
> Key: CASSANDRA-13114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13114
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van der Woerdt
> Attachments: 13114_netty-4.0.43_2.x-3.0.patch, 
> 13114_netty-4.0.43_3.11.patch
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-12032 updated netty for 
> Cassandra 3.8, but this wasn't backported. Netty 4.0.23, which ships with 
> Cassandra 3.0.x, has some serious bugs around memory handling for SSL 
> connections.
> It would be nice if both were updated to 4.0.42, a version released this year.
> 4.0.23 makes it impossible for me to run SSL, because nodes run out of memory 
> every ~30 minutes. This was fixed in 4.0.27.



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

[jira] [Commented] (CASSANDRA-13114) 3.0.x: update netty


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

Stefan Podkowinski commented on CASSANDRA-13114:


I admit that I don't really have an opinion on using any particular version. 
Any reasons not to go with the latest stable 4.0 release? 

Let's try a CI run using 4.0.43:

||2.1||2.2||3.0||3.11||trunk||
|[branch|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-13114-2.1]|[branch|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-13114-2.2]|[branch|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-13114-3.0]|[branch|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-13114-3.11]|[branch|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-13114-trunk]|
|[dtest|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-13114-2.1-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-13114-2.2-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-13114-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-13114-3.11-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-13114-trunk-dtest/]|
|[testall|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-13114-2.1-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-13114-2.2-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-13114-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-13114-3.11-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-13114-trunk-testall/]|


[~jasobrown], you have any strong preference for netty releases and gossip 2.0?

[~norman], anything to double check or look out for from our side while 
updating from 4.0.23 -> 4.0.43?


> 3.0.x: update netty
> ---
>
> Key: CASSANDRA-13114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13114
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van der Woerdt
>
> https://issues.apache.org/jira/browse/CASSANDRA-12032 updated netty for 
> Cassandra 3.8, but this wasn't backported. Netty 4.0.23, which ships with 
> Cassandra 3.0.x, has some serious bugs around memory handling for SSL 
> connections.
> It would be nice if both were updated to 4.0.42, a version released this year.
> 4.0.23 makes it impossible for me to run SSL, because nodes run out of memory 
> every ~30 minutes. This was fixed in 4.0.27.



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

[jira] [Assigned] (CASSANDRA-13152) UPDATE on counter columns with empty list as argument in IN disables cluster


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

Benjamin Lerer reassigned CASSANDRA-13152:
--

Assignee: Benjamin Lerer

> UPDATE on counter columns with empty list as argument in IN disables cluster
> 
>
> Key: CASSANDRA-13152
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13152
> Project: Cassandra
>  Issue Type: Bug
> Environment: Linux Ubuntu 16
> 3 Virtual machines
>Reporter: jorge collinet
>Assignee: Benjamin Lerer
> Fix For: 3.3
>
>
> On a 3 node cluster
> with this table (replication factor of 2):
> CREATE TABLE tracking.item_items_rec_history (
>   reference_id bigint,
>   country text,
>   portal text,
>   app_name text,
>   recommended_id bigint,
>   counter counter,
>   PRIMARY KEY (reference_id, country, portal, app_name, recommended_id)
> );
> If I execute 
> UPDATE user_items_rec_history 
> SET counter = counter + 1 
> WHERE reference_id = 1 AND country = '' AND portal = '' AND app_name = '' AND 
> recommended_id IN ();
> Take note that the IN is empty
> The cluster starts to malfunction and responds a lot of timeouts to any query.
> After resetting some of the nodes, the cluster starts to function normally 
> again.



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

[jira] [Commented] (CASSANDRA-13114) 3.0.x: update netty

2017-01-25 Thread Tom van der Woerdt (JIRA)


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

Tom van der Woerdt commented on CASSANDRA-13114:


4.0.39 has been tested pretty well with 3.x by now, so it should be relatively 
safe (much safer than, say, 3.0.36, which not only hasn't been tested, but also 
won't get the attention that 3.0.39 would get if it is used by both 3.0 and 
3.x). Definitely don't pick 4.1!

As for setting MaxDirectMemorySize: it was set to 20GB when I filed this 
ticket. No luck :)

Side-note: CASSANDRA-13126 is a related issue, on clusters with SSL enabled 
even non SSL clients may be impacted due to this netty issue.

> 3.0.x: update netty
> ---
>
> Key: CASSANDRA-13114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13114
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van der Woerdt
>
> https://issues.apache.org/jira/browse/CASSANDRA-12032 updated netty for 
> Cassandra 3.8, but this wasn't backported. Netty 4.0.23, which ships with 
> Cassandra 3.0.x, has some serious bugs around memory handling for SSL 
> connections.
> It would be nice if both were updated to 4.0.42, a version released this year.
> 4.0.23 makes it impossible for me to run SSL, because nodes run out of memory 
> every ~30 minutes. This was fixed in 4.0.27.



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

[jira] [Updated] (CASSANDRA-13152) UPDATE on counter columns with empty list as argument in IN disables cluster

2017-01-25 Thread jorge collinet (JIRA)


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

jorge collinet updated CASSANDRA-13152:
---
Description: 
On a 3 node cluster
with this table (replication factor of 2):
CREATE TABLE tracking.item_items_rec_history (
reference_id bigint,
country text,
portal text,
app_name text,
recommended_id bigint,
counter counter,
PRIMARY KEY (reference_id, country, portal, app_name, recommended_id)
);

If I execute 
UPDATE user_items_rec_history 
SET counter = counter + 1 
WHERE reference_id = 1 AND country = '' AND portal = '' AND app_name = '' AND 
recommended_id IN ();

Take note that the IN is empty

The cluster starts to malfunction and responds a lot of timeouts to any query.

After resetting some of the nodes, the cluster starts to function normally 
again.


  was:
On a 3 node cluster
with this table (replication factor of 2):
CREATE TABLE tracking.item_items_rec_history (
reference_id bigint,
country text,
portal text,
app_name text,
recommended_id bigint,
counter counter,
PRIMARY KEY (reference_id, country, portal, app_name, recommended_id)
);

If I execute 
UPDATE user_items_rec_history 
SET counter = counter + 1 
WHERE reference_id = 1 AND country = '' AND portal = '' AND app_name = '' AND 
recommended_id IN ();

The cluster starts to malfunction and responds a lot of timeouts to any query.

After resetting some of the nodes, the cluster starts to function normally 
again.



> UPDATE on counter columns with empty list as argument in IN disables cluster
> 
>
> Key: CASSANDRA-13152
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13152
> Project: Cassandra
>  Issue Type: Bug
> Environment: Linux Ubuntu 16
> 3 Virtual machines
>Reporter: jorge collinet
> Fix For: 3.3
>
>
> On a 3 node cluster
> with this table (replication factor of 2):
> CREATE TABLE tracking.item_items_rec_history (
>   reference_id bigint,
>   country text,
>   portal text,
>   app_name text,
>   recommended_id bigint,
>   counter counter,
>   PRIMARY KEY (reference_id, country, portal, app_name, recommended_id)
> );
> If I execute 
> UPDATE user_items_rec_history 
> SET counter = counter + 1 
> WHERE reference_id = 1 AND country = '' AND portal = '' AND app_name = '' AND 
> recommended_id IN ();
> Take note that the IN is empty
> The cluster starts to malfunction and responds a lot of timeouts to any query.
> After resetting some of the nodes, the cluster starts to function normally 
> again.



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

[jira] [Commented] (CASSANDRA-13025) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x.static_columns_with_distinct_test

2017-01-25 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-13025:
--

Thanks, it's now scheduled 
[here|http://cassci.datastax.com/job/pcmanus-13025-trunk-upgrade-upgrade/].

> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x.static_columns_with_distinct_test
> 
>
> Key: CASSANDRA-13025
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13025
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>Assignee: Sylvain Lebresne
>Priority: Critical
>  Labels: dtest, test-failure
> Fix For: 3.10, 3.0.x
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.X_dtest_upgrade/28/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x/static_columns_with_distinct_test
> {code}
> Error Message
> 
> {code}{code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools/decorators.py", line 46, in 
> wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/upgrade_tests/cql_tests.py", line 
> 4010, in static_columns_with_distinct_test
> rows = list(cursor.execute("SELECT DISTINCT k, s1 FROM test2"))
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 1998, in execute
> return self.execute_async(query, parameters, trace, custom_payload, 
> timeout, execution_profile, paging_state).result()
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 3784, in result
> raise self._final_exception
> {code}{code}
> Standard Output
> http://git-wip-us.apache.org/repos/asf/cassandra.git 
> git:7eac22dd41cb09e6d64fb5ac48b2cca3c8840cc8
> Unexpected error in node2 log, error: 
> ERROR [Native-Transport-Requests-2] 2016-12-08 03:20:04,861 Message.java:617 
> - Unexpected exception during request; channel = [id: 0xf4c13f2c, 
> L:/127.0.0.2:9042 - R:/127.0.0.1:52112]
> java.io.IOError: java.io.IOException: Corrupt empty row found in unfiltered 
> partition
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:224)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:212)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:779)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:741)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:408)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:273)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:232)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:219) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:204) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
>

[jira] [Created] (CASSANDRA-13152) UPDATE on counter columns with empty list as argument in IN disables cluster

2017-01-25 Thread jorge collinet (JIRA)

jorge collinet created CASSANDRA-13152:
--

 Summary: UPDATE on counter columns with empty list as argument in 
IN disables cluster
 Key: CASSANDRA-13152
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13152
 Project: Cassandra
  Issue Type: Bug
 Environment: Linux Ubuntu 16
3 Virtual machines
Reporter: jorge collinet
 Fix For: 3.3


On a 3 node cluster
with this table (replication factor of 2):
CREATE TABLE tracking.item_items_rec_history (
reference_id bigint,
country text,
portal text,
app_name text,
recommended_id bigint,
counter counter,
PRIMARY KEY (reference_id, country, portal, app_name, recommended_id)
);

If I execute 
UPDATE user_items_rec_history 
SET counter = counter + 1 
WHERE reference_id = 1 AND country = '' AND portal = '' AND app_name = '' AND 
recommended_id IN ();

The cluster starts to malfunction and responds a lot of timeouts to any query.

After resetting some of the nodes, the cluster starts to function normally 
again.




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

[jira] [Commented] (CASSANDRA-13114) 3.0.x: update netty

2017-01-25 Thread Robert Stupp (JIRA)


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

Robert Stupp commented on CASSANDRA-13114:
--

No objections regarding a _minor_ netty upgrade, if that solves real SSL issues 
/ an existing bug.  I'd just be very careful with dependency changes since 
4.0.37 introduced a couple of issues.
Would setting {{-XX:MaxDirectMemorySize=SomeBigValue}} help in this case?
However, I do object introducing the new stuff from CASSANDRA-12032 in 2.2 or 
3.0, because it is a new thing, which is disabled by default in 3.x.


> 3.0.x: update netty
> ---
>
> Key: CASSANDRA-13114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13114
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van der Woerdt
>
> https://issues.apache.org/jira/browse/CASSANDRA-12032 updated netty for 
> Cassandra 3.8, but this wasn't backported. Netty 4.0.23, which ships with 
> Cassandra 3.0.x, has some serious bugs around memory handling for SSL 
> connections.
> It would be nice if both were updated to 4.0.42, a version released this year.
> 4.0.23 makes it impossible for me to run SSL, because nodes run out of memory 
> every ~30 minutes. This was fixed in 4.0.27.



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

[jira] [Comment Edited] (CASSANDRA-13025) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x.static_columns_with_distinct_test


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

Benjamin Lerer edited comment on CASSANDRA-13025 at 1/25/17 12:45 PM:
--

{quote}Except that I don't remember how we do this on CI right now.{quote}

You just need to have {{upgrade}} in your branch name and {{cassci}} will 
create an additional job for the upgrade tests.


was (Author: blerer):
{quote}Except that I don't remember how we do this on CI right now.{quote}

You just need to have {{upgrade}} in your branch name and {{casci}} will create 
an additional job for the upgrade tests.

> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x.static_columns_with_distinct_test
> 
>
> Key: CASSANDRA-13025
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13025
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>Assignee: Sylvain Lebresne
>Priority: Critical
>  Labels: dtest, test-failure
> Fix For: 3.10, 3.0.x
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.X_dtest_upgrade/28/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x/static_columns_with_distinct_test
> {code}
> Error Message
> 
> {code}{code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools/decorators.py", line 46, in 
> wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/upgrade_tests/cql_tests.py", line 
> 4010, in static_columns_with_distinct_test
> rows = list(cursor.execute("SELECT DISTINCT k, s1 FROM test2"))
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 1998, in execute
> return self.execute_async(query, parameters, trace, custom_payload, 
> timeout, execution_profile, paging_state).result()
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 3784, in result
> raise self._final_exception
> {code}{code}
> Standard Output
> http://git-wip-us.apache.org/repos/asf/cassandra.git 
> git:7eac22dd41cb09e6d64fb5ac48b2cca3c8840cc8
> Unexpected error in node2 log, error: 
> ERROR [Native-Transport-Requests-2] 2016-12-08 03:20:04,861 Message.java:617 
> - Unexpected exception during request; channel = [id: 0xf4c13f2c, 
> L:/127.0.0.2:9042 - R:/127.0.0.1:52112]
> java.io.IOError: java.io.IOException: Corrupt empty row found in unfiltered 
> partition
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:224)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:212)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:779)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:741)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:408)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:273)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:232)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:219) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:204) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>

[jira] [Commented] (CASSANDRA-13025) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x.static_columns_with_distinct_test


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

Benjamin Lerer commented on CASSANDRA-13025:


{quote}Except that I don't remember how we do this on CI right now.{quote}

You just need to have {{upgrade}} in your branch name and {{casci}} will create 
an additional job for the upgrade tests.

> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x.static_columns_with_distinct_test
> 
>
> Key: CASSANDRA-13025
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13025
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>Assignee: Sylvain Lebresne
>Priority: Critical
>  Labels: dtest, test-failure
> Fix For: 3.10, 3.0.x
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.X_dtest_upgrade/28/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x/static_columns_with_distinct_test
> {code}
> Error Message
> 
> {code}{code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools/decorators.py", line 46, in 
> wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/upgrade_tests/cql_tests.py", line 
> 4010, in static_columns_with_distinct_test
> rows = list(cursor.execute("SELECT DISTINCT k, s1 FROM test2"))
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 1998, in execute
> return self.execute_async(query, parameters, trace, custom_payload, 
> timeout, execution_profile, paging_state).result()
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 3784, in result
> raise self._final_exception
> {code}{code}
> Standard Output
> http://git-wip-us.apache.org/repos/asf/cassandra.git 
> git:7eac22dd41cb09e6d64fb5ac48b2cca3c8840cc8
> Unexpected error in node2 log, error: 
> ERROR [Native-Transport-Requests-2] 2016-12-08 03:20:04,861 Message.java:617 
> - Unexpected exception during request; channel = [id: 0xf4c13f2c, 
> L:/127.0.0.2:9042 - R:/127.0.0.1:52112]
> java.io.IOError: java.io.IOException: Corrupt empty row found in unfiltered 
> partition
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:224)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:212)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:779)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:741)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:408)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:273)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:232)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:219) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:204) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
>

[jira] [Commented] (CASSANDRA-6964) error in logs: ByteBuf.release() was not called before it's garbage-collected


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

Romain Hardouin commented on CASSANDRA-6964:


[~spo...@gmail.com]: No, SSL is not enabled.

> error in logs: ByteBuf.release() was not called before it's garbage-collected
> -
>
> Key: CASSANDRA-6964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6964
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Russ Hatch
>  Labels: qa-resolved
> Attachments: node1.log
>
>
> Running some of our paging tests against 2.1 several of these exceptions are 
> triggered:
> {noformat}
> run_tests:
>  [java] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
>  [java] SLF4J: Defaulting to no-operation (NOP) logger implementation
>  [java] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for 
> further details.
>  [java] test_zero_page_size_ignored (__main__.TestPagingSize) ... ERROR
>  [java] 
>  [java] 
> ==
>  [java] ERROR: test_zero_page_size_ignored (__main__.TestPagingSize)
>  [java] 
> --
>  [java] Traceback (most recent call last):
>  [java]   File 
> "/home/rhatch/git/knifewine/cassandra-dtest-jython/base.py", line 152, in 
> tearDown
>  [java] raise AssertionError('Unexpected error in %s node log: %s' % 
> (node.name, errors))
>  [java] AssertionError: Unexpected error in node1 node log: ["ERROR 
> [nioEventLoopGroup-3-2] 2014-03-31 17:16:44,337 Slf4JLogger.java:176 - LEAK: 
> ByteBuf.release() was not called before it's garbage-collected. Enable 
> advanced leak reporting to find out where the leak occurred. To enable 
> advanced leak reporting, specify the JVM option 
> '-Dio.netty.leakDetectionLevel=advanced' or call 
> ResourceLeakDetector.setLevel()\n"]
>  [java] 
>  [java] 
> --
>  [java] Ran 1 test in 37.876s
>  [java] 
>  [java] FAILED (errors=1)
> {noformat}
> These tests are run through jython with the java driver, so there's a little 
> bit of setup needed (if you have ccm and dtest you are most of the way there):
> 1. clone and set up https://github.com/riptano/cassandra-dtest-jython . You 
> may need to install ivy and copy ivy.jar to ~/.ant/lib/ivy.jar
> 2. you should have ccm, and CASSANDRA_DIR should be set in your environment
> 3. from the root of cassandra-dtest-jython run the tests with 'ant 
> run_tests'. The tests take about 10 minutes run completely.
> 4. if you don't want to wait for the entire test suite to run, change the 
> bottom of paging_test.py to just run a single test like so:
> {noformat}
> if __name__ == '__main__':
> suite = unittest.TestSuite()
> suite.addTest(TestPagingSize("test_zero_page_size_ignored"))
> 
> unittest.TextTestRunner(verbosity=2).run(suite)
> 
> exit(0)
> {noformat}



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

[jira] [Comment Edited] (CASSANDRA-10689) java.lang.OutOfMemoryError: Direct buffer memory


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

Stefan Podkowinski edited comment on CASSANDRA-10689 at 1/25/17 12:24 PM:
--

If I understand correctly, the setting will reduce the potential size of 
allocated native memory per thread for non-direct buffers, but the total 
allocation size should still be capped by the constant number of pooled threads 
we use, multiplied by the max. allocated non-direct ByteBuffer size by each 
thread. What I'm wondering here is where are we using non-direct buffers and if 
large buffer allocations that would be affected by the setting, are intentional 
and shouldn't we be able to use smaller buffers instead?

Although the maxCachedBufferSize setting could help avoiding OOM errors, it 
sounds more like a band-aid to me, for a situation where increased native 
memory pressure is taking place caused by a memory leak somewhere else, e.g. in 
the Netty SSL handler (CASSANDRA-13114). Once memory has been depleted, an OOME 
could as well be raise during mentioned non-direct buffer allocations, even of 
moderate sizes.


was (Author: spo...@gmail.com):
If I understand correctly, the setting will reduce the potential size of 
allocated native memory per thread for non-direct buffers, but the total 
allocation size should still be capped by the constant number of pooled threads 
we use, multiplied by the max. allocated non-direct ByteBuffer size by each 
thread. What I'm wondering here is where are we using non-direct buffers and if 
large buffer allocations that would be affected by the setting, are intentional 
and shouldn't we be able to use smaller buffers instead?

Although the maxCachedBufferSize setting could help avoiding OOM errors, it 
sounds more like a band-aid to me, for a situation where increased native 
memory pressure is taking place caused by a memory leak somewhere else, e.g. in 
Netty (CASSANDRA-13114). Once memory has been depleted, an OOME could as well 
be raise during mentioned non-direct buffer allocations, even of moderate sizes.

> java.lang.OutOfMemoryError: Direct buffer memory
> 
>
> Key: CASSANDRA-10689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10689
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mlowicki
>
> {code}
> ERROR [SharedPool-Worker-63] 2015-11-11 17:53:16,161 
> JVMStabilityInspector.java:117 - JVM state determined to be unstable.  
> Exiting forcefully due to:
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:658) ~[na:1.7.0_80]
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123) 
> ~[na:1.7.0_80]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:306) 
> ~[na:1.7.0_80]
> at sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:174) 
> ~[na:1.7.0_80]
> at sun.nio.ch.IOUtil.read(IOUtil.java:195) ~[na:1.7.0_80]
> at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:149) 
> ~[na:1.7.0_80]
> at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.decompressChunk(CompressedRandomAccessReader.java:104)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.reBuffer(CompressedRandomAccessReader.java:81)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]  
> at 
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:310)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.io.util.PoolingSegmentedFile.getSegment(PoolingSegmentedFile.java:64)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.io.sstable.SSTableReader.getFileDataInput(SSTableReader.java:1894)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.columniterator.IndexedSliceReader.setToRowStart(IndexedSliceReader.java:107)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.columniterator.IndexedSliceReader.(IndexedSliceReader.java:83)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.createReader(SSTableSliceIterator.java:65)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.(SSTableSliceIterator.java:42)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:246)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:62)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
>

[jira] [Commented] (CASSANDRA-10689) java.lang.OutOfMemoryError: Direct buffer memory


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

Stefan Podkowinski commented on CASSANDRA-10689:


If I understand correctly, the setting will reduce the potential size of 
allocated native memory per thread for non-direct buffers, but the total 
allocation size should still be capped by the constant number of pooled threads 
we use, multiplied by the max. allocated non-direct ByteBuffer size by each 
thread. What I'm wondering here is where are we using non-direct buffers and if 
large buffer allocations that would be affected by the setting, are intentional 
and shouldn't we be able to use smaller buffers instead?

Although the maxCachedBufferSize setting could help avoiding OOM errors, it 
sounds more like a band-aid to me, for a situation where increased native 
memory pressure is taking place caused by a memory leak somewhere else, e.g. in 
Netty (CASSANDRA-13114). Once memory has been depleted, an OOME could as well 
be raise during mentioned non-direct buffer allocations, even of moderate sizes.

> java.lang.OutOfMemoryError: Direct buffer memory
> 
>
> Key: CASSANDRA-10689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10689
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mlowicki
>
> {code}
> ERROR [SharedPool-Worker-63] 2015-11-11 17:53:16,161 
> JVMStabilityInspector.java:117 - JVM state determined to be unstable.  
> Exiting forcefully due to:
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:658) ~[na:1.7.0_80]
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123) 
> ~[na:1.7.0_80]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:306) 
> ~[na:1.7.0_80]
> at sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:174) 
> ~[na:1.7.0_80]
> at sun.nio.ch.IOUtil.read(IOUtil.java:195) ~[na:1.7.0_80]
> at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:149) 
> ~[na:1.7.0_80]
> at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.decompressChunk(CompressedRandomAccessReader.java:104)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.reBuffer(CompressedRandomAccessReader.java:81)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]  
> at 
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:310)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.io.util.PoolingSegmentedFile.getSegment(PoolingSegmentedFile.java:64)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.io.sstable.SSTableReader.getFileDataInput(SSTableReader.java:1894)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.columniterator.IndexedSliceReader.setToRowStart(IndexedSliceReader.java:107)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.columniterator.IndexedSliceReader.(IndexedSliceReader.java:83)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.createReader(SSTableSliceIterator.java:65)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.(SSTableSliceIterator.java:42)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:246)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:62)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:270)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:62)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1994)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1837)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:353) 
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:85)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:47) 
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
> ~[apache-cassandra-2.1.11.jar:2.1.11]
>

[jira] [Commented] (CASSANDRA-13114) 3.0.x: update netty


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

Stefan Podkowinski commented on CASSANDRA-13114:


[~snazy], since you've been working on a couple of related issues 
(CASSANDRA-12032, CASSANDRA-12033, CASSANDRA-12034, CASSANDRA-11937, 
CASSANDRA-11818).. what would be your suggestion when it comes to back-porting  
some of these to further stabilize memory management in 2.x and 3.0? Do you see 
any issues updating netty to 4.0.42 on all branches, regardless of any 
back-porting decisions for the listed tickets?

> 3.0.x: update netty
> ---
>
> Key: CASSANDRA-13114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13114
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van der Woerdt
>
> https://issues.apache.org/jira/browse/CASSANDRA-12032 updated netty for 
> Cassandra 3.8, but this wasn't backported. Netty 4.0.23, which ships with 
> Cassandra 3.0.x, has some serious bugs around memory handling for SSL 
> connections.
> It would be nice if both were updated to 4.0.42, a version released this year.
> 4.0.23 makes it impossible for me to run SSL, because nodes run out of memory 
> every ~30 minutes. This was fixed in 4.0.27.



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

[jira] [Commented] (CASSANDRA-6964) error in logs: ByteBuf.release() was not called before it's garbage-collected


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

Stefan Podkowinski commented on CASSANDRA-6964:
---

[~rha], do you have ssl enabled for native transport connections? If so, 
CASSANDRA-13114 could be relevant for you here.

> error in logs: ByteBuf.release() was not called before it's garbage-collected
> -
>
> Key: CASSANDRA-6964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6964
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Russ Hatch
>  Labels: qa-resolved
> Attachments: node1.log
>
>
> Running some of our paging tests against 2.1 several of these exceptions are 
> triggered:
> {noformat}
> run_tests:
>  [java] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
>  [java] SLF4J: Defaulting to no-operation (NOP) logger implementation
>  [java] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for 
> further details.
>  [java] test_zero_page_size_ignored (__main__.TestPagingSize) ... ERROR
>  [java] 
>  [java] 
> ==
>  [java] ERROR: test_zero_page_size_ignored (__main__.TestPagingSize)
>  [java] 
> --
>  [java] Traceback (most recent call last):
>  [java]   File 
> "/home/rhatch/git/knifewine/cassandra-dtest-jython/base.py", line 152, in 
> tearDown
>  [java] raise AssertionError('Unexpected error in %s node log: %s' % 
> (node.name, errors))
>  [java] AssertionError: Unexpected error in node1 node log: ["ERROR 
> [nioEventLoopGroup-3-2] 2014-03-31 17:16:44,337 Slf4JLogger.java:176 - LEAK: 
> ByteBuf.release() was not called before it's garbage-collected. Enable 
> advanced leak reporting to find out where the leak occurred. To enable 
> advanced leak reporting, specify the JVM option 
> '-Dio.netty.leakDetectionLevel=advanced' or call 
> ResourceLeakDetector.setLevel()\n"]
>  [java] 
>  [java] 
> --
>  [java] Ran 1 test in 37.876s
>  [java] 
>  [java] FAILED (errors=1)
> {noformat}
> These tests are run through jython with the java driver, so there's a little 
> bit of setup needed (if you have ccm and dtest you are most of the way there):
> 1. clone and set up https://github.com/riptano/cassandra-dtest-jython . You 
> may need to install ivy and copy ivy.jar to ~/.ant/lib/ivy.jar
> 2. you should have ccm, and CASSANDRA_DIR should be set in your environment
> 3. from the root of cassandra-dtest-jython run the tests with 'ant 
> run_tests'. The tests take about 10 minutes run completely.
> 4. if you don't want to wait for the entire test suite to run, change the 
> bottom of paging_test.py to just run a single test like so:
> {noformat}
> if __name__ == '__main__':
> suite = unittest.TestSuite()
> suite.addTest(TestPagingSize("test_zero_page_size_ignored"))
> 
> unittest.TextTestRunner(verbosity=2).run(suite)
> 
> exit(0)
> {noformat}



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

[jira] [Commented] (CASSANDRA-13025) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x.static_columns_with_distinct_test

2017-01-25 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-13025:
--

The dtest failures were due to the protocol version bump and a too conservative 
assertion in {{ReadResponse}}. I pushed a commit for that and restarted the 
tests.

bq. CASSANDRA-13026 seems to be a duplicate?

There's a fair chance, though we should just run the upgrade tests on that 
branch to validate. Except that I don't remember how we do this on CI right now.

> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x.static_columns_with_distinct_test
> 
>
> Key: CASSANDRA-13025
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13025
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>Assignee: Sylvain Lebresne
>Priority: Critical
>  Labels: dtest, test-failure
> Fix For: 3.10, 3.0.x
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.X_dtest_upgrade/28/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x/static_columns_with_distinct_test
> {code}
> Error Message
> 
> {code}{code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools/decorators.py", line 46, in 
> wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/upgrade_tests/cql_tests.py", line 
> 4010, in static_columns_with_distinct_test
> rows = list(cursor.execute("SELECT DISTINCT k, s1 FROM test2"))
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 1998, in execute
> return self.execute_async(query, parameters, trace, custom_payload, 
> timeout, execution_profile, paging_state).result()
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 3784, in result
> raise self._final_exception
> {code}{code}
> Standard Output
> http://git-wip-us.apache.org/repos/asf/cassandra.git 
> git:7eac22dd41cb09e6d64fb5ac48b2cca3c8840cc8
> Unexpected error in node2 log, error: 
> ERROR [Native-Transport-Requests-2] 2016-12-08 03:20:04,861 Message.java:617 
> - Unexpected exception during request; channel = [id: 0xf4c13f2c, 
> L:/127.0.0.2:9042 - R:/127.0.0.1:52112]
> java.io.IOError: java.io.IOException: Corrupt empty row found in unfiltered 
> partition
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:224)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:212)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:779)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:741)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:408)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:273)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:232)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:219) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:204) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
>

[jira] [Commented] (CASSANDRA-6964) error in logs: ByteBuf.release() was not called before it's garbage-collected


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

Romain Hardouin commented on CASSANDRA-6964:


I don't know if it's worth re-opening this ticket but I see this error on a C* 
2.1.16 node:

{noformat}
ERROR [epollEventLoopGroup-2-18] Slf4JLogger.java:176 - LEAK: ByteBuf.release() 
was not called before it's garbage-collected. Enable advanced leak reporting to 
find out where the leak occurred. To enable advanced leak reporting, specify 
the JVM option '-Dio.netty.leakDetectionLevel=advanced' or call 
ResourceLeakDetector.setLevel()
{noformat}

> error in logs: ByteBuf.release() was not called before it's garbage-collected
> -
>
> Key: CASSANDRA-6964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6964
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Russ Hatch
>  Labels: qa-resolved
> Attachments: node1.log
>
>
> Running some of our paging tests against 2.1 several of these exceptions are 
> triggered:
> {noformat}
> run_tests:
>  [java] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
>  [java] SLF4J: Defaulting to no-operation (NOP) logger implementation
>  [java] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for 
> further details.
>  [java] test_zero_page_size_ignored (__main__.TestPagingSize) ... ERROR
>  [java] 
>  [java] 
> ==
>  [java] ERROR: test_zero_page_size_ignored (__main__.TestPagingSize)
>  [java] 
> --
>  [java] Traceback (most recent call last):
>  [java]   File 
> "/home/rhatch/git/knifewine/cassandra-dtest-jython/base.py", line 152, in 
> tearDown
>  [java] raise AssertionError('Unexpected error in %s node log: %s' % 
> (node.name, errors))
>  [java] AssertionError: Unexpected error in node1 node log: ["ERROR 
> [nioEventLoopGroup-3-2] 2014-03-31 17:16:44,337 Slf4JLogger.java:176 - LEAK: 
> ByteBuf.release() was not called before it's garbage-collected. Enable 
> advanced leak reporting to find out where the leak occurred. To enable 
> advanced leak reporting, specify the JVM option 
> '-Dio.netty.leakDetectionLevel=advanced' or call 
> ResourceLeakDetector.setLevel()\n"]
>  [java] 
>  [java] 
> --
>  [java] Ran 1 test in 37.876s
>  [java] 
>  [java] FAILED (errors=1)
> {noformat}
> These tests are run through jython with the java driver, so there's a little 
> bit of setup needed (if you have ccm and dtest you are most of the way there):
> 1. clone and set up https://github.com/riptano/cassandra-dtest-jython . You 
> may need to install ivy and copy ivy.jar to ~/.ant/lib/ivy.jar
> 2. you should have ccm, and CASSANDRA_DIR should be set in your environment
> 3. from the root of cassandra-dtest-jython run the tests with 'ant 
> run_tests'. The tests take about 10 minutes run completely.
> 4. if you don't want to wait for the entire test suite to run, change the 
> bottom of paging_test.py to just run a single test like so:
> {noformat}
> if __name__ == '__main__':
> suite = unittest.TestSuite()
> suite.addTest(TestPagingSize("test_zero_page_size_ignored"))
> 
> unittest.TextTestRunner(verbosity=2).run(suite)
> 
> exit(0)
> {noformat}



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

[jira] [Comment Edited] (CASSANDRA-12156) java.lang.ClassCastException During Write Operations


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

Romain Hardouin edited comment on CASSANDRA-12156 at 1/25/17 9:57 AM:
--

I encounter this issue every now and then on different clusters (one or two 
nodes at a time). Once a node starts to report these errors in logs the 
workaround is to restart Cassandra.
I have currently a node which started to reporting these errors 3 days ago. 31 
errors logged so far. Is there something I could do on this node to have a clue 
on what's happening?
Cassandra version: 2.1.16 / JVM: 1.8.0_91 


was (Author: rha):
I encounter this issue every now and then on different 2.1.16 clusters (one or 
two nodes at a time). Once a node starts to report these errors in logs the 
workaround is to restart Cassandra.
I have currently a node which started to reporting these errors 3 days ago. 31 
errors logged so far. Is there something I could do on this node to have a clue 
on what's happening?

> java.lang.ClassCastException During Write Operations
> 
>
> Key: CASSANDRA-12156
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12156
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Centos 6.7, JDK1.8.0_72, Cassandra 3.0.7
>Reporter: vin01
>Priority: Minor
> Fix For: 3.0.x
>
>
> During a regular ETL process today suddenly i am getting some errors from 
> cassandra which look like :-
> {code}
> ERROR [SharedPool-Worker-28] 2016-07-09 00:07:04,062 Message.java:611 - 
> Unexpected exception during request; channel = [id: 0x7e101236, 
> /ip.add.re.ss:36421 => /ip.add.re.ss:9044]
> io.netty.handler.codec.DecoderException: java.lang.ClassCastException: 
> java.lang.String cannot be cast to [B
> at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:99)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:163)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:971) 
> ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:854) 
> ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:249)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:149)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.epoll.EpollSocketChannel$EpollSocketUnsafe.epollInReady(EpollSocketChannel.java:722)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:326) 
> ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:264) 
> ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to [B
> at 
> io.netty.buffer.PooledHeapByteBuf.array(PooledHeapByteBuf.java:280) 
>

[jira] [Commented] (CASSANDRA-12156) java.lang.ClassCastException During Write Operations


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

Romain Hardouin commented on CASSANDRA-12156:
-

I encounter this issue every now and then on different 2.1.16 clusters (one or 
two nodes at a time). Once a node starts to report these errors in logs the 
workaround is to restart Cassandra.
I have currently a node which started to reporting these errors 3 days ago. 31 
errors logged so far. Is there something I could do on this node to have a clue 
on what's happening?

> java.lang.ClassCastException During Write Operations
> 
>
> Key: CASSANDRA-12156
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12156
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Centos 6.7, JDK1.8.0_72, Cassandra 3.0.7
>Reporter: vin01
>Priority: Minor
> Fix For: 3.0.x
>
>
> During a regular ETL process today suddenly i am getting some errors from 
> cassandra which look like :-
> {code}
> ERROR [SharedPool-Worker-28] 2016-07-09 00:07:04,062 Message.java:611 - 
> Unexpected exception during request; channel = [id: 0x7e101236, 
> /ip.add.re.ss:36421 => /ip.add.re.ss:9044]
> io.netty.handler.codec.DecoderException: java.lang.ClassCastException: 
> java.lang.String cannot be cast to [B
> at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:99)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:163)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:971) 
> ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:854) 
> ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:249)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:149)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.epoll.EpollSocketChannel$EpollSocketUnsafe.epollInReady(EpollSocketChannel.java:722)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:326) 
> ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:264) 
> ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
>  ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to [B
> at 
> io.netty.buffer.PooledHeapByteBuf.array(PooledHeapByteBuf.java:280) 
> ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> org.apache.cassandra.transport.FrameCompressor$LZ4Compressor.decompress(FrameCompressor.java:191)
>  ~[apache-cassandra-3.0.7.jar:3.0.7]
> at 
> org.apache.cassandra.transport.Frame$Decompressor.decode(Frame.java:310) 
> ~[apache-cassandra-3.0.7.jar:3.0.7]
> at 
> org.apache.cassandra.transport.Frame$Decompressor.decode(Frame.java:289) 
> ~[apache-cassandra-3.0.7.jar:3.0.7]
> at 
>

[jira] [Commented] (CASSANDRA-13025) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x.static_columns_with_distinct_test


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

Benjamin Lerer commented on CASSANDRA-13025:


CASSANDRA-13026 seems to be a duplicate? Am I wrong?

> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x.static_columns_with_distinct_test
> 
>
> Key: CASSANDRA-13025
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13025
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>Assignee: Sylvain Lebresne
>Priority: Critical
>  Labels: dtest, test-failure
> Fix For: 3.10, 3.0.x
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.X_dtest_upgrade/28/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x/static_columns_with_distinct_test
> {code}
> Error Message
> 
> {code}{code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools/decorators.py", line 46, in 
> wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/upgrade_tests/cql_tests.py", line 
> 4010, in static_columns_with_distinct_test
> rows = list(cursor.execute("SELECT DISTINCT k, s1 FROM test2"))
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 1998, in execute
> return self.execute_async(query, parameters, trace, custom_payload, 
> timeout, execution_profile, paging_state).result()
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 3784, in result
> raise self._final_exception
> {code}{code}
> Standard Output
> http://git-wip-us.apache.org/repos/asf/cassandra.git 
> git:7eac22dd41cb09e6d64fb5ac48b2cca3c8840cc8
> Unexpected error in node2 log, error: 
> ERROR [Native-Transport-Requests-2] 2016-12-08 03:20:04,861 Message.java:617 
> - Unexpected exception during request; channel = [id: 0xf4c13f2c, 
> L:/127.0.0.2:9042 - R:/127.0.0.1:52112]
> java.io.IOError: java.io.IOException: Corrupt empty row found in unfiltered 
> partition
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:224)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:212)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:779)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:741)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:408)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:273)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:232)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:219) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:204) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
>

[jira] [Updated] (CASSANDRA-12664) GCCompactionTest is flaky

2017-01-25 Thread Branimir Lambov (JIRA)


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

Branimir Lambov updated CASSANDRA-12664:

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

Committed as 
[237e14dd99cf3975d54cb1e41126c40bc183f3b4|https://github.com/apache/cassandra/commit/237e14dd99cf3975d54cb1e41126c40bc183f3b4].

> GCCompactionTest is flaky
> -
>
> Key: CASSANDRA-12664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12664
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Stefania
>Assignee: Branimir Lambov
>Priority: Minor
> Fix For: 3.x
>
>
> {{GCCompactionTest}} was introduced by CASSANDRA-7019 and appears to be 
> flaky, see for example 
> [here|https://cassci.datastax.com/view/Dev/view/sbtourist/job/sbtourist-CASSANDRA-9318-trunk-testall/lastCompletedBuild/testReport/org.apache.cassandra.cql3/GcCompactionTest/testGcCompactionStatic/].
>  
> I think it's the same root cause as CASSANDRA-12282: the tables in the test 
> keyspace are dropped asynchronously after each test, and this might cause 
> additional flush operations for all dirty tables in the keyspace. See the 
> [callstack|https://issues.apache.org/jira/browse/CASSANDRA-12282?focusedCommentId=15399098=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15399098]
>  in 12282. 
> A possible solution is to use KEYSPACE_PER_TEST, which is instead dropped 
> synchronously.



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

[1/3] cassandra git commit: Fix flaky GcCompactionTest

2017-01-25 Thread blambov

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.11 601606719 -> 237e14dd9
  refs/heads/trunk 3465799a3 -> 2987a7093


Fix flaky GcCompactionTest

Patch by Branimir Lambov; reviewed by Stefania Alborghetti for
CASSANDRA-12664

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

Branch: refs/heads/cassandra-3.11
Commit: 237e14dd99cf3975d54cb1e41126c40bc183f3b4
Parents: 6016067
Author: Branimir Lambov 
Authored: Mon Jan 23 17:42:19 2017 +0200
Committer: Branimir Lambov 
Committed: Wed Jan 25 10:10:43 2017 +0200

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cql3/GcCompactionTest.java | 25 
 2 files changed, 26 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/237e14dd/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 2f0e8f1..55762e2 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.10
+ * Fix flaky GcCompactionTest (CASSANDRA-12664)
  * Fix TestHintedHandoff.hintedhandoff_decom_test (CASSANDRA-13058)
  * Fixed query monitoring for range queries (CASSANDRA-13050)
  * Remove outboundBindAny configuration property (CASSANDRA-12673)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/237e14dd/test/unit/org/apache/cassandra/cql3/GcCompactionTest.java
--
diff --git a/test/unit/org/apache/cassandra/cql3/GcCompactionTest.java 
b/test/unit/org/apache/cassandra/cql3/GcCompactionTest.java
index 6fed033..a31b9a1 100644
--- a/test/unit/org/apache/cassandra/cql3/GcCompactionTest.java
+++ b/test/unit/org/apache/cassandra/cql3/GcCompactionTest.java
@@ -41,6 +41,31 @@ public class GcCompactionTest extends CQLTester
 static final int KEY_COUNT = 10;
 static final int CLUSTERING_COUNT = 20;
 
+// Test needs synchronous table drop to avoid flushes causing flaky 
failures
+
+@Override
+protected String createTable(String query)
+{
+return super.createTable(KEYSPACE_PER_TEST, query);
+}
+
+@Override
+protected UntypedResultSet execute(String query, Object... values) throws 
Throwable
+{
+return executeFormattedQuery(formatQuery(KEYSPACE_PER_TEST, query), 
values);
+}
+
+@Override
+public ColumnFamilyStore getCurrentColumnFamilyStore()
+{
+return super.getCurrentColumnFamilyStore(KEYSPACE_PER_TEST);
+}
+
+public void flush()
+{
+flush(KEYSPACE_PER_TEST);
+}
+
 @Test
 public void testGcCompactionPartitions() throws Throwable
 {

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

2017-01-25 Thread blambov

Merge branch 'cassandra-3.11' into trunk


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

Branch: refs/heads/trunk
Commit: 2987a7093c6e167649274f4aa8bf0242eb4dea91
Parents: 3465799 237e14d
Author: Branimir Lambov 
Authored: Wed Jan 25 10:17:15 2017 +0200
Committer: Branimir Lambov 
Committed: Wed Jan 25 10:17:15 2017 +0200

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cql3/GcCompactionTest.java | 25 
 2 files changed, 26 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2987a709/CHANGES.txt
--
diff --cc CHANGES.txt
index dd25cac,55762e2..e5bb09d
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,35 -1,5 +1,36 @@@
 +4.0
 + * Parallelize streaming of different keyspaces (4663)
 + * Improved compactions metrics (CASSANDRA-13015)
 + * Speed-up start-up sequence by avoiding un-needed flushes (CASSANDRA-13031)
 + * Use Caffeine (W-TinyLFU) for on-heap caches (CASSANDRA-10855)
 + * Thrift removal (CASSANDRA-5)
 + * Remove pre-3.0 compatibility code for 4.0 (CASSANDRA-12716)
 + * Add column definition kind to dropped columns in schema (CASSANDRA-12705)
 + * Add (automate) Nodetool Documentation (CASSANDRA-12672)
 + * Update bundled cqlsh python driver to 3.7.0 (CASSANDRA-12736)
 + * Reject invalid replication settings when creating or altering a keyspace 
(CASSANDRA-12681)
 + * Clean up the SSTableReader#getScanner API wrt removal of RateLimiter 
(CASSANDRA-12422)
 + * Use new token allocation for non bootstrap case as well (CASSANDRA-13080)
 + * Avoid byte-array copy when key cache is disabled (CASSANDRA-13084)
 + * More fixes to the TokenAllocator (CASSANDRA-12990)
 + * Require forceful decommission if number of nodes is less than replication 
factor (CASSANDRA-12510)
 + * Allow IN restrictions on column families with collections (CASSANDRA-12654)
 + * Move to FastThreadLocalThread and FastThreadLocal (CASSANDRA-13034)
 + * nodetool stopdaemon errors out (CASSANDRA-13030)
 + * Log message size in trace message in OutboundTcpConnection 
(CASSANDRA-13028)
 + * Add timeUnit Days for cassandra-stress (CASSANDRA-13029)
 + * Add mutation size and batch metrics (CASSANDRA-12649)
 + * Add method to get size of endpoints to TokenMetadata (CASSANDRA-12999)
 + * Fix primary index calculation for SASI (CASSANDRA-12910)
 + * Expose time spent waiting in thread pool queue (CASSANDRA-8398)
 + * Conditionally update index built status to avoid unnecessary flushes 
(CASSANDRA-12969)
 + * NoReplicationTokenAllocator should work with zero replication factor 
(CASSANDRA-12983)
 + * cqlsh auto completion: refactor definition of compaction strategy options 
(CASSANDRA-12946)
 + * Add support for arithmetic operators (CASSANDRA-11935)
 + * Tables in system_distributed should not use gcgs of 0 (CASSANDRA-12954)
 +
  3.10
+  * Fix flaky GcCompactionTest (CASSANDRA-12664)
   * Fix TestHintedHandoff.hintedhandoff_decom_test (CASSANDRA-13058)
   * Fixed query monitoring for range queries (CASSANDRA-13050)
   * Remove outboundBindAny configuration property (CASSANDRA-12673)

[2/3] cassandra git commit: Fix flaky GcCompactionTest

2017-01-25 Thread blambov

Fix flaky GcCompactionTest

Patch by Branimir Lambov; reviewed by Stefania Alborghetti for
CASSANDRA-12664

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

Branch: refs/heads/trunk
Commit: 237e14dd99cf3975d54cb1e41126c40bc183f3b4
Parents: 6016067
Author: Branimir Lambov 
Authored: Mon Jan 23 17:42:19 2017 +0200
Committer: Branimir Lambov 
Committed: Wed Jan 25 10:10:43 2017 +0200

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cql3/GcCompactionTest.java | 25 
 2 files changed, 26 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/237e14dd/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 2f0e8f1..55762e2 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.10
+ * Fix flaky GcCompactionTest (CASSANDRA-12664)
  * Fix TestHintedHandoff.hintedhandoff_decom_test (CASSANDRA-13058)
  * Fixed query monitoring for range queries (CASSANDRA-13050)
  * Remove outboundBindAny configuration property (CASSANDRA-12673)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/237e14dd/test/unit/org/apache/cassandra/cql3/GcCompactionTest.java
--
diff --git a/test/unit/org/apache/cassandra/cql3/GcCompactionTest.java 
b/test/unit/org/apache/cassandra/cql3/GcCompactionTest.java
index 6fed033..a31b9a1 100644
--- a/test/unit/org/apache/cassandra/cql3/GcCompactionTest.java
+++ b/test/unit/org/apache/cassandra/cql3/GcCompactionTest.java
@@ -41,6 +41,31 @@ public class GcCompactionTest extends CQLTester
 static final int KEY_COUNT = 10;
 static final int CLUSTERING_COUNT = 20;
 
+// Test needs synchronous table drop to avoid flushes causing flaky 
failures
+
+@Override
+protected String createTable(String query)
+{
+return super.createTable(KEYSPACE_PER_TEST, query);
+}
+
+@Override
+protected UntypedResultSet execute(String query, Object... values) throws 
Throwable
+{
+return executeFormattedQuery(formatQuery(KEYSPACE_PER_TEST, query), 
values);
+}
+
+@Override
+public ColumnFamilyStore getCurrentColumnFamilyStore()
+{
+return super.getCurrentColumnFamilyStore(KEYSPACE_PER_TEST);
+}
+
+public void flush()
+{
+flush(KEYSPACE_PER_TEST);
+}
+
 @Test
 public void testGcCompactionPartitions() throws Throwable
 {

[jira] [Commented] (CASSANDRA-13025) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x.static_columns_with_distinct_test