[jira] [Comment Edited] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[JIRA]

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

ingard mevåg edited comment on CASSANDRA-13236 at 2/18/17 7:41 AM:
---

How do I go about comparing the tables? I've run upgradesstables on every
node now, but I still have snapshops from before the upgrade.


was (Author: ingardm):
How do I go about comparing the tables? I've run upgradesstables on every
node now, but I still have snapshops from before the upgrade.





-- 
Ingard Mevåg
Driftssjef
Jottacloud

Mobil: +47 450 22 834
E-post: ing...@jottacloud.com
Webside: www.jottacloud.com


> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> {code}
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [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.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic 

[jira] [Updated] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[JIRA]

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

ingard mevåg updated CASSANDRA-13236:
-

How do I go about comparing the tables? I've run upgradesstables on every
node now, but I still have snapshops from before the upgrade.





-- 
Ingard Mevåg
Driftssjef
Jottacloud

Mobil: +47 450 22 834
E-post: ing...@jottacloud.com
Webside: www.jottacloud.com


> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> {code}
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [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.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserialize(UnfilteredSerializer.java:374)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> 

[jira] [Commented] (CASSANDRA-8844) Change Data Capture (CDC)

[Yasuharu Goto (JIRA)]

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

Yasuharu Goto commented on CASSANDRA-8844:
--

[~jbellis] Sorry, It seems that I unexpectedly changed the assignment with a 
keyboard shortcut. Thank you for your fix.

> Change Data Capture (CDC)
> -
>
> Key: CASSANDRA-8844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8844
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Coordination, Local Write-Read Paths
>Reporter: Tupshin Harper
>Assignee: Joshua McKenzie
>Priority: Critical
> Fix For: 3.8
>
>
> "In databases, change data capture (CDC) is a set of software design patterns 
> used to determine (and track) the data that has changed so that action can be 
> taken using the changed data. Also, Change data capture (CDC) is an approach 
> to data integration that is based on the identification, capture and delivery 
> of the changes made to enterprise data sources."
> -Wikipedia
> As Cassandra is increasingly being used as the Source of Record (SoR) for 
> mission critical data in large enterprises, it is increasingly being called 
> upon to act as the central hub of traffic and data flow to other systems. In 
> order to try to address the general need, we (cc [~brianmhess]), propose 
> implementing a simple data logging mechanism to enable per-table CDC patterns.
> h2. The goals:
> # Use CQL as the primary ingestion mechanism, in order to leverage its 
> Consistency Level semantics, and in order to treat it as the single 
> reliable/durable SoR for the data.
> # To provide a mechanism for implementing good and reliable 
> (deliver-at-least-once with possible mechanisms for deliver-exactly-once ) 
> continuous semi-realtime feeds of mutations going into a Cassandra cluster.
> # To eliminate the developmental and operational burden of users so that they 
> don't have to do dual writes to other systems.
> # For users that are currently doing batch export from a Cassandra system, 
> give them the opportunity to make that realtime with a minimum of coding.
> h2. The mechanism:
> We propose a durable logging mechanism that functions similar to a commitlog, 
> with the following nuances:
> - Takes place on every node, not just the coordinator, so RF number of copies 
> are logged.
> - Separate log per table.
> - Per-table configuration. Only tables that are specified as CDC_LOG would do 
> any logging.
> - Per DC. We are trying to keep the complexity to a minimum to make this an 
> easy enhancement, but most likely use cases would prefer to only implement 
> CDC logging in one (or a subset) of the DCs that are being replicated to
> - In the critical path of ConsistencyLevel acknowledgment. Just as with the 
> commitlog, failure to write to the CDC log should fail that node's write. If 
> that means the requested consistency level was not met, then clients *should* 
> experience UnavailableExceptions.
> - Be written in a Row-centric manner such that it is easy for consumers to 
> reconstitute rows atomically.
> - Written in a simple format designed to be consumed *directly* by daemons 
> written in non JVM languages
> h2. Nice-to-haves
> I strongly suspect that the following features will be asked for, but I also 
> believe that they can be deferred for a subsequent release, and to guage 
> actual interest.
> - Multiple logs per table. This would make it easy to have multiple 
> "subscribers" to a single table's changes. A workaround would be to create a 
> forking daemon listener, but that's not a great answer.
> - Log filtering. Being able to apply filters, including UDF-based filters 
> would make Casandra a much more versatile feeder into other systems, and 
> again, reduce complexity that would otherwise need to be built into the 
> daemons.
> h2. Format and Consumption
> - Cassandra would only write to the CDC log, and never delete from it. 
> - Cleaning up consumed logfiles would be the client daemon's responibility
> - Logfile size should probably be configurable.
> - Logfiles should be named with a predictable naming schema, making it 
> triivial to process them in order.
> - Daemons should be able to checkpoint their work, and resume from where they 
> left off. This means they would have to leave some file artifact in the CDC 
> log's directory.
> - A sophisticated daemon should be able to be written that could 
> -- Catch up, in written-order, even when it is multiple logfiles behind in 
> processing
> -- Be able to continuously "tail" the most recent logfile and get 
> low-latency(ms?) access to the data as it is written.
> h2. Alternate approach
> In order to make consuming a change log easy and efficient to do with low 
> latency, the following could supplement the approach outlined above
> - 

[jira] [Assigned] (CASSANDRA-8844) Change Data Capture (CDC)

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis reassigned CASSANDRA-8844:
-

Assignee: Joshua McKenzie  (was: Yasuharu Goto)

> Change Data Capture (CDC)
> -
>
> Key: CASSANDRA-8844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8844
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Coordination, Local Write-Read Paths
>Reporter: Tupshin Harper
>Assignee: Joshua McKenzie
>Priority: Critical
> Fix For: 3.8
>
>
> "In databases, change data capture (CDC) is a set of software design patterns 
> used to determine (and track) the data that has changed so that action can be 
> taken using the changed data. Also, Change data capture (CDC) is an approach 
> to data integration that is based on the identification, capture and delivery 
> of the changes made to enterprise data sources."
> -Wikipedia
> As Cassandra is increasingly being used as the Source of Record (SoR) for 
> mission critical data in large enterprises, it is increasingly being called 
> upon to act as the central hub of traffic and data flow to other systems. In 
> order to try to address the general need, we (cc [~brianmhess]), propose 
> implementing a simple data logging mechanism to enable per-table CDC patterns.
> h2. The goals:
> # Use CQL as the primary ingestion mechanism, in order to leverage its 
> Consistency Level semantics, and in order to treat it as the single 
> reliable/durable SoR for the data.
> # To provide a mechanism for implementing good and reliable 
> (deliver-at-least-once with possible mechanisms for deliver-exactly-once ) 
> continuous semi-realtime feeds of mutations going into a Cassandra cluster.
> # To eliminate the developmental and operational burden of users so that they 
> don't have to do dual writes to other systems.
> # For users that are currently doing batch export from a Cassandra system, 
> give them the opportunity to make that realtime with a minimum of coding.
> h2. The mechanism:
> We propose a durable logging mechanism that functions similar to a commitlog, 
> with the following nuances:
> - Takes place on every node, not just the coordinator, so RF number of copies 
> are logged.
> - Separate log per table.
> - Per-table configuration. Only tables that are specified as CDC_LOG would do 
> any logging.
> - Per DC. We are trying to keep the complexity to a minimum to make this an 
> easy enhancement, but most likely use cases would prefer to only implement 
> CDC logging in one (or a subset) of the DCs that are being replicated to
> - In the critical path of ConsistencyLevel acknowledgment. Just as with the 
> commitlog, failure to write to the CDC log should fail that node's write. If 
> that means the requested consistency level was not met, then clients *should* 
> experience UnavailableExceptions.
> - Be written in a Row-centric manner such that it is easy for consumers to 
> reconstitute rows atomically.
> - Written in a simple format designed to be consumed *directly* by daemons 
> written in non JVM languages
> h2. Nice-to-haves
> I strongly suspect that the following features will be asked for, but I also 
> believe that they can be deferred for a subsequent release, and to guage 
> actual interest.
> - Multiple logs per table. This would make it easy to have multiple 
> "subscribers" to a single table's changes. A workaround would be to create a 
> forking daemon listener, but that's not a great answer.
> - Log filtering. Being able to apply filters, including UDF-based filters 
> would make Casandra a much more versatile feeder into other systems, and 
> again, reduce complexity that would otherwise need to be built into the 
> daemons.
> h2. Format and Consumption
> - Cassandra would only write to the CDC log, and never delete from it. 
> - Cleaning up consumed logfiles would be the client daemon's responibility
> - Logfile size should probably be configurable.
> - Logfiles should be named with a predictable naming schema, making it 
> triivial to process them in order.
> - Daemons should be able to checkpoint their work, and resume from where they 
> left off. This means they would have to leave some file artifact in the CDC 
> log's directory.
> - A sophisticated daemon should be able to be written that could 
> -- Catch up, in written-order, even when it is multiple logfiles behind in 
> processing
> -- Be able to continuously "tail" the most recent logfile and get 
> low-latency(ms?) access to the data as it is written.
> h2. Alternate approach
> In order to make consuming a change log easy and efficient to do with low 
> latency, the following could supplement the approach outlined above
> - Instead of writing to a logfile, by default, Cassandra could expose a 
> socket for a daemon to connect 

[jira] [Assigned] (CASSANDRA-8844) Change Data Capture (CDC)

[Yasuharu Goto (JIRA)]

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

Yasuharu Goto reassigned CASSANDRA-8844:


Assignee: Yasuharu Goto  (was: Joshua McKenzie)

> Change Data Capture (CDC)
> -
>
> Key: CASSANDRA-8844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8844
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Coordination, Local Write-Read Paths
>Reporter: Tupshin Harper
>Assignee: Yasuharu Goto
>Priority: Critical
> Fix For: 3.8
>
>
> "In databases, change data capture (CDC) is a set of software design patterns 
> used to determine (and track) the data that has changed so that action can be 
> taken using the changed data. Also, Change data capture (CDC) is an approach 
> to data integration that is based on the identification, capture and delivery 
> of the changes made to enterprise data sources."
> -Wikipedia
> As Cassandra is increasingly being used as the Source of Record (SoR) for 
> mission critical data in large enterprises, it is increasingly being called 
> upon to act as the central hub of traffic and data flow to other systems. In 
> order to try to address the general need, we (cc [~brianmhess]), propose 
> implementing a simple data logging mechanism to enable per-table CDC patterns.
> h2. The goals:
> # Use CQL as the primary ingestion mechanism, in order to leverage its 
> Consistency Level semantics, and in order to treat it as the single 
> reliable/durable SoR for the data.
> # To provide a mechanism for implementing good and reliable 
> (deliver-at-least-once with possible mechanisms for deliver-exactly-once ) 
> continuous semi-realtime feeds of mutations going into a Cassandra cluster.
> # To eliminate the developmental and operational burden of users so that they 
> don't have to do dual writes to other systems.
> # For users that are currently doing batch export from a Cassandra system, 
> give them the opportunity to make that realtime with a minimum of coding.
> h2. The mechanism:
> We propose a durable logging mechanism that functions similar to a commitlog, 
> with the following nuances:
> - Takes place on every node, not just the coordinator, so RF number of copies 
> are logged.
> - Separate log per table.
> - Per-table configuration. Only tables that are specified as CDC_LOG would do 
> any logging.
> - Per DC. We are trying to keep the complexity to a minimum to make this an 
> easy enhancement, but most likely use cases would prefer to only implement 
> CDC logging in one (or a subset) of the DCs that are being replicated to
> - In the critical path of ConsistencyLevel acknowledgment. Just as with the 
> commitlog, failure to write to the CDC log should fail that node's write. If 
> that means the requested consistency level was not met, then clients *should* 
> experience UnavailableExceptions.
> - Be written in a Row-centric manner such that it is easy for consumers to 
> reconstitute rows atomically.
> - Written in a simple format designed to be consumed *directly* by daemons 
> written in non JVM languages
> h2. Nice-to-haves
> I strongly suspect that the following features will be asked for, but I also 
> believe that they can be deferred for a subsequent release, and to guage 
> actual interest.
> - Multiple logs per table. This would make it easy to have multiple 
> "subscribers" to a single table's changes. A workaround would be to create a 
> forking daemon listener, but that's not a great answer.
> - Log filtering. Being able to apply filters, including UDF-based filters 
> would make Casandra a much more versatile feeder into other systems, and 
> again, reduce complexity that would otherwise need to be built into the 
> daemons.
> h2. Format and Consumption
> - Cassandra would only write to the CDC log, and never delete from it. 
> - Cleaning up consumed logfiles would be the client daemon's responibility
> - Logfile size should probably be configurable.
> - Logfiles should be named with a predictable naming schema, making it 
> triivial to process them in order.
> - Daemons should be able to checkpoint their work, and resume from where they 
> left off. This means they would have to leave some file artifact in the CDC 
> log's directory.
> - A sophisticated daemon should be able to be written that could 
> -- Catch up, in written-order, even when it is multiple logfiles behind in 
> processing
> -- Be able to continuously "tail" the most recent logfile and get 
> low-latency(ms?) access to the data as it is written.
> h2. Alternate approach
> In order to make consuming a change log easy and efficient to do with low 
> latency, the following could supplement the approach outlined above
> - Instead of writing to a logfile, by default, Cassandra could expose a 
> socket for a daemon to connect to, 

[jira] [Updated] (CASSANDRA-10726) Read repair inserts should not be blocking

[Xiaolong Jiang (JIRA)]

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

Xiaolong Jiang updated CASSANDRA-10726:
---
 Reviewer: Jason Brown
Fix Version/s: 3.0.x
   Status: Patch Available  (was: In Progress)

> Read repair inserts should not be blocking
> --
>
> Key: CASSANDRA-10726
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10726
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Coordination
>Reporter: Richard Low
>Assignee: Xiaolong Jiang
> Fix For: 3.0.x
>
>
> Today, if there’s a digest mismatch in a foreground read repair, the insert 
> to update out of date replicas is blocking. This means, if it fails, the read 
> fails with a timeout. If a node is dropping writes (maybe it is overloaded or 
> the mutation stage is backed up for some other reason), all reads to a 
> replica set could fail. Further, replicas dropping writes get more out of 
> sync so will require more read repair.
> The comment on the code for why the writes are blocking is:
> {code}
> // wait for the repair writes to be acknowledged, to minimize impact on any 
> replica that's
> // behind on writes in case the out-of-sync row is read multiple times in 
> quick succession
> {code}
> but the bad side effect is that reads timeout. Either the writes should not 
> be blocking or we should return success for the read even if the write times 
> out.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-10726) Read repair inserts should not be blocking

[Xiaolong Jiang (JIRA)]

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

Xiaolong Jiang commented on CASSANDRA-10726:


[~jasobrown] Patch is ready https://github.com/apache/cassandra/pull/94

> Read repair inserts should not be blocking
> --
>
> Key: CASSANDRA-10726
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10726
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Coordination
>Reporter: Richard Low
>Assignee: Xiaolong Jiang
>
> Today, if there’s a digest mismatch in a foreground read repair, the insert 
> to update out of date replicas is blocking. This means, if it fails, the read 
> fails with a timeout. If a node is dropping writes (maybe it is overloaded or 
> the mutation stage is backed up for some other reason), all reads to a 
> replica set could fail. Further, replicas dropping writes get more out of 
> sync so will require more read repair.
> The comment on the code for why the writes are blocking is:
> {code}
> // wait for the repair writes to be acknowledged, to minimize impact on any 
> replica that's
> // behind on writes in case the out-of-sync row is read multiple times in 
> quick succession
> {code}
> but the bad side effect is that reads timeout. Either the writes should not 
> be blocking or we should return success for the read even if the write times 
> out.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-10726) Read repair inserts should not be blocking

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-10726:


GitHub user xiaolong302 opened a pull request:

https://github.com/apache/cassandra/pull/94

CASSANDRA-10726: Read repair inserts should use speculative retry

1. do an extra read repair retry to only guarantee “monotonic quorum
read”. Here “quorum” means majority of nodes among replicas
2. only block what is needed for resolving the digest mismatch no
matter whether it’s speculative retry or read repair chance.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/xiaolong302/cassandra CASSANDRA-10726

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cassandra/pull/94.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #94


commit a587c20e82ffc4aa7c4a3cb1468551b255fc7f71
Author: Xiaolong Jiang 
Date:   2017-01-17T05:31:06Z

Cass: CASSANDRA-10726: Read repair inserts should use speculative retry

1. do an extra read repair retry to only guarantee “monotonic quorum
read”. Here “quorum” means majority of nodes among replicas
2. only block what is needed for resolving the digest mismatch no
matter whether it’s speculative retry or read repair chance.




> Read repair inserts should not be blocking
> --
>
> Key: CASSANDRA-10726
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10726
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Coordination
>Reporter: Richard Low
>Assignee: Xiaolong Jiang
>
> Today, if there’s a digest mismatch in a foreground read repair, the insert 
> to update out of date replicas is blocking. This means, if it fails, the read 
> fails with a timeout. If a node is dropping writes (maybe it is overloaded or 
> the mutation stage is backed up for some other reason), all reads to a 
> replica set could fail. Further, replicas dropping writes get more out of 
> sync so will require more read repair.
> The comment on the code for why the writes are blocking is:
> {code}
> // wait for the repair writes to be acknowledged, to minimize impact on any 
> replica that's
> // behind on writes in case the out-of-sync row is read multiple times in 
> quick succession
> {code}
> but the bad side effect is that reads timeout. Either the writes should not 
> be blocking or we should return success for the read even if the write times 
> out.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

cassandra git commit: make inner classes static where possible

[dbrosius]

Repository: cassandra
Updated Branches:
  refs/heads/trunk aa9b84995 -> 1f7a1dde5


make inner classes static where possible


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

Branch: refs/heads/trunk
Commit: 1f7a1dde5ee5fdea108fb50a5ab86af1e86207d7
Parents: aa9b849
Author: Dave Brosius 
Authored: Fri Feb 17 18:31:32 2017 -0500
Committer: Dave Brosius 
Committed: Fri Feb 17 18:31:32 2017 -0500

--
 src/java/org/apache/cassandra/service/ActiveRepairService.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f7a1dde/src/java/org/apache/cassandra/service/ActiveRepairService.java
--
diff --git a/src/java/org/apache/cassandra/service/ActiveRepairService.java 
b/src/java/org/apache/cassandra/service/ActiveRepairService.java
index c497907..518cd8e 100644
--- a/src/java/org/apache/cassandra/service/ActiveRepairService.java
+++ b/src/java/org/apache/cassandra/service/ActiveRepairService.java
@@ -100,7 +100,7 @@ public class ActiveRepairService implements 
IEndpointStateChangeSubscriber, IFai
 STARTED, SESSION_SUCCESS, SESSION_FAILED, FINISHED
 }
 
-public class ConsistentSessions
+public static class ConsistentSessions
 {
 public final LocalSessions local = new LocalSessions();
 public final CoordinatorSessions coordinated = new 
CoordinatorSessions();

[jira] [Commented] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13236:


Likely a dupe of CASSANDRA-12088 , marking as related. 

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> {code}
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [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.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserialize(UnfilteredSerializer.java:374)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:217)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> ... 23 common frames omitted
> {code}



--
This message was sent by 

cassandra git commit: c* uses commons-lang3

[dbrosius]

Repository: cassandra
Updated Branches:
  refs/heads/trunk c878b6968 -> aa9b84995


c* uses commons-lang3


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

Branch: refs/heads/trunk
Commit: aa9b84995ffafa4325ea009d6748ca143aa6d236
Parents: c878b69
Author: Dave Brosius 
Authored: Fri Feb 17 18:24:11 2017 -0500
Committer: Dave Brosius 
Committed: Fri Feb 17 18:24:11 2017 -0500

--
 src/java/org/apache/cassandra/cql3/Duration.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/aa9b8499/src/java/org/apache/cassandra/cql3/Duration.java
--
diff --git a/src/java/org/apache/cassandra/cql3/Duration.java 
b/src/java/org/apache/cassandra/cql3/Duration.java
index e6151cb..7452316 100644
--- a/src/java/org/apache/cassandra/cql3/Duration.java
+++ b/src/java/org/apache/cassandra/cql3/Duration.java
@@ -29,7 +29,7 @@ import org.apache.cassandra.serializers.MarshalException;
 
 import static 
org.apache.cassandra.cql3.statements.RequestValidations.checkTrue;
 import static 
org.apache.cassandra.cql3.statements.RequestValidations.invalidRequest;
-import static org.apache.commons.lang.time.DateUtils.MILLIS_PER_DAY;
+import static org.apache.commons.lang3.time.DateUtils.MILLIS_PER_DAY;
 
 /**
  * Represents a duration. A durations store separately months, days, and 
seconds due to the fact that

[jira] [Updated] (CASSANDRA-13234) Add histogram for delay to deliver hints

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13234:
---
Status: Patch Available  (was: Open)

> Add histogram for delay to deliver hints
> 
>
> Key: CASSANDRA-13234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13234
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
> Fix For: 3.0.x, 3.11.x
>
>
> There is very little visibility into hint delivery in general - having 
> histograms available to understand how long it takes to deliver hints is 
> useful for operators to better identify problems. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13234) Add histogram for delay to deliver hints

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13234:


|| Branch || Unit Test || Dtest ||
| [3.0|https://github.com/jeffjirsa/cassandra/tree/cassandra-3.0-13234] | [3.0 
testall|http://cassci.datastax.com/job/jeffjirsa-cassandra-3.0-13234-testall/] 
| [3.0 
dtest|http://cassci.datastax.com/job/jeffjirsa-cassandra-3.0-13234-dtest/] |
| [3.11|https://github.com/jeffjirsa/cassandra/tree/cassandra-3.11-13234] | 
[3.11 
testall|http://cassci.datastax.com/job/jeffjirsa-cassandra-3.11-13234-testall/] 
| [3.11 
dtest|http://cassci.datastax.com/job/jeffjirsa-cassandra-3.11-13234-dtest/] |
| [trunk|https://github.com/jeffjirsa/cassandra/tree/cassandra-13234] | 
[testall|http://cassci.datastax.com/job/jeffjirsa-cassandra-13234-testall/] | 
[dtest|http://cassci.datastax.com/job/jeffjirsa-cassandra-13234-dtest/] |


> Add histogram for delay to deliver hints
> 
>
> Key: CASSANDRA-13234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13234
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
> Fix For: 3.0.x, 3.11.x
>
>
> There is very little visibility into hint delivery in general - having 
> histograms available to understand how long it takes to deliver hints is 
> useful for operators to better identify problems. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13226) StreamPlan for incremental repairs flushing memtables unnecessarily

[Blake Eggleston (JIRA)]

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

Blake Eggleston updated CASSANDRA-13226:

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

committed as c878b6968be88fa89fb1d1d0212411bcbc4fae7c

> StreamPlan for incremental repairs flushing memtables unnecessarily
> ---
>
> Key: CASSANDRA-13226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13226
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 4.0
>
>
> Since incremental repairs are run against a fixed dataset, there's no need to 
> flush memtables when streaming for them.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

cassandra git commit: StreamPlan for incremental repairs flushing memtables unnecessarily Patch by Blake Eggleston; Reviewed by Marcus Eriksson for CASSANDRA-13226

[bdeggleston]

Repository: cassandra
Updated Branches:
  refs/heads/trunk c718bfff9 -> c878b6968


StreamPlan for incremental repairs flushing memtables unnecessarily
Patch by Blake Eggleston; Reviewed by Marcus Eriksson for CASSANDRA-13226


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

Branch: refs/heads/trunk
Commit: c878b6968be88fa89fb1d1d0212411bcbc4fae7c
Parents: c718bff
Author: Blake Eggleston 
Authored: Wed Feb 15 10:47:24 2017 -0800
Committer: Blake Eggleston 
Committed: Fri Feb 17 13:57:17 2017 -0800

--
 .../cassandra/repair/StreamingRepairTask.java   | 19 ++--
 .../apache/cassandra/streaming/StreamPlan.java  | 10 +++
 .../compaction/AbstractPendingRepairTest.java   |  4 +-
 ...pactionStrategyManagerPendingRepairTest.java | 14 +--
 .../db/compaction/PendingRepairManagerTest.java | 22 ++---
 .../cassandra/repair/AbstractRepairTest.java| 91 
 .../repair/StreamingRepairTaskTest.java | 89 +++
 .../consistent/CoordinatorSessionTest.java  |  3 +-
 .../consistent/CoordinatorSessionsTest.java |  5 +-
 .../repair/consistent/LocalSessionTest.java |  5 +-
 10 files changed, 230 insertions(+), 32 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c878b696/src/java/org/apache/cassandra/repair/StreamingRepairTask.java
--
diff --git a/src/java/org/apache/cassandra/repair/StreamingRepairTask.java 
b/src/java/org/apache/cassandra/repair/StreamingRepairTask.java
index f24a79a..6bce1fa 100644
--- a/src/java/org/apache/cassandra/repair/StreamingRepairTask.java
+++ b/src/java/org/apache/cassandra/repair/StreamingRepairTask.java
@@ -19,6 +19,7 @@ package org.apache.cassandra.repair;
 
 import java.net.InetAddress;
 
+import com.google.common.annotations.VisibleForTesting;
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
 
@@ -64,13 +65,17 @@ public class StreamingRepairTask implements Runnable, 
StreamEventHandler
 ActiveRepairService.ParentRepairSession prs = 
ActiveRepairService.instance.getParentRepairSession(desc.parentSessionId);
 isIncremental = prs.isIncremental;
 }
-new StreamPlan("Repair", repairedAt, 1, false, isIncremental, false, 
isConsistent ? desc.parentSessionId : null).listeners(this)
-.flushBeforeTransfer(true)
-// request ranges from the remote 
node
-.requestRanges(dest, preferred, 
desc.keyspace, request.ranges, desc.columnFamily)
-// send ranges to the remote node
-.transferRanges(dest, preferred, 
desc.keyspace, request.ranges, desc.columnFamily)
-.execute();
+createStreamPlan(dest, preferred, isIncremental).execute();
+}
+
+@VisibleForTesting
+StreamPlan createStreamPlan(InetAddress dest, InetAddress preferred, 
boolean isIncremental)
+{
+return new StreamPlan("Repair", repairedAt, 1, false, isIncremental, 
false, isConsistent ? desc.parentSessionId : null)
+   .listeners(this)
+   .flushBeforeTransfer(!isIncremental) // sstables are isolated 
at the beginning of an incremental repair session, so flushing isn't neccessary
+   .requestRanges(dest, preferred, desc.keyspace, request.ranges, 
desc.columnFamily) // request ranges from the remote node
+   .transferRanges(dest, preferred, desc.keyspace, request.ranges, 
desc.columnFamily); // send ranges to the remote node
 }
 
 public void handleStreamEvent(StreamEvent event)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c878b696/src/java/org/apache/cassandra/streaming/StreamPlan.java
--
diff --git a/src/java/org/apache/cassandra/streaming/StreamPlan.java 
b/src/java/org/apache/cassandra/streaming/StreamPlan.java
index 5526da8..5a2ce77 100644
--- a/src/java/org/apache/cassandra/streaming/StreamPlan.java
+++ b/src/java/org/apache/cassandra/streaming/StreamPlan.java
@@ -202,4 +202,14 @@ public class StreamPlan
 this.flushBeforeTransfer = flushBeforeTransfer;
 return this;
 }
+
+public long getRepairedAt()
+{
+return repairedAt;
+}
+
+public boolean getFlushBeforeTransfer()
+{
+return flushBeforeTransfer;
+}
 }

[jira] [Resolved] (CASSANDRA-13018) Exceptions encountered calling getSeeds() breaks OTC thread

[Jason Brown (JIRA)]

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

Jason Brown resolved CASSANDRA-13018.
-
   Resolution: Fixed
Fix Version/s: 4.0
   3.11.0
   3.0.11
   2.2.9

committed as sha {{8556a2b932046ee0633b0e619d3dd04b57bb653e}} to 2.2, 3.0, 
3.11, and trunk. thanks!

> Exceptions encountered calling getSeeds() breaks OTC thread
> ---
>
> Key: CASSANDRA-13018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13018
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>  Labels: lhf
> Fix For: 2.2.9, 3.0.11, 3.11.0, 4.0
>
> Attachments: 
> 0001-Better-handle-config-errors-during-outbound-connecti.patch
>
>
> OutboundTcpConnection.connect() calls getSeeds(). If getSeeds() throws an 
> exception (for example, DD/Config invalid yaml error), messaging thread(s) 
> break(s). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jasobrown]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.11
Commit: e2bdf9971da514d260176663bbd8cc24f2d60049
Parents: 338226e 8556a2b
Author: Jason Brown 
Authored: Fri Feb 17 13:33:46 2017 -0800
Committer: Jason Brown 
Committed: Fri Feb 17 13:35:40 2017 -0800

--
 CHANGES.txt |  4 
 .../cassandra/net/OutboundTcpConnection.java| 22 
 2 files changed, 22 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e2bdf997/CHANGES.txt
--
diff --cc CHANGES.txt
index ab345e6,1b83501..af06a02
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,44 -1,7 +1,48 @@@
 -2.2.10
++3.0.12
++Merged from 2.2
+  * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
+ 
 -2.2.9
 +3.0.11
 + * Use keyspace replication settings on system.size_estimates table 
(CASSANDRA-9639)
 + * Add vm.max_map_count StartupCheck (CASSANDRA-13008)
 + * Hint related logging should include the IP address of the destination in 
addition to 
 +   host ID (CASSANDRA-13205)
 + * Reloading logback.xml does not work (CASSANDRA-13173)
 + * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
 + * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
 + * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)
 + * Abort or retry on failed hints delivery (CASSANDRA-13124)
 + * Fix handling of partition with partition-level deletion plus
 +   live rows in sstabledump (CASSANDRA-13177)
 + * Provide user workaround when system_schema.columns does not contain entries
 +   for a table that's in system_schema.tables (CASSANDRA-13180)
 + * Dump threads when unit tests time out (CASSANDRA-13117)
 + * Better error when modifying function permissions without explicit keyspace 
(CASSANDRA-12925)
 + * Indexer is not correctly invoked when building indexes over sstables 
(CASSANDRA-13075)
 + * Read repair is not blocking repair to finish in foreground repair 
(CASSANDRA-13115)
 + * Stress daemon help is incorrect (CASSANDRA-12563)
 + * Remove ALTER TYPE support (CASSANDRA-12443)
 + * Fix assertion for certain legacy range tombstone pattern (CASSANDRA-12203)
 + * Set javac encoding to utf-8 (CASSANDRA-11077)
 + * Replace empty strings with null values if they cannot be converted 
(CASSANDRA-12794)
 + * Fixed flacky SSTableRewriterTest: check file counts before calling 
validateCFS (CASSANDRA-12348)
 + * Fix deserialization of 2.x DeletedCells (CASSANDRA-12620)
 + * Add parent repair session id to anticompaction log message 
(CASSANDRA-12186)
 + * Improve contention handling on failure to acquire MV lock for streaming 
and hints (CASSANDRA-12905)
 + * Fix DELETE and UPDATE queries with empty IN restrictions (CASSANDRA-12829)
 + * Mark MVs as built after successful bootstrap (CASSANDRA-12984)
 + * Estimated TS drop-time histogram updated with Cell.NO_DELETION_TIME 
(CASSANDRA-13040)
 + * Nodetool compactionstats fails with NullPointerException (CASSANDRA-13021)
 + * Thread local pools never cleaned up (CASSANDRA-13033)
 + * Set RPC_READY to false when draining or if a node is marked as shutdown 
(CASSANDRA-12781)
 + * Make sure sstables only get committed when it's safe to discard commit log 
records (CASSANDRA-12956)
 + * Reject default_time_to_live option when creating or altering MVs 
(CASSANDRA-12868)
 + * Nodetool should use a more sane max heap size (CASSANDRA-12739)
 + * LocalToken ensures token values are cloned on heap (CASSANDRA-12651)
 + * AnticompactionRequestSerializer serializedSize is incorrect 
(CASSANDRA-12934)
 + * Prevent reloading of logback.xml from UDF sandbox (CASSANDRA-12535)
 + * Reenable HeapPool (CASSANDRA-12900)
 +Merged from 2.2:
   * Coalescing strategy sleeps too much and shouldn't be enabled by default 
(CASSANDRA-13090)
   * Fix negative mean latency metric (CASSANDRA-12876)
   * Use only one file pointer when creating commitlog segments 
(CASSANDRA-12539)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e2bdf997/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
--

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

[jasobrown]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.0
Commit: e2bdf9971da514d260176663bbd8cc24f2d60049
Parents: 338226e 8556a2b
Author: Jason Brown 
Authored: Fri Feb 17 13:33:46 2017 -0800
Committer: Jason Brown 
Committed: Fri Feb 17 13:35:40 2017 -0800

--
 CHANGES.txt |  4 
 .../cassandra/net/OutboundTcpConnection.java| 22 
 2 files changed, 22 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e2bdf997/CHANGES.txt
--
diff --cc CHANGES.txt
index ab345e6,1b83501..af06a02
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,44 -1,7 +1,48 @@@
 -2.2.10
++3.0.12
++Merged from 2.2
+  * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
+ 
 -2.2.9
 +3.0.11
 + * Use keyspace replication settings on system.size_estimates table 
(CASSANDRA-9639)
 + * Add vm.max_map_count StartupCheck (CASSANDRA-13008)
 + * Hint related logging should include the IP address of the destination in 
addition to 
 +   host ID (CASSANDRA-13205)
 + * Reloading logback.xml does not work (CASSANDRA-13173)
 + * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
 + * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
 + * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)
 + * Abort or retry on failed hints delivery (CASSANDRA-13124)
 + * Fix handling of partition with partition-level deletion plus
 +   live rows in sstabledump (CASSANDRA-13177)
 + * Provide user workaround when system_schema.columns does not contain entries
 +   for a table that's in system_schema.tables (CASSANDRA-13180)
 + * Dump threads when unit tests time out (CASSANDRA-13117)
 + * Better error when modifying function permissions without explicit keyspace 
(CASSANDRA-12925)
 + * Indexer is not correctly invoked when building indexes over sstables 
(CASSANDRA-13075)
 + * Read repair is not blocking repair to finish in foreground repair 
(CASSANDRA-13115)
 + * Stress daemon help is incorrect (CASSANDRA-12563)
 + * Remove ALTER TYPE support (CASSANDRA-12443)
 + * Fix assertion for certain legacy range tombstone pattern (CASSANDRA-12203)
 + * Set javac encoding to utf-8 (CASSANDRA-11077)
 + * Replace empty strings with null values if they cannot be converted 
(CASSANDRA-12794)
 + * Fixed flacky SSTableRewriterTest: check file counts before calling 
validateCFS (CASSANDRA-12348)
 + * Fix deserialization of 2.x DeletedCells (CASSANDRA-12620)
 + * Add parent repair session id to anticompaction log message 
(CASSANDRA-12186)
 + * Improve contention handling on failure to acquire MV lock for streaming 
and hints (CASSANDRA-12905)
 + * Fix DELETE and UPDATE queries with empty IN restrictions (CASSANDRA-12829)
 + * Mark MVs as built after successful bootstrap (CASSANDRA-12984)
 + * Estimated TS drop-time histogram updated with Cell.NO_DELETION_TIME 
(CASSANDRA-13040)
 + * Nodetool compactionstats fails with NullPointerException (CASSANDRA-13021)
 + * Thread local pools never cleaned up (CASSANDRA-13033)
 + * Set RPC_READY to false when draining or if a node is marked as shutdown 
(CASSANDRA-12781)
 + * Make sure sstables only get committed when it's safe to discard commit log 
records (CASSANDRA-12956)
 + * Reject default_time_to_live option when creating or altering MVs 
(CASSANDRA-12868)
 + * Nodetool should use a more sane max heap size (CASSANDRA-12739)
 + * LocalToken ensures token values are cloned on heap (CASSANDRA-12651)
 + * AnticompactionRequestSerializer serializedSize is incorrect 
(CASSANDRA-12934)
 + * Prevent reloading of logback.xml from UDF sandbox (CASSANDRA-12535)
 + * Reenable HeapPool (CASSANDRA-12900)
 +Merged from 2.2:
   * Coalescing strategy sleeps too much and shouldn't be enabled by default 
(CASSANDRA-13090)
   * Fix negative mean latency metric (CASSANDRA-12876)
   * Use only one file pointer when creating commitlog segments 
(CASSANDRA-12539)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e2bdf997/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
--

[08/10] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[jasobrown]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/cassandra-3.11
Commit: 3f89d2446d35021c06a294fb418cb46d9d4aa95e
Parents: cc405c0 e2bdf99
Author: Jason Brown 
Authored: Fri Feb 17 13:36:24 2017 -0800
Committer: Jason Brown 
Committed: Fri Feb 17 13:37:49 2017 -0800

--
 CHANGES.txt |  1 +
 .../cassandra/net/OutboundTcpConnection.java| 22 
 2 files changed, 19 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f89d244/CHANGES.txt
--
diff --cc CHANGES.txt
index 1a9ce2d,af06a02..45098ee
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -19,131 -16,6 +19,132 @@@ Merged from 3.0
 live rows in sstabledump (CASSANDRA-13177)
   * Provide user workaround when system_schema.columns does not contain entries
 for a table that's in system_schema.tables (CASSANDRA-13180)
 +Merged from 2.2:
++ * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
 + * Fix negative mean latency metric (CASSANDRA-12876)
 + * Use only one file pointer when creating commitlog segments 
(CASSANDRA-12539)
 +Merged from 2.1:
 + * Use portable stderr for java error in startup (CASSANDRA-13211)
 + * Fix Thread Leak in OutboundTcpConnection (CASSANDRA-13204)
 + * Coalescing strategy can enter infinite loop (CASSANDRA-13159)
 +
 +3.10
 + * Fix secondary index queries regression (CASSANDRA-13013)
 + * Add duration type to the protocol V5 (CASSANDRA-12850)
 + * Fix duration type validation (CASSANDRA-13143)
 + * 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)
 + * Use correct bounds for all-data range when filtering (CASSANDRA-12666)
 + * Remove timing window in test case (CASSANDRA-12875)
 + * Resolve unit testing without JCE security libraries installed 
(CASSANDRA-12945)
 + * Fix inconsistencies in cassandra-stress load balancing policy 
(CASSANDRA-12919)
 + * Fix validation of non-frozen UDT cells (CASSANDRA-12916)
 + * Don't shut down socket input/output on StreamSession (CASSANDRA-12903)
 + * Fix Murmur3PartitionerTest (CASSANDRA-12858)
 + * Move cqlsh syntax rules into separate module and allow easier 
customization (CASSANDRA-12897)
 + * Fix CommitLogSegmentManagerTest (CASSANDRA-12283)
 + * Fix cassandra-stress truncate option (CASSANDRA-12695)
 + * Fix crossNode value when receiving messages (CASSANDRA-12791)
 + * Don't load MX4J beans twice (CASSANDRA-12869)
 + * Extend native protocol request flags, add versions to SUPPORTED, and 
introduce ProtocolVersion enum (CASSANDRA-12838)
 + * Set JOINING mode when running pre-join tasks (CASSANDRA-12836)
 + * remove net.mintern.primitive library due to license issue (CASSANDRA-12845)
 + * Properly format IPv6 addresses when logging JMX service URL 
(CASSANDRA-12454)
 + * Optimize the vnode allocation for single replica per DC (CASSANDRA-12777)
 + * Use non-token restrictions for bounds when token restrictions are 
overridden (CASSANDRA-12419)
 + * Fix CQLSH auto completion for PER PARTITION LIMIT (CASSANDRA-12803)
 + * Use different build directories for Eclipse and Ant (CASSANDRA-12466)
 + * Avoid potential AttributeError in cqlsh due to no table metadata 
(CASSANDRA-12815)
 + * Fix RandomReplicationAwareTokenAllocatorTest.testExistingCluster 
(CASSANDRA-12812)
 + * Upgrade commons-codec to 1.9 (CASSANDRA-12790)
 + * Make the fanout size for LeveledCompactionStrategy to be configurable 
(CASSANDRA-11550)
 + * Add duration data type (CASSANDRA-11873)
 + * Fix timeout in ReplicationAwareTokenAllocatorTest (CASSANDRA-12784)
 + * Improve sum aggregate functions (CASSANDRA-12417)
 + * Make cassandra.yaml docs for batch_size_*_threshold_in_kb reflect changes 
in CASSANDRA-10876 (CASSANDRA-12761)
 + * cqlsh fails to format collections when using aliases (CASSANDRA-11534)
 + * Check for hash conflicts in prepared statements (CASSANDRA-12733)
 + * Exit query parsing upon first error (CASSANDRA-12598)
 + * Fix cassandra-stress to use single seed in UUID generation 
(CASSANDRA-12729)
 + * CQLSSTableWriter does not allow Update statement (CASSANDRA-12450)
 + * Config class uses boxed types but DD exposes primitive types 
(CASSANDRA-12199)
 + * Add pre- and post-shutdown hooks to Storage Service (CASSANDRA-12461)
 + * Add hint delivery metrics 

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

[jasobrown]

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/c718bfff
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c718bfff
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c718bfff

Branch: refs/heads/trunk
Commit: c718bfff9a27e23ec1b31fcb81f3b65d134936d1
Parents: aea8bbf 3f89d24
Author: Jason Brown 
Authored: Fri Feb 17 13:38:17 2017 -0800
Committer: Jason Brown 
Committed: Fri Feb 17 13:39:05 2017 -0800

--
 CHANGES.txt |  1 +
 .../cassandra/net/OutboundTcpConnection.java| 22 
 2 files changed, 19 insertions(+), 4 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c718bfff/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
--
diff --cc src/java/org/apache/cassandra/net/OutboundTcpConnection.java
index 69480df,a0ed270..feff527
--- a/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
+++ b/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
@@@ -439,10 -438,10 +439,8 @@@ public class OutboundTcpConnection exte
  int maxTargetVersion = handshakeVersion(in);
  if (maxTargetVersion == NO_VERSION)
  {
 -// no version is returned, so disconnect an try again: we 
will either get
 -// a different target version (targetVersion < 
MessagingService.VERSION_12)
 -// or if the same version the handshake will finally 
succeed
 +// no version is returned, so disconnect an try again
  logger.trace("Target max version is {}; no version 
information yet, will retry", maxTargetVersion);
- if 
(DatabaseDescriptor.getSeeds().contains(poolReference.endPoint()))
- logger.warn("Seed gossip version is {}; will not 
connect with that version", maxTargetVersion);
  disconnect();
  continue;
  }

[02/10] cassandra git commit: Exceptions encountered calling getSeeds() breaks OTC thread

[jasobrown]

Exceptions encountered calling getSeeds() breaks OTC thread

patch by jjirsa, reviewed by jasobrown for CASSANDRA-13018


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

Branch: refs/heads/cassandra-3.0
Commit: 8556a2b932046ee0633b0e619d3dd04b57bb653e
Parents: 70a08f1
Author: Jason Brown 
Authored: Fri Feb 17 11:03:26 2017 -0800
Committer: Jason Brown 
Committed: Fri Feb 17 13:33:18 2017 -0800

--
 CHANGES.txt |  3 +++
 .../cassandra/net/OutboundTcpConnection.java| 22 
 2 files changed, 21 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8556a2b9/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d53457f..1b83501 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,6 @@
+2.2.10
+ * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
+
 2.2.9
  * Coalescing strategy sleeps too much and shouldn't be enabled by default 
(CASSANDRA-13090)
  * Fix negative mean latency metric (CASSANDRA-12876)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8556a2b9/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
--
diff --git a/src/java/org/apache/cassandra/net/OutboundTcpConnection.java 
b/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
index 6ec78a4..8baac75 100644
--- a/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
+++ b/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
@@ -434,8 +434,6 @@ public class OutboundTcpConnection extends Thread
 // a different target version (targetVersion < 
MessagingService.VERSION_12)
 // or if the same version the handshake will finally 
succeed
 logger.trace("Target max version is {}; no version 
information yet, will retry", maxTargetVersion);
-if 
(DatabaseDescriptor.getSeeds().contains(poolReference.endPoint()))
-logger.warn("Seed gossip version is {}; will not 
connect with that version", maxTargetVersion);
 disconnect();
 continue;
 }
@@ -447,8 +445,24 @@ public class OutboundTcpConnection extends Thread
 if (targetVersion > maxTargetVersion)
 {
 logger.trace("Target max version is {}; will reconnect 
with that version", maxTargetVersion);
-disconnect();
-return false;
+try
+{
+if 
(DatabaseDescriptor.getSeeds().contains(poolReference.endPoint()))
+logger.warn("Seed gossip version is {}; will not 
connect with that version", maxTargetVersion);
+}
+catch (Throwable e)
+{
+// If invalid yaml has been added to the config since 
startup, getSeeds() will throw an AssertionError
+// Additionally, third party seed providers may throw 
exceptions if network is flakey
+// Regardless of what's thrown, we must catch it, 
disconnect, and try again
+JVMStabilityInspector.inspectThrowable(e);
+logger.warn("Configuration error prevented outbound 
connection: {}", e.getLocalizedMessage());
+}
+finally
+{
+disconnect();
+return false;
+}
 }
 
 if (targetVersion < maxTargetVersion && targetVersion < 
MessagingService.current_version)

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

[jasobrown]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/trunk
Commit: e2bdf9971da514d260176663bbd8cc24f2d60049
Parents: 338226e 8556a2b
Author: Jason Brown 
Authored: Fri Feb 17 13:33:46 2017 -0800
Committer: Jason Brown 
Committed: Fri Feb 17 13:35:40 2017 -0800

--
 CHANGES.txt |  4 
 .../cassandra/net/OutboundTcpConnection.java| 22 
 2 files changed, 22 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e2bdf997/CHANGES.txt
--
diff --cc CHANGES.txt
index ab345e6,1b83501..af06a02
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,44 -1,7 +1,48 @@@
 -2.2.10
++3.0.12
++Merged from 2.2
+  * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
+ 
 -2.2.9
 +3.0.11
 + * Use keyspace replication settings on system.size_estimates table 
(CASSANDRA-9639)
 + * Add vm.max_map_count StartupCheck (CASSANDRA-13008)
 + * Hint related logging should include the IP address of the destination in 
addition to 
 +   host ID (CASSANDRA-13205)
 + * Reloading logback.xml does not work (CASSANDRA-13173)
 + * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
 + * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
 + * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)
 + * Abort or retry on failed hints delivery (CASSANDRA-13124)
 + * Fix handling of partition with partition-level deletion plus
 +   live rows in sstabledump (CASSANDRA-13177)
 + * Provide user workaround when system_schema.columns does not contain entries
 +   for a table that's in system_schema.tables (CASSANDRA-13180)
 + * Dump threads when unit tests time out (CASSANDRA-13117)
 + * Better error when modifying function permissions without explicit keyspace 
(CASSANDRA-12925)
 + * Indexer is not correctly invoked when building indexes over sstables 
(CASSANDRA-13075)
 + * Read repair is not blocking repair to finish in foreground repair 
(CASSANDRA-13115)
 + * Stress daemon help is incorrect (CASSANDRA-12563)
 + * Remove ALTER TYPE support (CASSANDRA-12443)
 + * Fix assertion for certain legacy range tombstone pattern (CASSANDRA-12203)
 + * Set javac encoding to utf-8 (CASSANDRA-11077)
 + * Replace empty strings with null values if they cannot be converted 
(CASSANDRA-12794)
 + * Fixed flacky SSTableRewriterTest: check file counts before calling 
validateCFS (CASSANDRA-12348)
 + * Fix deserialization of 2.x DeletedCells (CASSANDRA-12620)
 + * Add parent repair session id to anticompaction log message 
(CASSANDRA-12186)
 + * Improve contention handling on failure to acquire MV lock for streaming 
and hints (CASSANDRA-12905)
 + * Fix DELETE and UPDATE queries with empty IN restrictions (CASSANDRA-12829)
 + * Mark MVs as built after successful bootstrap (CASSANDRA-12984)
 + * Estimated TS drop-time histogram updated with Cell.NO_DELETION_TIME 
(CASSANDRA-13040)
 + * Nodetool compactionstats fails with NullPointerException (CASSANDRA-13021)
 + * Thread local pools never cleaned up (CASSANDRA-13033)
 + * Set RPC_READY to false when draining or if a node is marked as shutdown 
(CASSANDRA-12781)
 + * Make sure sstables only get committed when it's safe to discard commit log 
records (CASSANDRA-12956)
 + * Reject default_time_to_live option when creating or altering MVs 
(CASSANDRA-12868)
 + * Nodetool should use a more sane max heap size (CASSANDRA-12739)
 + * LocalToken ensures token values are cloned on heap (CASSANDRA-12651)
 + * AnticompactionRequestSerializer serializedSize is incorrect 
(CASSANDRA-12934)
 + * Prevent reloading of logback.xml from UDF sandbox (CASSANDRA-12535)
 + * Reenable HeapPool (CASSANDRA-12900)
 +Merged from 2.2:
   * Coalescing strategy sleeps too much and shouldn't be enabled by default 
(CASSANDRA-13090)
   * Fix negative mean latency metric (CASSANDRA-12876)
   * Use only one file pointer when creating commitlog segments 
(CASSANDRA-12539)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e2bdf997/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
--

[09/10] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[jasobrown]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/trunk
Commit: 3f89d2446d35021c06a294fb418cb46d9d4aa95e
Parents: cc405c0 e2bdf99
Author: Jason Brown 
Authored: Fri Feb 17 13:36:24 2017 -0800
Committer: Jason Brown 
Committed: Fri Feb 17 13:37:49 2017 -0800

--
 CHANGES.txt |  1 +
 .../cassandra/net/OutboundTcpConnection.java| 22 
 2 files changed, 19 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f89d244/CHANGES.txt
--
diff --cc CHANGES.txt
index 1a9ce2d,af06a02..45098ee
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -19,131 -16,6 +19,132 @@@ Merged from 3.0
 live rows in sstabledump (CASSANDRA-13177)
   * Provide user workaround when system_schema.columns does not contain entries
 for a table that's in system_schema.tables (CASSANDRA-13180)
 +Merged from 2.2:
++ * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
 + * Fix negative mean latency metric (CASSANDRA-12876)
 + * Use only one file pointer when creating commitlog segments 
(CASSANDRA-12539)
 +Merged from 2.1:
 + * Use portable stderr for java error in startup (CASSANDRA-13211)
 + * Fix Thread Leak in OutboundTcpConnection (CASSANDRA-13204)
 + * Coalescing strategy can enter infinite loop (CASSANDRA-13159)
 +
 +3.10
 + * Fix secondary index queries regression (CASSANDRA-13013)
 + * Add duration type to the protocol V5 (CASSANDRA-12850)
 + * Fix duration type validation (CASSANDRA-13143)
 + * 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)
 + * Use correct bounds for all-data range when filtering (CASSANDRA-12666)
 + * Remove timing window in test case (CASSANDRA-12875)
 + * Resolve unit testing without JCE security libraries installed 
(CASSANDRA-12945)
 + * Fix inconsistencies in cassandra-stress load balancing policy 
(CASSANDRA-12919)
 + * Fix validation of non-frozen UDT cells (CASSANDRA-12916)
 + * Don't shut down socket input/output on StreamSession (CASSANDRA-12903)
 + * Fix Murmur3PartitionerTest (CASSANDRA-12858)
 + * Move cqlsh syntax rules into separate module and allow easier 
customization (CASSANDRA-12897)
 + * Fix CommitLogSegmentManagerTest (CASSANDRA-12283)
 + * Fix cassandra-stress truncate option (CASSANDRA-12695)
 + * Fix crossNode value when receiving messages (CASSANDRA-12791)
 + * Don't load MX4J beans twice (CASSANDRA-12869)
 + * Extend native protocol request flags, add versions to SUPPORTED, and 
introduce ProtocolVersion enum (CASSANDRA-12838)
 + * Set JOINING mode when running pre-join tasks (CASSANDRA-12836)
 + * remove net.mintern.primitive library due to license issue (CASSANDRA-12845)
 + * Properly format IPv6 addresses when logging JMX service URL 
(CASSANDRA-12454)
 + * Optimize the vnode allocation for single replica per DC (CASSANDRA-12777)
 + * Use non-token restrictions for bounds when token restrictions are 
overridden (CASSANDRA-12419)
 + * Fix CQLSH auto completion for PER PARTITION LIMIT (CASSANDRA-12803)
 + * Use different build directories for Eclipse and Ant (CASSANDRA-12466)
 + * Avoid potential AttributeError in cqlsh due to no table metadata 
(CASSANDRA-12815)
 + * Fix RandomReplicationAwareTokenAllocatorTest.testExistingCluster 
(CASSANDRA-12812)
 + * Upgrade commons-codec to 1.9 (CASSANDRA-12790)
 + * Make the fanout size for LeveledCompactionStrategy to be configurable 
(CASSANDRA-11550)
 + * Add duration data type (CASSANDRA-11873)
 + * Fix timeout in ReplicationAwareTokenAllocatorTest (CASSANDRA-12784)
 + * Improve sum aggregate functions (CASSANDRA-12417)
 + * Make cassandra.yaml docs for batch_size_*_threshold_in_kb reflect changes 
in CASSANDRA-10876 (CASSANDRA-12761)
 + * cqlsh fails to format collections when using aliases (CASSANDRA-11534)
 + * Check for hash conflicts in prepared statements (CASSANDRA-12733)
 + * Exit query parsing upon first error (CASSANDRA-12598)
 + * Fix cassandra-stress to use single seed in UUID generation 
(CASSANDRA-12729)
 + * CQLSSTableWriter does not allow Update statement (CASSANDRA-12450)
 + * Config class uses boxed types but DD exposes primitive types 
(CASSANDRA-12199)
 + * Add pre- and post-shutdown hooks to Storage Service (CASSANDRA-12461)
 + * Add hint delivery metrics (CASSANDRA-12693)
 + * 

[01/10] cassandra git commit: Exceptions encountered calling getSeeds() breaks OTC thread

[jasobrown]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 70a08f1c3 -> 8556a2b93
  refs/heads/cassandra-3.0 338226e04 -> e2bdf9971
  refs/heads/cassandra-3.11 cc405c0b2 -> 3f89d2446
  refs/heads/trunk aea8bbff3 -> c718bfff9


Exceptions encountered calling getSeeds() breaks OTC thread

patch by jjirsa, reviewed by jasobrown for CASSANDRA-13018


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

Branch: refs/heads/cassandra-2.2
Commit: 8556a2b932046ee0633b0e619d3dd04b57bb653e
Parents: 70a08f1
Author: Jason Brown 
Authored: Fri Feb 17 11:03:26 2017 -0800
Committer: Jason Brown 
Committed: Fri Feb 17 13:33:18 2017 -0800

--
 CHANGES.txt |  3 +++
 .../cassandra/net/OutboundTcpConnection.java| 22 
 2 files changed, 21 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8556a2b9/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d53457f..1b83501 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,6 @@
+2.2.10
+ * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
+
 2.2.9
  * Coalescing strategy sleeps too much and shouldn't be enabled by default 
(CASSANDRA-13090)
  * Fix negative mean latency metric (CASSANDRA-12876)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8556a2b9/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
--
diff --git a/src/java/org/apache/cassandra/net/OutboundTcpConnection.java 
b/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
index 6ec78a4..8baac75 100644
--- a/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
+++ b/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
@@ -434,8 +434,6 @@ public class OutboundTcpConnection extends Thread
 // a different target version (targetVersion < 
MessagingService.VERSION_12)
 // or if the same version the handshake will finally 
succeed
 logger.trace("Target max version is {}; no version 
information yet, will retry", maxTargetVersion);
-if 
(DatabaseDescriptor.getSeeds().contains(poolReference.endPoint()))
-logger.warn("Seed gossip version is {}; will not 
connect with that version", maxTargetVersion);
 disconnect();
 continue;
 }
@@ -447,8 +445,24 @@ public class OutboundTcpConnection extends Thread
 if (targetVersion > maxTargetVersion)
 {
 logger.trace("Target max version is {}; will reconnect 
with that version", maxTargetVersion);
-disconnect();
-return false;
+try
+{
+if 
(DatabaseDescriptor.getSeeds().contains(poolReference.endPoint()))
+logger.warn("Seed gossip version is {}; will not 
connect with that version", maxTargetVersion);
+}
+catch (Throwable e)
+{
+// If invalid yaml has been added to the config since 
startup, getSeeds() will throw an AssertionError
+// Additionally, third party seed providers may throw 
exceptions if network is flakey
+// Regardless of what's thrown, we must catch it, 
disconnect, and try again
+JVMStabilityInspector.inspectThrowable(e);
+logger.warn("Configuration error prevented outbound 
connection: {}", e.getLocalizedMessage());
+}
+finally
+{
+disconnect();
+return false;
+}
 }
 
 if (targetVersion < maxTargetVersion && targetVersion < 
MessagingService.current_version)

[04/10] cassandra git commit: Exceptions encountered calling getSeeds() breaks OTC thread

[jasobrown]

Exceptions encountered calling getSeeds() breaks OTC thread

patch by jjirsa, reviewed by jasobrown for CASSANDRA-13018


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

Branch: refs/heads/trunk
Commit: 8556a2b932046ee0633b0e619d3dd04b57bb653e
Parents: 70a08f1
Author: Jason Brown 
Authored: Fri Feb 17 11:03:26 2017 -0800
Committer: Jason Brown 
Committed: Fri Feb 17 13:33:18 2017 -0800

--
 CHANGES.txt |  3 +++
 .../cassandra/net/OutboundTcpConnection.java| 22 
 2 files changed, 21 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8556a2b9/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d53457f..1b83501 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,6 @@
+2.2.10
+ * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
+
 2.2.9
  * Coalescing strategy sleeps too much and shouldn't be enabled by default 
(CASSANDRA-13090)
  * Fix negative mean latency metric (CASSANDRA-12876)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8556a2b9/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
--
diff --git a/src/java/org/apache/cassandra/net/OutboundTcpConnection.java 
b/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
index 6ec78a4..8baac75 100644
--- a/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
+++ b/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
@@ -434,8 +434,6 @@ public class OutboundTcpConnection extends Thread
 // a different target version (targetVersion < 
MessagingService.VERSION_12)
 // or if the same version the handshake will finally 
succeed
 logger.trace("Target max version is {}; no version 
information yet, will retry", maxTargetVersion);
-if 
(DatabaseDescriptor.getSeeds().contains(poolReference.endPoint()))
-logger.warn("Seed gossip version is {}; will not 
connect with that version", maxTargetVersion);
 disconnect();
 continue;
 }
@@ -447,8 +445,24 @@ public class OutboundTcpConnection extends Thread
 if (targetVersion > maxTargetVersion)
 {
 logger.trace("Target max version is {}; will reconnect 
with that version", maxTargetVersion);
-disconnect();
-return false;
+try
+{
+if 
(DatabaseDescriptor.getSeeds().contains(poolReference.endPoint()))
+logger.warn("Seed gossip version is {}; will not 
connect with that version", maxTargetVersion);
+}
+catch (Throwable e)
+{
+// If invalid yaml has been added to the config since 
startup, getSeeds() will throw an AssertionError
+// Additionally, third party seed providers may throw 
exceptions if network is flakey
+// Regardless of what's thrown, we must catch it, 
disconnect, and try again
+JVMStabilityInspector.inspectThrowable(e);
+logger.warn("Configuration error prevented outbound 
connection: {}", e.getLocalizedMessage());
+}
+finally
+{
+disconnect();
+return false;
+}
 }
 
 if (targetVersion < maxTargetVersion && targetVersion < 
MessagingService.current_version)

[03/10] cassandra git commit: Exceptions encountered calling getSeeds() breaks OTC thread

[jasobrown]

Exceptions encountered calling getSeeds() breaks OTC thread

patch by jjirsa, reviewed by jasobrown for CASSANDRA-13018


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

Branch: refs/heads/cassandra-3.11
Commit: 8556a2b932046ee0633b0e619d3dd04b57bb653e
Parents: 70a08f1
Author: Jason Brown 
Authored: Fri Feb 17 11:03:26 2017 -0800
Committer: Jason Brown 
Committed: Fri Feb 17 13:33:18 2017 -0800

--
 CHANGES.txt |  3 +++
 .../cassandra/net/OutboundTcpConnection.java| 22 
 2 files changed, 21 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8556a2b9/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d53457f..1b83501 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,6 @@
+2.2.10
+ * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
+
 2.2.9
  * Coalescing strategy sleeps too much and shouldn't be enabled by default 
(CASSANDRA-13090)
  * Fix negative mean latency metric (CASSANDRA-12876)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8556a2b9/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
--
diff --git a/src/java/org/apache/cassandra/net/OutboundTcpConnection.java 
b/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
index 6ec78a4..8baac75 100644
--- a/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
+++ b/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
@@ -434,8 +434,6 @@ public class OutboundTcpConnection extends Thread
 // a different target version (targetVersion < 
MessagingService.VERSION_12)
 // or if the same version the handshake will finally 
succeed
 logger.trace("Target max version is {}; no version 
information yet, will retry", maxTargetVersion);
-if 
(DatabaseDescriptor.getSeeds().contains(poolReference.endPoint()))
-logger.warn("Seed gossip version is {}; will not 
connect with that version", maxTargetVersion);
 disconnect();
 continue;
 }
@@ -447,8 +445,24 @@ public class OutboundTcpConnection extends Thread
 if (targetVersion > maxTargetVersion)
 {
 logger.trace("Target max version is {}; will reconnect 
with that version", maxTargetVersion);
-disconnect();
-return false;
+try
+{
+if 
(DatabaseDescriptor.getSeeds().contains(poolReference.endPoint()))
+logger.warn("Seed gossip version is {}; will not 
connect with that version", maxTargetVersion);
+}
+catch (Throwable e)
+{
+// If invalid yaml has been added to the config since 
startup, getSeeds() will throw an AssertionError
+// Additionally, third party seed providers may throw 
exceptions if network is flakey
+// Regardless of what's thrown, we must catch it, 
disconnect, and try again
+JVMStabilityInspector.inspectThrowable(e);
+logger.warn("Configuration error prevented outbound 
connection: {}", e.getLocalizedMessage());
+}
+finally
+{
+disconnect();
+return false;
+}
 }
 
 if (targetVersion < maxTargetVersion && targetVersion < 
MessagingService.current_version)

[jira] [Commented] (CASSANDRA-13238) Add actual row output to assertEmpty error message

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13238:
-

+1

> Add actual row output to assertEmpty error message
> --
>
> Key: CASSANDRA-13238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13238
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Alex Petrov
>Priority: Trivial
>
> We have several issues popping up every now and then that are hard to debug 
> and the test failure messages aren't entirely helpful, for example: 
> {code}
> java.lang.AssertionError: Expected empty result but got 1 rows:
> {code}
> It could be much better if we could have an actual output (what exactly the 
> row that got returned appended to it:
> {code}
> java.lang.AssertionError: Expected empty result but got 1 rows: 
> [row(value=null)]
> {code}
> The nice side-effect of this change is that now we will have a helper method 
> that can nicely turn an {{UntypedResultSet}} into {{String}} (I apologise if 
> I did overlooked one).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (CASSANDRA-12811) testall failure in org.apache.cassandra.cql3.validation.operations.DeleteTest.testDeleteWithOneClusteringColumns-compression

[Alex Petrov (JIRA)]

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

Alex Petrov edited comment on CASSANDRA-12811 at 2/17/17 9:17 PM:
--

Was able to reproduce it several times and get some more information, although 
so far not much clear. It happens on memtable writes, noncompact tables (trying 
to reproduce for other settings as well). Although weirdly enough the 
tombstones are where they have to be:

{code}
INFO  [main] 2017-02-17 18:36:38,687 partition.partitionKey() = 
DecoratedKey(-3485513579396041028, )
INFO  [main] 2017-02-17 18:36:38,687 row = 
org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@418ee592
INFO  [main] 2017-02-17 18:36:38,687 ByteBufferUtil.bytesToHex(buffer) = 
0001
INFO  [main] 2017-02-17 18:36:38,687 row = 
org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@8a66b81f
INFO  [main] 2017-02-17 18:36:38,687 ByteBufferUtil.bytesToHex(buffer) = 
0001
{code}

What's weird here though is that row itself isn't even here. Although it seems 
to be to re-using byte buffers again...


was (Author: ifesdjeen):
So far I could not reproduce the issue. It also seems that over the last 60+ 
runs it didn't fail once.

> testall failure in 
> org.apache.cassandra.cql3.validation.operations.DeleteTest.testDeleteWithOneClusteringColumns-compression
> 
>
> Key: CASSANDRA-12811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12811
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Alex Petrov
>  Labels: test-failure
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.X_testall/34/testReport/org.apache.cassandra.cql3.validation.operations/DeleteTest/testDeleteWithOneClusteringColumns_compression/
> {code}
> Error Message
> Expected empty result but got 1 rows
> {code}
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Expected empty result but got 1 rows
>   at org.apache.cassandra.cql3.CQLTester.assertEmpty(CQLTester.java:1089)
>   at 
> org.apache.cassandra.cql3.validation.operations.DeleteTest.testDeleteWithOneClusteringColumns(DeleteTest.java:463)
>   at 
> org.apache.cassandra.cql3.validation.operations.DeleteTest.testDeleteWithOneClusteringColumns(DeleteTest.java:427)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-13236:
-

+1 on what [~Stefania] said.

Sometimes it's also useful to compare the outputs from the old and new 
sstables, might be helpful to understand how to fix the upgrade path.

If you can't show the sstables, you could also try hex-dumping the part of 
buffer on the exception (with {{ByteBufferUtil#bytesAsHex}}), this way you can 
understand if the sstable is completely off, or it's just this single byte is 
written incorrectly. Sometimes the offsets might be wrong, which leads into 
reader jumping and starting reading from the wrong point in the sstable. 

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> {code}
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [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.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> 

[jira] [Updated] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-13236:

Description: 
After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like this:

{code}
ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
Unexpected exception during request; channel = [id: 0xa8b98684, 
/10.0.70.104:56814 => /10.0.80.24:9042]
java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
partition (isStatic flag set): 160
at 
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
 [apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
 [apache-cassandra-3.0.10.jar:3.0.10]
at 
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
 [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.access$700(AbstractChannelHandlerContext.java:32)
 [netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
 [netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_72]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
 [apache-cassandra-3.0.10.jar:3.0.10]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
[apache-cassandra-3.0.10.jar:3.0.10]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
(isStatic flag set): 160
at 
org.apache.cassandra.db.rows.UnfilteredSerializer.deserialize(UnfilteredSerializer.java:374)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:217)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
... 23 common frames omitted
{code}

  was:
After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like this:
ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
Unexpected exception during request; channel = [id: 0xa8b98684, 
/10.0.70.104:56814 => /10.0.80.24:9042]
java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
partition (isStatic flag set): 160
at 
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 

[jira] [Updated] (CASSANDRA-13238) Add actual row output to assertEmpty error message

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-13238:

Status: Patch Available  (was: Open)

And a trivial patch to fix it (without CI, but hope it's also not necessary): 

[3.0|https://github.com/ifesdjeen/cassandra/tree/12811-3.0] would merge clean 
up to trunk.

> Add actual row output to assertEmpty error message
> --
>
> Key: CASSANDRA-13238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13238
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Alex Petrov
>Priority: Trivial
>
> We have several issues popping up every now and then that are hard to debug 
> and the test failure messages aren't entirely helpful, for example: 
> {code}
> java.lang.AssertionError: Expected empty result but got 1 rows:
> {code}
> It could be much better if we could have an actual output (what exactly the 
> row that got returned appended to it:
> {code}
> java.lang.AssertionError: Expected empty result but got 1 rows: 
> [row(value=null)]
> {code}
> The nice side-effect of this change is that now we will have a helper method 
> that can nicely turn an {{UntypedResultSet}} into {{String}} (I apologise if 
> I did overlooked one).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CASSANDRA-13238) Add actual row output to assertEmpty error message

[Alex Petrov (JIRA)]

Alex Petrov created CASSANDRA-13238:
---

 Summary: Add actual row output to assertEmpty error message
 Key: CASSANDRA-13238
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13238
 Project: Cassandra
  Issue Type: Improvement
Reporter: Alex Petrov
Priority: Trivial


We have several issues popping up every now and then that are hard to debug and 
the test failure messages aren't entirely helpful, for example: 

{code}
java.lang.AssertionError: Expected empty result but got 1 rows:
{code}

It could be much better if we could have an actual output (what exactly the row 
that got returned appended to it:

{code}
java.lang.AssertionError: Expected empty result but got 1 rows: 
[row(value=null)]
{code}

The nice side-effect of this change is that now we will have a helper method 
that can nicely turn an {{UntypedResultSet}} into {{String}} (I apologise if I 
did overlooked one).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-11983) Migration task failed to complete

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-11983:


Strongly suspect this is a duplicate of CASSANDRA-12653 , which is 
patch-available, for anyone who is desperate for a fix (should be reviewed and 
committed soon).

> Migration task failed to complete
> -
>
> Key: CASSANDRA-11983
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11983
> Project: Cassandra
>  Issue Type: Bug
>  Components: Lifecycle
> Environment: Docker / Kubernetes running
> Linux cassandra-21 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) 
> x86_64 GNU/Linux
> openjdk version "1.8.0_91"
> OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-1~bpo8+1-b14)
> OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
> Cassnadra 3.5 installed from 
> deb-src http://www.apache.org/dist/cassandra/debian 35x main
>Reporter: Chris Love
>Assignee: Jeff Jirsa
> Fix For: 3.0.x, 3.11.x
>
> Attachments: cass.log
>
>
> When nodes are boostrapping I am getting mulitple errors: "Migration task 
> failed to complete", from MigrationManager.java
> The errors increase as more nodes are added to the ring, as I am creating a 
> ring of 1k nodes.
> Cassandra yaml i here 
> https://github.com/k8s-for-greeks/gpmr/blob/3d50ff91a139b9c4a7a26eda0fb4dcf9a008fbed/pet-race-devops/docker/cassandra-debian/files/cassandra.yaml



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13018) Exceptions encountered calling getSeeds() breaks OTC thread

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13018:


Changes lgtm!


> Exceptions encountered calling getSeeds() breaks OTC thread
> ---
>
> Key: CASSANDRA-13018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13018
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>  Labels: lhf
> Attachments: 
> 0001-Better-handle-config-errors-during-outbound-connecti.patch
>
>
> OutboundTcpConnection.connect() calls getSeeds(). If getSeeds() throws an 
> exception (for example, DD/Config invalid yaml error), messaging thread(s) 
> break(s). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13018) Exceptions encountered calling getSeeds() breaks OTC thread

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13018:
-

fixed all 4 branches

> Exceptions encountered calling getSeeds() breaks OTC thread
> ---
>
> Key: CASSANDRA-13018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13018
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>  Labels: lhf
> Attachments: 
> 0001-Better-handle-config-errors-during-outbound-connecti.patch
>
>
> OutboundTcpConnection.connect() calls getSeeds(). If getSeeds() throws an 
> exception (for example, DD/Config invalid yaml error), messaging thread(s) 
> break(s). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13018) Exceptions encountered calling getSeeds() breaks OTC thread

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13018:
-

(facepalm) - fixing now. Thanks for catching that!

> Exceptions encountered calling getSeeds() breaks OTC thread
> ---
>
> Key: CASSANDRA-13018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13018
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>  Labels: lhf
> Attachments: 
> 0001-Better-handle-config-errors-during-outbound-connecti.patch
>
>
> OutboundTcpConnection.connect() calls getSeeds(). If getSeeds() throws an 
> exception (for example, DD/Config invalid yaml error), messaging thread(s) 
> break(s). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13018) Exceptions encountered calling getSeeds() breaks OTC thread

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13018:


[~jasobrown] You've corrected the logging bug, but left the broken OTC thread 
issue - that is, in your branches ( 
https://github.com/jasobrown/cassandra/blob/abe3db6431b428a687bd918027c2d042f8986bbc/src/java/org/apache/cassandra/net/OutboundTcpConnection.java#L437
 for example ), you left the old call to getSeeds() unprotected, which can 
still throw and break.



> Exceptions encountered calling getSeeds() breaks OTC thread
> ---
>
> Key: CASSANDRA-13018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13018
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>  Labels: lhf
> Attachments: 
> 0001-Better-handle-config-errors-during-outbound-connecti.patch
>
>
> OutboundTcpConnection.connect() calls getSeeds(). If getSeeds() throws an 
> exception (for example, DD/Config invalid yaml error), messaging thread(s) 
> break(s). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-11471) Add SASL mechanism negotiation to the native protocol

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-11471:
---
Reviewer: Ariel Weisberg

> Add SASL mechanism negotiation to the native protocol
> -
>
> Key: CASSANDRA-11471
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11471
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: CQL
>Reporter: Sam Tunnicliffe
>Assignee: Ben Bromhead
>  Labels: client-impacting
> Attachments: CASSANDRA-11471
>
>
> Introducing an additional message exchange into the authentication sequence 
> would allow us to support multiple authentication schemes and [negotiation of 
> SASL mechanisms|https://tools.ietf.org/html/rfc4422#section-3.2]. 
> The current {{AUTHENTICATE}} message sent from Client to Server includes the 
> java classname of the configured {{IAuthenticator}}. This could be superceded 
> by a new message which lists the SASL mechanisms supported by the server. The 
> client would then respond with a new message which indicates it's choice of 
> mechanism.  This would allow the server to support multiple mechanisms, for 
> example enabling both {{PLAIN}} for username/password authentication and 
> {{EXTERNAL}} for a mechanism for extracting credentials from SSL 
> certificates\* (see the example in 
> [RFC-4422|https://tools.ietf.org/html/rfc4422#appendix-A]). Furthermore, the 
> server could tailor the list of supported mechanisms on a per-connection 
> basis, e.g. only offering certificate based auth to encrypted clients. 
> The client's response should include the selected mechanism and any initial 
> response data. This is mechanism-specific; the {{PLAIN}} mechanism consists 
> of a single round in which the client sends encoded credentials as the 
> initial response data and the server response indicates either success or 
> failure with no futher challenges required.
> From a protocol perspective, after the mechanism negotiation the exchange 
> would continue as in protocol v4, with one or more rounds of 
> {{AUTH_CHALLENGE}} and {{AUTH_RESPONSE}} messages, terminated by an 
> {{AUTH_SUCCESS}} sent from Server to Client upon successful authentication or 
> an {{ERROR}} on auth failure. 
> XMPP performs mechanism negotiation in this way, 
> [RFC-3920|http://tools.ietf.org/html/rfc3920#section-6] includes a good 
> overview.
> \* Note: this would require some a priori agreement between client and server 
> over the implementation of the {{EXTERNAL}} mechanism.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13018) Exceptions encountered calling getSeeds() breaks OTC thread

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13018:
-

updated the patch as per the convo with [~jjirsa], pushed the code, and running 
tests:

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


> Exceptions encountered calling getSeeds() breaks OTC thread
> ---
>
> Key: CASSANDRA-13018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13018
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>  Labels: lhf
> Attachments: 
> 0001-Better-handle-config-errors-during-outbound-connecti.patch
>
>
> OutboundTcpConnection.connect() calls getSeeds(). If getSeeds() throws an 
> exception (for example, DD/Config invalid yaml error), messaging thread(s) 
> break(s). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13018) Exceptions encountered calling getSeeds() breaks OTC thread

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-13018:

Summary: Exceptions encountered calling getSeeds() breaks OTC thread  (was: 
Exceptions encountered calling getSeeds() breaks messaging service)

> Exceptions encountered calling getSeeds() breaks OTC thread
> ---
>
> Key: CASSANDRA-13018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13018
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>  Labels: lhf
> Attachments: 
> 0001-Better-handle-config-errors-during-outbound-connecti.patch
>
>
> OutboundTcpConnection.connect() calls getSeeds(). If getSeeds() throws an 
> exception (for example, DD/Config invalid yaml error), messaging thread(s) 
> break(s). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13018) Exceptions encountered calling getSeeds() breaks messaging service

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13018:


In reading through this and talking to Jason, it does appear that the log line 
is in the wrong place.

The only way we end up in this block is if the connect fails (or rather, if 
we're unable to read the other side's version), but what we really want to 
guard against in CASSANDRA-8768 is connecting to an incompatible version - 
which is a few blocks down.


> Exceptions encountered calling getSeeds() breaks messaging service
> --
>
> Key: CASSANDRA-13018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13018
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>  Labels: lhf
> Attachments: 
> 0001-Better-handle-config-errors-during-outbound-connecti.patch
>
>
> OutboundTcpConnection.connect() calls getSeeds(). If getSeeds() throws an 
> exception (for example, DD/Config invalid yaml error), messaging thread(s) 
> break(s). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13237) Legacy deserializer can create unexpected boundary range tombstones

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-13237:

Reviewer: Branimir Lambov

> Legacy deserializer can create unexpected boundary range tombstones
> ---
>
> Key: CASSANDRA-13237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13237
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.11.x
>
>
> Most of the code don't generate a range tombstone boundary with the same 
> deletion time on both side as this is basically useless, and there is some 
> assertion in {{DataResolver}} that actually expect this. However, the 
> deserializer for legacy sstable doesn't always properly avoid their creation 
> and we can thus generate them (and break the {{DataResolver}} assertion.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-13236:
--

My guess is that either the sstable(s) are corrupt, or it's incorrectly trying 
to read a static row as a regular row, like for CASSANDRA-12582. If you don't 
have too many sstables, you could try to reproduce it with 
{{tools/bin/sstabledump}}. If you can reproduce it and can share the sstable 
with the problem, then we should be able to debug what is going on.

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [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.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserialize(UnfilteredSerializer.java:374)

[jira] [Commented] (CASSANDRA-13230) Build RPM packages for release

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-13230:


Historical precedent :)  I'm not sure of the possible differences between 
Oracle and OpenJDK javac bytecode, but will ask around. Using OpenJDK does make 
build dependency install much simpler and maintainable in the long run, so I'm 
happy to give it a shot.

> Build RPM packages for release
> --
>
> Key: CASSANDRA-13230
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13230
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Packaging
>Reporter: Michael Shuler
>Assignee: Stefan Podkowinski
>
> Currently, releases are built locally on Debian/Ubuntu based machines, 
> without native support for building RPM packages. This can be done with a 
> docker image.
> The current cassandra-release scripts are here (please, do not randomly run 
> and push tags..):
> https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git;a=tree;f=cassandra-release
> A couple incomplete docker run scripts are here:
> https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git;a=tree;f=docker-wip
> {code}
> git clone https://git-wip-us.apache.org/repos/asf/cassandra-builds.git
> {code}
> Patches for build infra improvements are welcome!
> /cc [~spo...@gmail.com] if you want to assign to yourself, I'd be happy to 
> review :)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson reassigned CASSANDRA-13153:
---

Assignee: Stefan Podkowinski

> 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
>Assignee: Stefan Podkowinski
>  Labels: Cassandra
> 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 after 2.2, if they 
> have anticompaction with full repair.
> 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.
>   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.15#6346)

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

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-13153:

Reproduced In: 2.2.8, 2.2.7  (was: 2.2.7, 2.2.8)
 Reviewer: Marcus Eriksson

> 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
>Assignee: Stefan Podkowinski
>  Labels: Cassandra
> 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 after 2.2, if they 
> have anticompaction with full repair.
> 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.
>   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.15#6346)

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

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-13153:
-

[~spo...@gmail.com] the patch LGTM, could you run CI on it?

> 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
>Assignee: Stefan Podkowinski
>  Labels: Cassandra
> 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 after 2.2, if they 
> have anticompaction with full repair.
> 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.
>   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.15#6346)

[jira] [Commented] (CASSANDRA-13130) Strange result of several list updates in a single request

[Mikhail Krupitskiy (JIRA)]

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

Mikhail Krupitskiy commented on CASSANDRA-13130:


Thank you for the clarification!
Such behaviour looks like not intuitive - will be very useful to have the 
description somewhere in Cassandra's docs. 

1) Are there any plans to make the behaviour more intuitive like "the second 
value will win because it comes last"?
2) How the following query will work (does an order matter?)?
{code}UPDATE t SET listColumn[2] = 8, listColumn = 7 + listColumn WHERE id = 
1;{code}
3) Is there a general recommendation not to combine several updates to one 
column in the single query?

> Strange result of several list updates in a single request
> --
>
> Key: CASSANDRA-13130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13130
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Mikhail Krupitskiy
>Assignee: Benjamin Lerer
>Priority: Trivial
>
> Let's assume that we have a row with the 'listColumn' column and value 
> \{1,2,3,4\}.
> For me it looks logical to expect that the following two pieces of code will 
> ends up with the same result but it isn't so.
> Code1:
> {code}
> UPDATE t SET listColumn[2] = 7, listColumn[2] = 8  WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\} 
> Actual result: listColumn=\{1,2,7,8,4\}
> Code2:
> {code}
> UPDATE t SET listColumn[2] = 7  WHERE id = 1;
> UPDATE t SET listColumn[2] = 8  WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\} 
> Actual result: listColumn=\{1,2,8,4\}
> So the question is why Code1 and Code2 give different results?
> Looks like Code1 should give the same result as Code2.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-12915) SASI: Index intersection with an empty range really inefficient

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-12915:

Status: Patch Available  (was: Open)

> SASI: Index intersection with an empty range really inefficient
> ---
>
> Key: CASSANDRA-12915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12915
> Project: Cassandra
>  Issue Type: Improvement
>  Components: sasi
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 3.11.x, 4.x
>
>
> It looks like RangeIntersectionIterator.java and be pretty inefficient in 
> some cases. Let's take the following query:
> SELECT data FROM table WHERE index1 = 'foo' AND index2 = 'bar';
> In this case:
> * index1 = 'foo' will match 2 items
> * index2 = 'bar' will match ~300k items
> On my setup, the query will take ~1 sec, most of the time being spent in 
> disk.TokenTree.getTokenAt().
> if I patch RangeIntersectionIterator so that it doesn't try to do the 
> intersection (and effectively only use 'index1') the query will run in a few 
> tenth of milliseconds.
> I see multiple solutions for that:
> * Add a static thresold to avoid the use of the index for the intersection 
> when we know it will be slow. Probably when the range size factor is very 
> small and the range size is big.
> * CASSANDRA-10765



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-12915) SASI: Index intersection with an empty range really inefficient

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-12915:

Reviewer: Alex Petrov
  Status: Open  (was: Patch Available)

> SASI: Index intersection with an empty range really inefficient
> ---
>
> Key: CASSANDRA-12915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12915
> Project: Cassandra
>  Issue Type: Improvement
>  Components: sasi
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 3.11.x, 4.x
>
>
> It looks like RangeIntersectionIterator.java and be pretty inefficient in 
> some cases. Let's take the following query:
> SELECT data FROM table WHERE index1 = 'foo' AND index2 = 'bar';
> In this case:
> * index1 = 'foo' will match 2 items
> * index2 = 'bar' will match ~300k items
> On my setup, the query will take ~1 sec, most of the time being spent in 
> disk.TokenTree.getTokenAt().
> if I patch RangeIntersectionIterator so that it doesn't try to do the 
> intersection (and effectively only use 'index1') the query will run in a few 
> tenth of milliseconds.
> I see multiple solutions for that:
> * Add a static thresold to avoid the use of the index for the intersection 
> when we know it will be slow. Probably when the range size factor is very 
> small and the range size is big.
> * CASSANDRA-10765



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[Cassandra Wiki] Update of "Committers" by MichaelShuler

[Apache Wiki]

Dear Wiki user,

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

The "Committers" page has been changed by MichaelShuler:
https://wiki.apache.org/cassandra/Committers?action=diff=72=73

  ||Avinash Lakshman ||Jan 2009 ||Facebook ||Co-author of Facebook Cassandra ||
  ||Prashant Malik ||Jan 2009 ||Facebook ||Co-author of Facebook Cassandra ||
  ||Jonathan Ellis ||Mar 2009 ||Datastax ||PMC member||
- ||Eric Evans ||Jun 2009 ||The OpenNMS Group ||PMC member, Debian packager , 
Release manager ||
+ ||Eric Evans ||Jun 2009 ||Wikimedia Foundation ||PMC member, Debian packager 
, Release manager ||
  ||Jun Rao ||Jun 2009 ||!LinkedIn ||PMC member ||
  ||Chris Goffinet ||Sept 2009 ||Twitter ||PMC member ||
  ||Johan Oskarsson ||Nov 2009 ||Twitter ||Also a 
[[http://hadoop.apache.org/|Hadoop]] committer ||
@@ -32, +32 @@

  ||Carl Yeksigian ||Jan 2016 ||Datastax ||Also a 
[[http://thrift.apache.org|Thrift]] committer ||
  ||Stefania Alborghetti ||Apr 2016 ||Datastax || ||
  ||Jeff Jirsa ||June 2016 ||Apple|| PMC member ||
- ||Nate McCall ||June 2016 ||Last Pickle|| Project chair ||
+ ||Nate !McCall ||June 2016 ||Last Pickle|| Project chair ||
  ||Jake Farrell ||June 2016 || || PMC member ||
  ||Michael Shuler ||June 2016 ||Datastax || PMC member, Release manager ||
  ||Michael Semb Wever ||June 2016 || Last Pickle || ||

[jira] [Commented] (CASSANDRA-13230) Build RPM packages for release

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski commented on CASSANDRA-13230:


The debian docker part has now been updated as well. I'm a bit curious why you 
tried to use the Oracle JDK for building? Any concerns why we shouldn't just go 
with openjdk here?

> Build RPM packages for release
> --
>
> Key: CASSANDRA-13230
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13230
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Packaging
>Reporter: Michael Shuler
>Assignee: Stefan Podkowinski
>
> Currently, releases are built locally on Debian/Ubuntu based machines, 
> without native support for building RPM packages. This can be done with a 
> docker image.
> The current cassandra-release scripts are here (please, do not randomly run 
> and push tags..):
> https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git;a=tree;f=cassandra-release
> A couple incomplete docker run scripts are here:
> https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git;a=tree;f=docker-wip
> {code}
> git clone https://git-wip-us.apache.org/repos/asf/cassandra-builds.git
> {code}
> Patches for build infra improvements are welcome!
> /cc [~spo...@gmail.com] if you want to assign to yourself, I'd be happy to 
> review :)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-12915) SASI: Index intersection with an empty range really inefficient

[Corentin Chary (JIRA)]

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

Corentin Chary updated CASSANDRA-12915:
---
Fix Version/s: 4.x
   Status: Patch Available  (was: Open)

> SASI: Index intersection with an empty range really inefficient
> ---
>
> Key: CASSANDRA-12915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12915
> Project: Cassandra
>  Issue Type: Improvement
>  Components: sasi
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 3.11.x, 4.x
>
>
> It looks like RangeIntersectionIterator.java and be pretty inefficient in 
> some cases. Let's take the following query:
> SELECT data FROM table WHERE index1 = 'foo' AND index2 = 'bar';
> In this case:
> * index1 = 'foo' will match 2 items
> * index2 = 'bar' will match ~300k items
> On my setup, the query will take ~1 sec, most of the time being spent in 
> disk.TokenTree.getTokenAt().
> if I patch RangeIntersectionIterator so that it doesn't try to do the 
> intersection (and effectively only use 'index1') the query will run in a few 
> tenth of milliseconds.
> I see multiple solutions for that:
> * Add a static thresold to avoid the use of the index for the intersection 
> when we know it will be slow. Probably when the range size factor is very 
> small and the range size is big.
> * CASSANDRA-10765



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-12915) SASI: Index intersection with an empty range really inefficient

[Corentin Chary (JIRA)]

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

Corentin Chary commented on CASSANDRA-12915:


{code}
CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': '1'}  AND durable_writes = true;

CREATE TABLE test.test (
r text PRIMARY KEY,
a text,
b text,
c text,
data text
);

CREATE CUSTOM INDEX test_a_idx ON test.test (a) USING 
'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'analyzer_class': 
'org.apache.cassandra.index.sasi.analyzer.NonTokenizingAnalyzer', 
'case_sensitive': 'true'};
CREATE CUSTOM INDEX test_c_idx ON test.test (c) USING 
'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'analyzer_class': 
'org.apache.cassandra.index.sasi.analyzer.NonTokenizingAnalyzer', 
'case_sensitive': 'true'};
CREATE CUSTOM INDEX test_b_idx ON test.test (b) USING 
'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'analyzer_class': 
'org.apache.cassandra.index.sasi.analyzer.NonTokenizingAnalyzer', 
'case_sensitive': 'true'};
{code}

{code}
$ cat > generate.py
import sys
import random

def main(args):
n = int(args[1])

for i in xrange(n):
a = '0'
b = i % 10
c = i % (n / 10) + random.randint(0, 10)
print ("%d,%s,%d,%d,%d" % (i, a, b, c, i))

if __name__ == '__main__':
main(sys.argv)
$ python generate.py 200 > test.csv
{code}
{code}
COPY test.test FROM 'test.csv'  WITH MAXBATCHSIZE = 100 AND MAXATTEMPTS = 10 
AND MAXINSERTERRORS = 99;
{code}

{code}
cqlsh> SELECT * FROM test.test WHERE a = '1' AND c = '38151' LIMIT 1 ALLOW 
FILTERING;

 r | a | b | c | data
---+---+---+---+--

(0 rows)

Tracing session: fbc23200-f522-11e6-95df-69d39475f5a8

 activity   
   | 
timestamp  | source| source_elapsed | client
---++---++---

Execute CQL3 query | 
2017-02-17 16:08:48.288000 | 127.0.0.1 |  0 | 127.0.0.1
  Parsing SELECT * FROM test.test WHERE a = '1' 
AND c = '38151' LIMIT 1 ALLOW FILTERING; [Native-Transport-Requests-1] | 
2017-02-17 16:08:48.288000 | 127.0.0.1 |268 | 127.0.0.1

 Preparing statement [Native-Transport-Requests-1] | 
2017-02-17 16:08:48.289000 | 127.0.0.1 |513 | 127.0.0.1
 Index mean cardinalities are 
test_a_idx:-9223372036854775808,test_c_idx:-9223372036854775808. Scanning with 
test_a_idx. [Native-Transport-Requests-1] | 2017-02-17 16:08:48.289000 | 
127.0.0.1 |913 | 127.0.0.1

   Computing ranges to query [Native-Transport-Requests-1] | 
2017-02-17 16:08:48.289000 | 127.0.0.1 |   1027 | 127.0.0.1
Submitting range requests on 257 ranges with a concurrency of 1 
(-3.24259165E16 rows per range expected) [Native-Transport-Requests-1] | 
2017-02-17 16:08:48.289001 | 127.0.0.1 |   1319 | 127.0.0.1

   Submitted 1 concurrent range requests [Native-Transport-Requests-1] | 
2017-02-17 16:08:48.29 | 127.0.0.1 |   2229 | 127.0.0.1

  Executing read on test.test using index test_a_idx [ReadStage-3] | 
2017-02-17 16:08:48.292000 | 127.0.0.1 |   3494 | 127.0.0.1

   Read 0 live and 0 tombstone cells [ReadStage-3] | 
2017-02-17 16:08:48.293000 | 127.0.0.1 |   4694 | 127.0.0.1

  Request complete | 
2017-02-17 16:08:48.292930 | 127.0.0.1 |   4930 | 127.0.0.1
{code}


Yay ! No more iterating on the useless index.

Patch is on https://github.com/iksaif/cassandra/tree/sasi-null-intersect


> SASI: Index intersection with an empty range really inefficient
> ---
>
> Key: CASSANDRA-12915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12915
> Project: Cassandra
>  Issue Type: Improvement
>  Components: 

[jira] [Commented] (CASSANDRA-13230) Build RPM packages for release

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-13230:


Sounds great! Those scripts were only a start on what dependencies needed to be 
installed to get through a build successfully and I never got back to them to 
work out a shared volume to drop the packages in when complete. Your suggestion 
is exactly what I was thinking.

> Build RPM packages for release
> --
>
> Key: CASSANDRA-13230
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13230
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Packaging
>Reporter: Michael Shuler
>Assignee: Stefan Podkowinski
>
> Currently, releases are built locally on Debian/Ubuntu based machines, 
> without native support for building RPM packages. This can be done with a 
> docker image.
> The current cassandra-release scripts are here (please, do not randomly run 
> and push tags..):
> https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git;a=tree;f=cassandra-release
> A couple incomplete docker run scripts are here:
> https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git;a=tree;f=docker-wip
> {code}
> git clone https://git-wip-us.apache.org/repos/asf/cassandra-builds.git
> {code}
> Patches for build infra improvements are welcome!
> /cc [~spo...@gmail.com] if you want to assign to yourself, I'd be happy to 
> review :)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13232) "multiple versions of ant detected in path for junit" printed for every junit test case spawned by "ant test"

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-13232:
---
Reviewer: Ariel Weisberg

> "multiple versions of ant detected in path for junit" printed for every junit 
> test case spawned by "ant test"
> -
>
> Key: CASSANDRA-13232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13232
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Michael Kjellman
>Assignee: Michael Kjellman
> Attachments: 673.diff
>
>
> There is a super annoying junit warning logged before every junit test case 
> when you run "ant test". This is due to the fact that the ant junit task that 
> we have configured in our build.xml sources the system class path and most 
> importantly what's in ant.library.dir.
> [junit] WARNING: multiple versions of ant detected in path for junit 
> [junit]  
> jar:file:/usr/local/ant/lib/ant.jar!/org/apache/tools/ant/Project.class
> [junit]  and 
> jar:file:/Users/mkjellman/Documents/mkjellman-cie-cassandra-trunk/build/lib/jars/ant-1.9.6.jar!/org/apache/tools/ant/Project.class
> The fix here is to explicitly exclude the ant jar downloaded from the maven 
> tasks that ends up in ${build.lib} and ${build.dir.lib} so only the ant 
> libraries from the system class path are used.
> I played around with excluding the ant classes/jars from the system class 
> path in favor of using the ones we copy into ${build.lib} and 
> ${build.dir.lib} with no success. After reading the documentation it seems 
> you always want to use the libs that shipped with whatever is in $ANT_HOME so 
> i believe excluding the jars from the build lib directories is the correct 
> change anyways.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13189) Use prompt_toolkit in cqlsh

[Corentin Chary (JIRA)]

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

Corentin Chary updated CASSANDRA-13189:
---
Description: 
prompt_toolkit is an alternative to readline 
(https://github.com/jonathanslenders/python-prompt-toolkit) and is used in a 
lot of software, including the upcomming version of ipython.

I'm working on an initial version that keeps compatibility with readline, which 
is available here: https://github.com/iksaif/cassandra/tree/prompt_toolkit

It's still missing tests and a few things, but I'm opening this for tracking 
and feedbacks.

!cqlsh-prompt-tookit.png|thumbnail!

  was:
prompt_toolkit is an alternative to readline 
(https://github.com/jonathanslenders/python-prompt-toolkit) and is used in a 
lot of software, including the upcomming version of ipython.

I'm working on an initial version that keeps compatibility with readline, which 
is available here: https://github.com/iksaif/cassandra/tree/prompt_toolkit

It's still missing tests and a few things, but I'm opening this for tracking 
and feedbacks.

!https://issues.apache.org/jira/secure/attachment/12851335/cqlsh-prompt-tookit.png|thumbnail!


> Use prompt_toolkit in cqlsh
> ---
>
> Key: CASSANDRA-13189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13189
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Corentin Chary
>Assignee: Corentin Chary
>Priority: Minor
> Attachments: cqlsh-prompt-tookit.png
>
>
> prompt_toolkit is an alternative to readline 
> (https://github.com/jonathanslenders/python-prompt-toolkit) and is used in a 
> lot of software, including the upcomming version of ipython.
> I'm working on an initial version that keeps compatibility with readline, 
> which is available here: 
> https://github.com/iksaif/cassandra/tree/prompt_toolkit
> It's still missing tests and a few things, but I'm opening this for tracking 
> and feedbacks.
> !cqlsh-prompt-tookit.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13189) Use prompt_toolkit in cqlsh

[Corentin Chary (JIRA)]

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

Corentin Chary commented on CASSANDRA-13189:


!cqlsh-prompt-tookit.png|thumbnail!

> Use prompt_toolkit in cqlsh
> ---
>
> Key: CASSANDRA-13189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13189
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Corentin Chary
>Assignee: Corentin Chary
>Priority: Minor
> Attachments: cqlsh-prompt-tookit.png
>
>
> prompt_toolkit is an alternative to readline 
> (https://github.com/jonathanslenders/python-prompt-toolkit) and is used in a 
> lot of software, including the upcomming version of ipython.
> I'm working on an initial version that keeps compatibility with readline, 
> which is available here: 
> https://github.com/iksaif/cassandra/tree/prompt_toolkit
> It's still missing tests and a few things, but I'm opening this for tracking 
> and feedbacks.
> !cqlsh-prompt-tookit.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13189) Use prompt_toolkit in cqlsh

[Corentin Chary (JIRA)]

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

Corentin Chary updated CASSANDRA-13189:
---
Description: 
prompt_toolkit is an alternative to readline 
(https://github.com/jonathanslenders/python-prompt-toolkit) and is used in a 
lot of software, including the upcomming version of ipython.

I'm working on an initial version that keeps compatibility with readline, which 
is available here: https://github.com/iksaif/cassandra/tree/prompt_toolkit

It's still missing tests and a few things, but I'm opening this for tracking 
and feedbacks.

!https://issues.apache.org/jira/secure/attachment/12851335/cqlsh-prompt-tookit.png|thumbnail!

  was:
prompt_toolkit is an alternative to readline 
(https://github.com/jonathanslenders/python-prompt-toolkit) and is used in a 
lot of software, including the upcomming version of ipython.

I'm working on an initial version that keeps compatibility with readline, which 
is available here: https://github.com/iksaif/cassandra/tree/prompt_toolkit

It's still missing tests and a few things, but I'm opening this for tracking 
and feedbacks.

!cqlsh-prompt-toolkit.png!


> Use prompt_toolkit in cqlsh
> ---
>
> Key: CASSANDRA-13189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13189
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Corentin Chary
>Assignee: Corentin Chary
>Priority: Minor
> Attachments: cqlsh-prompt-tookit.png
>
>
> prompt_toolkit is an alternative to readline 
> (https://github.com/jonathanslenders/python-prompt-toolkit) and is used in a 
> lot of software, including the upcomming version of ipython.
> I'm working on an initial version that keeps compatibility with readline, 
> which is available here: 
> https://github.com/iksaif/cassandra/tree/prompt_toolkit
> It's still missing tests and a few things, but I'm opening this for tracking 
> and feedbacks.
> !https://issues.apache.org/jira/secure/attachment/12851335/cqlsh-prompt-tookit.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (CASSANDRA-13189) Use prompt_toolkit in cqlsh

[Corentin Chary (JIRA)]

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

Corentin Chary edited comment on CASSANDRA-13189 at 2/17/17 2:48 PM:
-

!cqlsh-prompt-tookit.png!


was (Author: iksaif):
!cqlsh-prompt-tookit.png|thumbnail!

> Use prompt_toolkit in cqlsh
> ---
>
> Key: CASSANDRA-13189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13189
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Corentin Chary
>Assignee: Corentin Chary
>Priority: Minor
> Attachments: cqlsh-prompt-tookit.png
>
>
> prompt_toolkit is an alternative to readline 
> (https://github.com/jonathanslenders/python-prompt-toolkit) and is used in a 
> lot of software, including the upcomming version of ipython.
> I'm working on an initial version that keeps compatibility with readline, 
> which is available here: 
> https://github.com/iksaif/cassandra/tree/prompt_toolkit
> It's still missing tests and a few things, but I'm opening this for tracking 
> and feedbacks.
> !cqlsh-prompt-tookit.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13189) Use prompt_toolkit in cqlsh

[Corentin Chary (JIRA)]

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

Corentin Chary updated CASSANDRA-13189:
---
Description: 
prompt_toolkit is an alternative to readline 
(https://github.com/jonathanslenders/python-prompt-toolkit) and is used in a 
lot of software, including the upcomming version of ipython.

I'm working on an initial version that keeps compatibility with readline, which 
is available here: https://github.com/iksaif/cassandra/tree/prompt_toolkit

It's still missing tests and a few things, but I'm opening this for tracking 
and feedbacks.

!cqlsh-prompt-toolkit.png!

  was:
prompt_toolkit is an alternative to readline 
(https://github.com/jonathanslenders/python-prompt-toolkit) and is used in a 
lot of software, including the upcomming version of ipython.

I'm working on an initial version that keeps compatibility with readline, which 
is available here: https://github.com/iksaif/cassandra/tree/prompt_toolkit

It's still missing tests and a few things, but I'm opening this for tracking 
and feedbacks.


> Use prompt_toolkit in cqlsh
> ---
>
> Key: CASSANDRA-13189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13189
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Corentin Chary
>Assignee: Corentin Chary
>Priority: Minor
> Attachments: cqlsh-prompt-tookit.png
>
>
> prompt_toolkit is an alternative to readline 
> (https://github.com/jonathanslenders/python-prompt-toolkit) and is used in a 
> lot of software, including the upcomming version of ipython.
> I'm working on an initial version that keeps compatibility with readline, 
> which is available here: 
> https://github.com/iksaif/cassandra/tree/prompt_toolkit
> It's still missing tests and a few things, but I'm opening this for tracking 
> and feedbacks.
> !cqlsh-prompt-toolkit.png!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13237) Legacy deserializer can create unexpected boundary range tombstones

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-13237:
-
Status: Patch Available  (was: Open)

Attaching patches for the problem below:
| [13237-3.0|https://github.com/pcmanus/cassandra/commits/13237-3.0] | 
[utests|http://cassci.datastax.com/job/pcmanus-13237-3.0-testall] | 
[dtests|http://cassci.datastax.com/job/pcmanus-13237-3.0-dtest] |
| [13237-3.11|https://github.com/pcmanus/cassandra/commits/13237-3.11] | 
[utests|http://cassci.datastax.com/job/pcmanus-13237-3.11-testall] | 
[dtests|http://cassci.datastax.com/job/pcmanus-13237-3.11-dtest] |
| [13237-trunk|https://github.com/pcmanus/cassandra/commits/13237-trunk] | 
[utests|http://cassci.datastax.com/job/pcmanus-13237-trunk-testall] | 
[dtests|http://cassci.datastax.com/job/pcmanus-13237-trunk-dtest] |

The first commit of the 3.0/3.11 patches is actually not doing anything but 
just adding a unit test that shows we can indeed create a range tombstone 
boundary that have the same deletion on both sides. For that, and because we 
don't have an easy way to actually write old sstable, the patch also refactor 
{{UnfilteredDeserializer.OldFormatDeserializer}} so that it can be unit tested. 
So while the diff may look "large-ish", it's really just moving some code 
around for the test purposes.

The 2nd commit does 2 things:
# it fixes the legacy deserializer to stop doing this.
# it update the assertion in {{DataResolver}} that breaks with such boundaries 
(again, same deletion on both side of the boundary).

Not that while it may sound like the 1st part is enough, we can't guarantee 
that some use having already upgraded haven't some bad boundaries already 
(let's clarify when I say "bad" that it's really just an small inefficiency so 
not really a big deal) so we shouldn't break on those. Still, no point in 
creating such useless boundaries, hence the 1st part.

The trunk patch really only include the {{DataResolver}} change since legacy 
code has been removed there.

> Legacy deserializer can create unexpected boundary range tombstones
> ---
>
> Key: CASSANDRA-13237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13237
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.11.x
>
>
> Most of the code don't generate a range tombstone boundary with the same 
> deletion time on both side as this is basically useless, and there is some 
> assertion in {{DataResolver}} that actually expect this. However, the 
> deserializer for legacy sstable doesn't always properly avoid their creation 
> and we can thus generate them (and break the {{DataResolver}} assertion.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-12915) SASI: Index intersection with an empty range really inefficient

[Corentin Chary (JIRA)]

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

Corentin Chary updated CASSANDRA-12915:
---
Summary: SASI: Index intersection with an empty range really inefficient  
(was: SASI: Index intersection can be very inefficient)

> SASI: Index intersection with an empty range really inefficient
> ---
>
> Key: CASSANDRA-12915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12915
> Project: Cassandra
>  Issue Type: Improvement
>  Components: sasi
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 3.11.x
>
>
> It looks like RangeIntersectionIterator.java and be pretty inefficient in 
> some cases. Let's take the following query:
> SELECT data FROM table WHERE index1 = 'foo' AND index2 = 'bar';
> In this case:
> * index1 = 'foo' will match 2 items
> * index2 = 'bar' will match ~300k items
> On my setup, the query will take ~1 sec, most of the time being spent in 
> disk.TokenTree.getTokenAt().
> if I patch RangeIntersectionIterator so that it doesn't try to do the 
> intersection (and effectively only use 'index1') the query will run in a few 
> tenth of milliseconds.
> I see multiple solutions for that:
> * Add a static thresold to avoid the use of the index for the intersection 
> when we know it will be slow. Probably when the range size factor is very 
> small and the range size is big.
> * CASSANDRA-10765



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CASSANDRA-13237) Legacy deserializer can create unexpected boundary range tombstones

[Sylvain Lebresne (JIRA)]

Sylvain Lebresne created CASSANDRA-13237:


 Summary: Legacy deserializer can create unexpected boundary range 
tombstones
 Key: CASSANDRA-13237
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13237
 Project: Cassandra
  Issue Type: Bug
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
 Fix For: 3.0.x, 3.11.x


Most of the code don't generate a range tombstone boundary with the same 
deletion time on both side as this is basically useless, and there is some 
assertion in {{DataResolver}} that actually expect this. However, the 
deserializer for legacy sstable doesn't always properly avoid their creation 
and we can thus generate them (and break the {{DataResolver}} assertion.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[JIRA]

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

ingard mevåg commented on CASSANDRA-13236:
--

as the upgradesstables process is running we're seeing a change (a bit too soon 
to conclude maybe). For instance:

cqlsh> SELECT * FROM collections WHERE username = 'redacted' AND 
collection_type in(0,1,2,3,4,5,6,7);
ServerError: java.io.IOError: java.io.IOException: Corrupt flags value for 
unfiltered partition (isStatic flag set): 160

Its failing there, but sometimes it actually returns data. So maybe the problem 
is related to one or more of the replicated data sets not having completed the 
upgradesstables for that specific table yet?

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [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.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: 

[jira] [Commented] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13236:
-

[~ifesdjeen] or [~Stefania] any ideas what might be going here? It seems to be 
failing at {{UnfilteredSerializer#deserialize()}}, where it checks the extended 
flags to see if the row is static (apparently the flags indicate the row is 
static).

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [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.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserialize(UnfilteredSerializer.java:374)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> 

[jira] [Commented] (CASSANDRA-13230) Build RPM packages for release

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski commented on CASSANDRA-13230:


I've now created my own branch that would split up the docker process a bit by 
first creating a build image with all tooling and afterwards trigger the actual 
build process by using a script executed by `docker run`. RPMs will afterwards 
end up in the hosts dist directory. 

My suggestion would be to update the debian docker script as well, so it will 
create deb files along with the RPMs in the dist dir. Afterwards the 
cassandra-release scripts could be updated to pick up the packages from dist 
dir, instead of building them locally. WDYT?

> Build RPM packages for release
> --
>
> Key: CASSANDRA-13230
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13230
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Packaging
>Reporter: Michael Shuler
>Assignee: Stefan Podkowinski
>
> Currently, releases are built locally on Debian/Ubuntu based machines, 
> without native support for building RPM packages. This can be done with a 
> docker image.
> The current cassandra-release scripts are here (please, do not randomly run 
> and push tags..):
> https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git;a=tree;f=cassandra-release
> A couple incomplete docker run scripts are here:
> https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git;a=tree;f=docker-wip
> {code}
> git clone https://git-wip-us.apache.org/repos/asf/cassandra-builds.git
> {code}
> Patches for build infra improvements are welcome!
> /cc [~spo...@gmail.com] if you want to assign to yourself, I'd be happy to 
> review :)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (CASSANDRA-13230) Build RPM packages for release

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski reassigned CASSANDRA-13230:
--

Assignee: Stefan Podkowinski

> Build RPM packages for release
> --
>
> Key: CASSANDRA-13230
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13230
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Packaging
>Reporter: Michael Shuler
>Assignee: Stefan Podkowinski
>
> Currently, releases are built locally on Debian/Ubuntu based machines, 
> without native support for building RPM packages. This can be done with a 
> docker image.
> The current cassandra-release scripts are here (please, do not randomly run 
> and push tags..):
> https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git;a=tree;f=cassandra-release
> A couple incomplete docker run scripts are here:
> https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git;a=tree;f=docker-wip
> {code}
> git clone https://git-wip-us.apache.org/repos/asf/cassandra-builds.git
> {code}
> Patches for build infra improvements are welcome!
> /cc [~spo...@gmail.com] if you want to assign to yourself, I'd be happy to 
> review :)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[JIRA]

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

ingard mevåg commented on CASSANDRA-13236:
--

yes

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [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.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserialize(UnfilteredSerializer.java:374)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:217)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> ... 23 common frames omitted



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13236:
-

Is the exception always/only about the "Corrupt flags value for unfiltered 
partition (isStatic flag set): 160"?

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [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.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserialize(UnfilteredSerializer.java:374)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:217)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> ... 23 common frames 

[jira] [Commented] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[JIRA]

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

ingard mevåg commented on CASSANDRA-13236:
--

We started the upgrade process and got that error repeatedly when the server 
came back up. We found another similar ticket CASSANDRA-12088, which again 
referred to CASSANDRA-12582. Atm we've upgraded all nodes to 3.0.10 and are in 
the process of running upgradesstables on them.
The error is still occuring on all nodes, including the ones which have 
finished the upgradesstables process.

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [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.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic flag set): 160
> at 
> 

[jira] [Commented] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13236:
-

The stack trace above indicates a select statement is happening. Is this 
occurring on "every" request, or only infrequently (as in a few times a minute 
or less)? Does this happen on all nodes, or a subset? Also, is the cluster 
completely transitioned to 3.0, or are you in middle of upgrading?

As far as logging goes, I'm not sure we have a way to dump error-inducing 
statements.

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [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.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic flag set): 160
> at 
> 

[jira] [Commented] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[JIRA]

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

ingard mevåg commented on CASSANDRA-13236:
--

CREATE KEYSPACE keyspace WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': '3'}  AND durable_writes = true;

CREATE TABLE keyspace.public_uri_share (
    uri text PRIMARY KEY,
    collection__username__type__id text
) WITH bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99PERCENTILE';

CREATE TABLE keyspace.photo_collections (
    photo__username__id text,
    collection__username__type__id text,
    collection_photo_order bigint,
    is_cover_photo boolean,
    PRIMARY KEY (photo__username__id, collection__username__type__id)
) WITH CLUSTERING ORDER BY (collection__username__type__id ASC)
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99PERCENTILE';

CREATE TABLE keyspace.comments_counts (
    collection__username__type__id text,
    collection_photo_order bigint,
    counter_value counter,
    PRIMARY KEY (collection__username__type__id, collection_photo_order)
) WITH CLUSTERING ORDER BY (collection_photo_order ASC)
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99PERCENTILE';

CREATE TABLE keyspace.comments (
    collection__username__type__id text,
    collection_photo_order bigint,
    comment_id_order bigint,
    comment text,
    commenter_username text,
    PRIMARY KEY (collection__username__type__id, collection_photo_order, 
comment_id_order)
) WITH CLUSTERING ORDER BY (collection_photo_order ASC, comment_id_order ASC)
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99PERCENTILE';

CREATE TABLE keyspace.photos (
    username text,
    id_shard int,
    id text,
    json text,
    main_collection__username__type__id text,
    u_id text,
    PRIMARY KEY ((username, id_shard), id)
) WITH CLUSTERING ORDER BY (id ASC)
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND 

[jira] [Commented] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[JIRA]

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

ingard mevåg commented on CASSANDRA-13236:
--

I'm not sure which queries causes this atm. Is there a way to find out from 
enabling logging or something else?

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [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.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserialize(UnfilteredSerializer.java:374)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:217)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> ... 23 common 

[jira] [Commented] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13236:
-

Can you share the schema and query?

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [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.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserialize(UnfilteredSerializer.java:374)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:217)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> ... 23 common frames omitted



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13130) Strange result of several list updates in a single request

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-13130:


bq. Could you please clarify what does "the higher value will win" mean?

Sorry, I meant the {{greater}} value win.

bq. Does it mean that it's not defined which of two updates will be actually 
applied?

It is clearly defined which value will win. It might not just be the one that 
you expect.

If you look at the following query: {{UPDATE t SET listColumn\[2\] = 8, 
listColumn\[2\] = 7  WHERE id = 1;}}
You might expect that the second value will win because it comes last.

In reality C* will consider that it has received 2 updates with exactly the 
same {{timestamp}}: {{UPDATE t SET listColumn\[2\] = 8  WHERE id = 1;}} and 
{{UPDATE t SET listColumn\[2\] = 7  WHERE id = 1;}} and will reconcile the data.

The data will be reconciled as follow:
# if one of the modifications is a deletion (tomstone), it wins and the data is 
marked as deleted
# if none of the modifications is a deletion, the update with the greater value 
win. If {{A > B}} then A win. If {{B > A}} then B win.

You will face the same issue with batches:
{code}
BEGIN BATCH
UPDATE t SET listColumn[2] = 8  WHERE id = 1;
UPDATE t SET listColumn[2] = 7  WHERE id = 1;
APPLY BATCH;
{code}
will also result in {{listColumn=\{1,2,8,4\}}}.
 
I you want the second update to always be the winner then you should send to 
separate updates.


> Strange result of several list updates in a single request
> --
>
> Key: CASSANDRA-13130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13130
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Mikhail Krupitskiy
>Assignee: Benjamin Lerer
>Priority: Trivial
>
> Let's assume that we have a row with the 'listColumn' column and value 
> \{1,2,3,4\}.
> For me it looks logical to expect that the following two pieces of code will 
> ends up with the same result but it isn't so.
> Code1:
> {code}
> UPDATE t SET listColumn[2] = 7, listColumn[2] = 8  WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\} 
> Actual result: listColumn=\{1,2,7,8,4\}
> Code2:
> {code}
> UPDATE t SET listColumn[2] = 7  WHERE id = 1;
> UPDATE t SET listColumn[2] = 8  WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\} 
> Actual result: listColumn=\{1,2,8,4\}
> So the question is why Code1 and Code2 give different results?
> Looks like Code1 should give the same result as Code2.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[JIRA]

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

ingard mevåg updated CASSANDRA-13236:
-
Since Version: 3.10

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [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.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserialize(UnfilteredSerializer.java:374)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:217)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> ... 23 common frames omitted



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[JIRA]

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

ingard mevåg updated CASSANDRA-13236:
-
  Environment: cassandra 3.0.10
Since Version:   (was: 3.10)

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [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.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserialize(UnfilteredSerializer.java:374)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:217)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> ... 23 common frames omitted



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[JIRA]

ingard mevåg created CASSANDRA-13236:


 Summary: corrupt flag error after upgrade from 2.2 to 3.0.10
 Key: CASSANDRA-13236
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
 Project: Cassandra
  Issue Type: Bug
Reporter: ingard mevåg


After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like this:
ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
Unexpected exception during request; channel = [id: 0xa8b98684, 
/10.0.70.104:56814 => /10.0.80.24:9042]
java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
partition (isStatic flag set): 160
at 
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
 [apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
 [apache-cassandra-3.0.10.jar:3.0.10]
at 
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
 [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.access$700(AbstractChannelHandlerContext.java:32)
 [netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
 [netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_72]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
 [apache-cassandra-3.0.10.jar:3.0.10]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
[apache-cassandra-3.0.10.jar:3.0.10]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
(isStatic flag set): 160
at 
org.apache.cassandra.db.rows.UnfilteredSerializer.deserialize(UnfilteredSerializer.java:374)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
at 
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:217)
 ~[apache-cassandra-3.0.10.jar:3.0.10]
... 23 common frames omitted



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (CASSANDRA-13216) testall failure in org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages

[Alex Petrov (JIRA)]

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

Alex Petrov reassigned CASSANDRA-13216:
---

Assignee: Alex Petrov

> testall failure in 
> org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages
> 
>
> Key: CASSANDRA-13216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13216
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>Assignee: Alex Petrov
>  Labels: test-failure, testall
> Attachments: TEST-org.apache.cassandra.net.MessagingServiceTest.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.11_testall/81/testReport/org.apache.cassandra.net/MessagingServiceTest/testDroppedMessages
> {code}
> Error Message
> expected:<... dropped latency: 27[30 ms and Mean cross-node dropped latency: 
> 2731] ms> but was:<... dropped latency: 27[28 ms and Mean cross-node dropped 
> latency: 2730] ms>
> {code}{code}
> Stacktrace
> junit.framework.AssertionFailedError: expected:<... dropped latency: 27[30 ms 
> and Mean cross-node dropped latency: 2731] ms> but was:<... dropped latency: 
> 27[28 ms and Mean cross-node dropped latency: 2730] ms>
>   at 
> org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages(MessagingServiceTest.java:83)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13216) testall failure in org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-13216:
-

Problem is that when the test is running subsequently or there was some test 
that has already modified values of dropped messages metrics, since they're 
stored in mbean, they'll still be retrieved. 

For example, on the subsequent run we'd get the following metrics: 
{code}
 {READ=7500, RANGE_SLICE=7500... }
{code}

Instead, we should have just gotten 0es. 

Unfortunately, dropwizard metrics does not give any simple mechanism for 
resetting the metrics. The path of least resistance I've currently found is 
just to assign a unique name to the scope while testing the metrics that have 
to be test-unique and resettable.

> testall failure in 
> org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages
> 
>
> Key: CASSANDRA-13216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13216
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>  Labels: test-failure, testall
> Attachments: TEST-org.apache.cassandra.net.MessagingServiceTest.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.11_testall/81/testReport/org.apache.cassandra.net/MessagingServiceTest/testDroppedMessages
> {code}
> Error Message
> expected:<... dropped latency: 27[30 ms and Mean cross-node dropped latency: 
> 2731] ms> but was:<... dropped latency: 27[28 ms and Mean cross-node dropped 
> latency: 2730] ms>
> {code}{code}
> Stacktrace
> junit.framework.AssertionFailedError: expected:<... dropped latency: 27[30 ms 
> and Mean cross-node dropped latency: 2731] ms> but was:<... dropped latency: 
> 27[28 ms and Mean cross-node dropped latency: 2730] ms>
>   at 
> org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages(MessagingServiceTest.java:83)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13235) All thread blocked and writes pending.

[zhaoyan (JIRA)]

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

zhaoyan updated CASSANDRA-13235:

Description: 
I found cassandra many pending  MutationStage task

{code}
NFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:51 - Pool Name  
  Active   Pending  Completed   Blocked  All Time Blocked
INFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:66 - 
MutationStage   384  4553 4294213082 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
RequestResponseStage  0 0 2172612382 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
ReadRepairStage   0 05378852 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
CounterMutationStage  0 0  0 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - ReadStage 
5 0  577242284 0 0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - MiscStage 
0 0  0 0 0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
HintedHandoff 0 0   1480 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
GossipStage   0 09342250 0  
   0

{code}
And I found there are many blocked thread with jstack

{code}
"SharedPool-Worker-28" #416 daemon prio=5 os_prio=0 tid=0x01fb8000 
nid=0x7459 waiting for monitor entry [0x7fdd83ca]
   java.lang.Thread.State: BLOCKED (on object monitor)
at sun.misc.Unsafe.monitorEnter(Native Method)
at 
org.apache.cassandra.utils.concurrent.Locks.monitorEnterUnsafe(Locks.java:46)
at 
org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:202)
at org.apache.cassandra.db.Memtable.put(Memtable.java:210)
at 
org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1244)
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396)
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:359)
at org.apache.cassandra.db.Mutation.apply(Mutation.java:214)
at 
org.apache.cassandra.db.MutationVerbHandler.doVerb(MutationVerbHandler.java:54)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at 
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
at java.lang.Thread.run(Thread.java:745)

{code}

To use "grep BLOCKED |wc -l",  get Number is 384 

  was:
I found cassandra many pending  MutationStage task

{code}
NFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:51 - Pool Name  
  Active   Pending  Completed   Blocked  All Time Blocked
INFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:66 - 
MutationStage   384  4553 4294213082 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
RequestResponseStage  0 0 2172612382 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
ReadRepairStage   0 05378852 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
CounterMutationStage  0 0  0 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - ReadStage 
5 0  577242284 0 0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - MiscStage 
0 0  0 0 0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
HintedHandoff 0 0   1480 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
GossipStage   0 09342250 0  
   0

{code}
And I found there are many blocked thread with jstack

{code}
"SharedPool-Worker-28" #416 daemon prio=5 os_prio=0 tid=0x01fb8000 
nid=0x7459 waiting for monitor entry [0x7fdd83ca]
   java.lang.Thread.State: BLOCKED (on object monitor)
at sun.misc.Unsafe.monitorEnter(Native Method)
at 

[jira] [Updated] (CASSANDRA-13235) All thread blocked and writes pending.

[zhaoyan (JIRA)]

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

zhaoyan updated CASSANDRA-13235:

Description: 
I found cassandra many pending  MutationStage task

{code}
NFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:51 - Pool Name  
  Active   Pending  Completed   Blocked  All Time Blocked
INFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:66 - 
MutationStage   384  4553 4294213082 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
RequestResponseStage  0 0 2172612382 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
ReadRepairStage   0 05378852 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
CounterMutationStage  0 0  0 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - ReadStage 
5 0  577242284 0 0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - MiscStage 
0 0  0 0 0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
HintedHandoff 0 0   1480 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
GossipStage   0 09342250 0  
   0

{code}
And I found there are many blocked thread with jstack

{code}
"SharedPool-Worker-28" #416 daemon prio=5 os_prio=0 tid=0x01fb8000 
nid=0x7459 waiting for monitor entry [0x7fdd83ca]
   java.lang.Thread.State: BLOCKED (on object monitor)
at sun.misc.Unsafe.monitorEnter(Native Method)
at 
org.apache.cassandra.utils.concurrent.Locks.monitorEnterUnsafe(Locks.java:46)
at 
org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:202)
at org.apache.cassandra.db.Memtable.put(Memtable.java:210)
at 
org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1244)
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396)
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:359)
at org.apache.cassandra.db.Mutation.apply(Mutation.java:214)
at 
org.apache.cassandra.db.MutationVerbHandler.doVerb(MutationVerbHandler.java:54)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at 
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
at java.lang.Thread.run(Thread.java:745)

{code}

  was:
I found cassandra many pending  MutationStage task

{code}
NFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:51 - Pool Name  
  Active   Pending  Completed   Blocked  All Time Blocked
INFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:66 - 
MutationStage   384  4553 4294213082 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
RequestResponseStage  0 0 2172612382 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
ReadRepairStage   0 05378852 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
CounterMutationStage  0 0  0 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - ReadStage 
5 0  577242284 0 0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - MiscStage 
0 0  0 0 0

{code}
And I found there are many blocked thread with jstack

{code}
"SharedPool-Worker-28" #416 daemon prio=5 os_prio=0 tid=0x01fb8000 
nid=0x7459 waiting for monitor entry [0x7fdd83ca]
   java.lang.Thread.State: BLOCKED (on object monitor)
at sun.misc.Unsafe.monitorEnter(Native Method)
at 
org.apache.cassandra.utils.concurrent.Locks.monitorEnterUnsafe(Locks.java:46)
at 
org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:202)
at org.apache.cassandra.db.Memtable.put(Memtable.java:210)
at 
org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1244)
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396)
at 

[jira] [Updated] (CASSANDRA-13235) All thread blocked and writes pending.

[zhaoyan (JIRA)]

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

zhaoyan updated CASSANDRA-13235:

Description: 
I found cassandra many pending  MutationStage task

{code}
NFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:51 - Pool Name  
  Active   Pending  Completed   Blocked  All Time Blocked
INFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:66 - 
MutationStage   384  4553 4294213082 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
RequestResponseStage  0 0 2172612382 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
ReadRepairStage   0 05378852 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
CounterMutationStage  0 0  0 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - ReadStage 
5 0  577242284 0 0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - MiscStage 
0 0  0 0 0

{code}
And I found there are many blocked thread with jstack

{code}
"SharedPool-Worker-28" #416 daemon prio=5 os_prio=0 tid=0x01fb8000 
nid=0x7459 waiting for monitor entry [0x7fdd83ca]
   java.lang.Thread.State: BLOCKED (on object monitor)
at sun.misc.Unsafe.monitorEnter(Native Method)
at 
org.apache.cassandra.utils.concurrent.Locks.monitorEnterUnsafe(Locks.java:46)
at 
org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:202)
at org.apache.cassandra.db.Memtable.put(Memtable.java:210)
at 
org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1244)
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396)
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:359)
at org.apache.cassandra.db.Mutation.apply(Mutation.java:214)
at 
org.apache.cassandra.db.MutationVerbHandler.doVerb(MutationVerbHandler.java:54)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at 
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
at java.lang.Thread.run(Thread.java:745)

INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
HintedHandoff 0 0   1480 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
GossipStage   0 09342250 0  
   0

{code}

  was:
I found cassandra many pending  MutationStage task

NFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:51 - Pool Name  
  Active   Pending  Completed   Blocked  All Time Blocked
INFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:66 - 
MutationStage   384  4553 4294213082 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
RequestResponseStage  0 0 2172612382 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
ReadRepairStage   0 05378852 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
CounterMutationStage  0 0  0 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - ReadStage 
5 0  577242284 0 0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - MiscStage 
0 0  0 0 0

And I found there are many blocked thread with jstack

"SharedPool-Worker-28" #416 daemon prio=5 os_prio=0 tid=0x01fb8000 
nid=0x7459 waiting for monitor entry [0x7fdd83ca]
   java.lang.Thread.State: BLOCKED (on object monitor)
at sun.misc.Unsafe.monitorEnter(Native Method)
at 
org.apache.cassandra.utils.concurrent.Locks.monitorEnterUnsafe(Locks.java:46)
at 
org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:202)
at org.apache.cassandra.db.Memtable.put(Memtable.java:210)
at 
org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1244)
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396)
at 

[jira] [Created] (CASSANDRA-13235) All thread blocked and writes pending.

[zhaoyan (JIRA)]

zhaoyan created CASSANDRA-13235:
---

 Summary: All thread blocked and writes pending.
 Key: CASSANDRA-13235
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13235
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: jdk8
cassandra 2.1.15
Reporter: zhaoyan


I found cassandra many pending  MutationStage task

NFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:51 - Pool Name  
  Active   Pending  Completed   Blocked  All Time Blocked
INFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:66 - 
MutationStage   384  4553 4294213082 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
RequestResponseStage  0 0 2172612382 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
ReadRepairStage   0 05378852 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
CounterMutationStage  0 0  0 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - ReadStage 
5 0  577242284 0 0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - MiscStage 
0 0  0 0 0

And I found there are many blocked thread with jstack

"SharedPool-Worker-28" #416 daemon prio=5 os_prio=0 tid=0x01fb8000 
nid=0x7459 waiting for monitor entry [0x7fdd83ca]
   java.lang.Thread.State: BLOCKED (on object monitor)
at sun.misc.Unsafe.monitorEnter(Native Method)
at 
org.apache.cassandra.utils.concurrent.Locks.monitorEnterUnsafe(Locks.java:46)
at 
org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:202)
at org.apache.cassandra.db.Memtable.put(Memtable.java:210)
at 
org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1244)
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396)
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:359)
at org.apache.cassandra.db.Mutation.apply(Mutation.java:214)
at 
org.apache.cassandra.db.MutationVerbHandler.doVerb(MutationVerbHandler.java:54)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at 
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
at java.lang.Thread.run(Thread.java:745)

INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
HintedHandoff 0 0   1480 0  
   0
INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
GossipStage   0 09342250 0  
   0




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)