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

[Ben Slater (JIRA)]

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

Ben Slater edited comment on CASSANDRA-11914 at 5/28/16 4:47 AM:
-

I've attach a proof of concept patch the just prints the command setting and 
related options. If people think this is useful and are OK with the general 
direction then I'll finish off in this way for the remaining settings and 
options.


was (Author: slater_ben):
Proof of concept only

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



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

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

[Ben Slater (JIRA)]

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

Ben Slater updated CASSANDRA-11914:
---
Attachment: 11914-trunk.patch

Proof of concept only

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



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

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

[Ben Slater (JIRA)]

Ben Slater created CASSANDRA-11914:
--

 Summary: Provide option for cassandra-stress to dump all settings
 Key: CASSANDRA-11914
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11914
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Ben Slater
Priority: Minor


cassandra-stress has quite a lot of default settings and settings that are 
derived as side effects of explicit options. For people learning the tool and 
saving a clear record of what was run, I think it would be useful if there was 
an option to have the tool print all its settings at the start of a run.



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

[jira] [Updated] (CASSANDRA-11913) BufferUnderFlowException in CompressorTest

[Rei Odaira (JIRA)]

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

Rei Odaira updated CASSANDRA-11913:
---
Description: org.apache.cassandra.io.compress.CompressorTest causes 
java.nio.BufferUnderflowException on environments where FastByteOperations uses 
PureJavaOperations. The root cause is that CompressorTest.testArrayUncompress() 
copies data from a ByteBuffer to a byte array beyond the limit of the 
ByteBuffer.  (was: org.apache.cassandra.io.compress.CompressorTest causes 
java.nio.BufferUnderflowException on environments where FastByteOperations uses 
PureJavaOperations. The root cause is that CompressorTest.testArrayUncompress() 
copies data from a ByteBuffer to a byte array beyond the limit of the 
ByteBuffer. I will attach a patch shortly.)

> BufferUnderFlowException in CompressorTest
> --
>
> Key: CASSANDRA-11913
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11913
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
> Environment: Non-x86 environments
>Reporter: Rei Odaira
>Priority: Minor
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: 11913-2.2.txt
>
>
> org.apache.cassandra.io.compress.CompressorTest causes 
> java.nio.BufferUnderflowException on environments where FastByteOperations 
> uses PureJavaOperations. The root cause is that 
> CompressorTest.testArrayUncompress() copies data from a ByteBuffer to a byte 
> array beyond the limit of the ByteBuffer.



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

[jira] [Updated] (CASSANDRA-11913) BufferUnderFlowException in CompressorTest

[Rei Odaira (JIRA)]

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

Rei Odaira updated CASSANDRA-11913:
---
 Flags: Patch
Attachment: 11913-2.2.txt

> BufferUnderFlowException in CompressorTest
> --
>
> Key: CASSANDRA-11913
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11913
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
> Environment: Non-x86 environments
>Reporter: Rei Odaira
>Priority: Minor
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: 11913-2.2.txt
>
>
> org.apache.cassandra.io.compress.CompressorTest causes 
> java.nio.BufferUnderflowException on environments where FastByteOperations 
> uses PureJavaOperations. The root cause is that 
> CompressorTest.testArrayUncompress() copies data from a ByteBuffer to a byte 
> array beyond the limit of the ByteBuffer. I will attach a patch shortly.



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

[jira] [Created] (CASSANDRA-11913) BufferUnderFlowException in CompressorTest

[Rei Odaira (JIRA)]

Rei Odaira created CASSANDRA-11913:
--

 Summary: BufferUnderFlowException in CompressorTest
 Key: CASSANDRA-11913
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11913
 Project: Cassandra
  Issue Type: Bug
  Components: Testing
 Environment: Non-x86 environments
Reporter: Rei Odaira
Priority: Minor
 Fix For: 2.2.x, 3.0.x, 3.x


org.apache.cassandra.io.compress.CompressorTest causes 
java.nio.BufferUnderflowException on environments where FastByteOperations uses 
PureJavaOperations. The root cause is that CompressorTest.testArrayUncompress() 
copies data from a ByteBuffer to a byte array beyond the limit of the 
ByteBuffer. I will attach a patch shortly.



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

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

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan edited comment on CASSANDRA-9530 at 5/28/16 3:19 AM:
-

We have Java based thrift code that uses AbstractType/C* marshaling to decode 
things.  I'm guessing other people probably do too, this change breaks that by 
having AbstractType pull in DatabaseDescriptor.

Opened CASSANDRA-11912 to fix this.


was (Author: jjordan):
We have Java based thrift code that uses AbstractType/C* marshaling to decode 
things.  I'm guessing other people probably do too, this change breaks that by 
having AbstractType pull in DatabaseDescriptor.

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



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

[jira] [Updated] (CASSANDRA-11878) dtest failure in upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_3_x_To_indev_3_x.select_key_in_test

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11878:

Reviewer: Alex Petrov

> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_3_x_To_indev_3_x.select_key_in_test
> -
>
> Key: CASSANDRA-11878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11878
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Marcus Eriksson
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log
>
>
> example failure:
> http://cassci.datastax.com/job/upgrade_tests-all/47/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_3_x_To_indev_3_x/select_key_in_test
> Failed on CassCI build upgrade_tests-all #47
> Attached logs for test failure.
> {code}
> ERROR [CompactionExecutor:2] 2016-05-21 23:10:35,678 CassandraDaemon.java:195 
> - Exception in thread Thread[CompactionExecutor:2,1,main]
> java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut 
> down
>   at 
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
>  ~[apache-cassandra-3.5.jar:3.5]
>   at 
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) 
> ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1364) 
> ~[na:1.8.0_51]
>   at 
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
>  ~[apache-cassandra-3.5.jar:3.5]
>   at 
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
>  ~[na:1.8.0_51]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager.submitBackground(CompactionManager.java:184)
>  ~[apache-cassandra-3.5.jar:3.5]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:270)
>  ~[apache-cassandra-3.5.jar:3.5]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_51]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
> {code}



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

[jira] [Commented] (CASSANDRA-11693) dtest failure in scrub_test.TestScrubIndexes.test_scrub_static_table

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-11693:
-

[~philipthompson] as reviewer since he's taking the dtest review.

> dtest failure in scrub_test.TestScrubIndexes.test_scrub_static_table
> 
>
> Key: CASSANDRA-11693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11693
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Russ Hatch
>Assignee: Yuki Morishita
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log
>
>
> intermittent failure: 
> http://cassci.datastax.com/job/trunk_offheap_dtest/166/testReport/scrub_test/TestScrubIndexes/test_scrub_static_table/
> looks distinct from another reported failure on this test for windows 
> (CASSANDRA-11284)



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

[jira] [Updated] (CASSANDRA-11693) dtest failure in scrub_test.TestScrubIndexes.test_scrub_static_table

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11693:

Reviewer: Philip Thompson

> dtest failure in scrub_test.TestScrubIndexes.test_scrub_static_table
> 
>
> Key: CASSANDRA-11693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11693
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Russ Hatch
>Assignee: Yuki Morishita
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log
>
>
> intermittent failure: 
> http://cassci.datastax.com/job/trunk_offheap_dtest/166/testReport/scrub_test/TestScrubIndexes/test_scrub_static_table/
> looks distinct from another reported failure on this test for windows 
> (CASSANDRA-11284)



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

[jira] [Commented] (CASSANDRA-11884) dtest failure in secondary_indexes_test.TestSecondaryIndexesOnCollections.test_tuple_indexes

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-11884:
-

[~blambov]: is this a dupe of 9669? If so, we should close it.

> dtest failure in 
> secondary_indexes_test.TestSecondaryIndexesOnCollections.test_tuple_indexes
> 
>
> Key: CASSANDRA-11884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11884
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Branimir Lambov
>  Labels: dtest
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: node1.log, node1_debug.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1234/testReport/secondary_indexes_test/TestSecondaryIndexesOnCollections/test_tuple_indexes
> Failed on CassCI build trunk_dtest #1234
> Logs are attached.



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

[jira] [Updated] (CASSANDRA-11884) dtest failure in secondary_indexes_test.TestSecondaryIndexesOnCollections.test_tuple_indexes

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11884:

Reviewer: Sam Tunnicliffe

> dtest failure in 
> secondary_indexes_test.TestSecondaryIndexesOnCollections.test_tuple_indexes
> 
>
> Key: CASSANDRA-11884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11884
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Branimir Lambov
>  Labels: dtest
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: node1.log, node1_debug.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1234/testReport/secondary_indexes_test/TestSecondaryIndexesOnCollections/test_tuple_indexes
> Failed on CassCI build trunk_dtest #1234
> Logs are attached.



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

[jira] [Updated] (CASSANDRA-11587) Cfstats estimate number of keys should return 0 for empty table

[Yuki Morishita (JIRA)]

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

Yuki Morishita updated CASSANDRA-11587:
---
Reviewer: Yuki Morishita

> Cfstats estimate number of keys should return 0 for empty table
> ---
>
> Key: CASSANDRA-11587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11587
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Cassandra 2.1.13
> Nodeltool
>Reporter: Jane Deng
>Assignee: Mahdi Mohammadi
>Priority: Trivial
>  Labels: lhf
> Fix For: 3.6, 2.2.x, 3.0.x
>
>
> If sstable count is 0, the "estimate number of keys" in cfstats shows -1. 
> {noformat}
> SSTable count: 0
> Number of keys (estimate): -1
> {noformat}
> The initial value of keyCount in SSTableReader is -1. When there is no 
> sstable, nor entry in memtable, the keyCount isn't increased. Cfstats should 
> have some boundary check and return 0 for this case. 



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

[jira] [Updated] (CASSANDRA-11587) Cfstats estimate number of keys should return 0 for empty table

[Mahdi Mohammadi (JIRA)]

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

Mahdi Mohammadi updated CASSANDRA-11587:

Fix Version/s: 3.0.x
   2.2.x
   3.6
   Status: Patch Available  (was: In Progress)

> Cfstats estimate number of keys should return 0 for empty table
> ---
>
> Key: CASSANDRA-11587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11587
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Cassandra 2.1.13
> Nodeltool
>Reporter: Jane Deng
>Assignee: Mahdi Mohammadi
>Priority: Trivial
>  Labels: lhf
> Fix For: 3.6, 2.2.x, 3.0.x
>
>
> If sstable count is 0, the "estimate number of keys" in cfstats shows -1. 
> {noformat}
> SSTable count: 0
> Number of keys (estimate): -1
> {noformat}
> The initial value of keyCount in SSTableReader is -1. When there is no 
> sstable, nor entry in memtable, the keyCount isn't increased. Cfstats should 
> have some boundary check and return 0 for this case. 



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

[jira] [Commented] (CASSANDRA-11587) Cfstats estimate number of keys should return 0 for empty table

[Mahdi Mohammadi (JIRA)]

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

Mahdi Mohammadi commented on CASSANDRA-11587:
-

Branch for [2.2|https://github.com/mm-binary/cassandra/tree/11587-2.2]
Branch for [3.0|https://github.com/mm-binary/cassandra/tree/11587-3.0]
Branch for [3.6|https://github.com/mm-binary/cassandra/tree/11587-3.6]

> Cfstats estimate number of keys should return 0 for empty table
> ---
>
> Key: CASSANDRA-11587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11587
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Cassandra 2.1.13
> Nodeltool
>Reporter: Jane Deng
>Assignee: Mahdi Mohammadi
>Priority: Trivial
>  Labels: lhf
>
> If sstable count is 0, the "estimate number of keys" in cfstats shows -1. 
> {noformat}
> SSTable count: 0
> Number of keys (estimate): -1
> {noformat}
> The initial value of keyCount in SSTableReader is -1. When there is no 
> sstable, nor entry in memtable, the keyCount isn't increased. Cfstats should 
> have some boundary check and return 0 for this case. 



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

[jira] [Assigned] (CASSANDRA-11912) Remove DatabaseDescriptor import from AbstractType

[Alex Petrov (JIRA)]

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

Alex Petrov reassigned CASSANDRA-11912:
---

Assignee: Alex Petrov

> Remove DatabaseDescriptor import from AbstractType
> --
>
> Key: CASSANDRA-11912
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11912
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Core
>Reporter: Jeremiah Jordan
>Assignee: Alex Petrov
> Fix For: 3.0.x, 3.x
>
>
> CASSANDRA-9530 added an import of DatabaseDescriptor in AbstractType, this 
> import breaks Thrift based java code which uses AbstractType based classes to 
> deserialize types.  The max size value should be give to AbstractType in some 
> other way that doesn't require importing DatabaseDescriptor.



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

[jira] [Resolved] (CASSANDRA-11032) Full trace returned on ReadFailure by cqlsh

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs resolved CASSANDRA-11032.
-
   Resolution: Fixed
Fix Version/s: 3.0.7
   3.7

The tests look good, so +1, committed to 3.0 as 
{{7a7704e5fddb00c877329db93d352e03e2179703}} and merged up to 3.7 and trunk.

Thanks!

> Full trace returned on ReadFailure by cqlsh
> ---
>
> Key: CASSANDRA-11032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11032
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Chris Splinter
>Assignee: Zhongxiang Zheng
>Priority: Minor
>  Labels: cqlsh, lhf
> Fix For: 3.7, 3.0.7
>
> Attachments: CASSANDRA-11032-trunk.patch
>
>
> I noticed that the full traceback is returned on a read failure where I 
> expected this to be a one line exception with the ReadFailure message. It is 
> minor, but would it be better to only return the ReadFailure details?
> {code}
> cqlsh> SELECT * FROM test_encryption_ks.test_bad_table;
> Traceback (most recent call last):
>   File "/usr/local/lib/dse/bin/../resources/cassandra/bin/cqlsh.py", line 
> 1276, in perform_simple_statement
> result = future.result()
>   File 
> "/usr/local/lib/dse/resources/cassandra/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py",
>  line 3122, in result
> raise self._final_exception
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation 
> failed - received 0 responses and 1 failures" info={'failures': 1, 
> 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {code}



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

[1/3] cassandra git commit: cqlsh: Suppress stacktraces for Read/WriteFailures

[tylerhobbs]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 5ca8052a9 -> 692d9992d


cqlsh: Suppress stacktraces for Read/WriteFailures

Patch by Zhongxiang Zheng; reviewed by Tyler Hobbs for CASSANDRA-11032


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

Branch: refs/heads/trunk
Commit: 7a7704e5fddb00c877329db93d352e03e2179703
Parents: 6f236c8
Author: Zhongxiang Zheng 
Authored: Fri May 27 13:04:47 2016 -0500
Committer: Tyler Hobbs 
Committed: Fri May 27 15:47:36 2016 -0500

--
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 5 ++---
 2 files changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7a7704e5/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 103eff0..d96f3c6 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.7
+ * cqlsh: Suppress stack trace from Read/WriteFailures (CASSANDRA-11032)
  * Remove unneeded code to repair index summaries that have
been improperly down-sampled (CASSANDRA-11127)
  * Avoid WriteTimeoutExceptions during commit log replay due to materialized

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7a7704e5/bin/cqlsh.py
--
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 0c60a52..9dc7b77 100644
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -152,7 +152,6 @@ from cassandra.metadata import (ColumnMetadata, 
KeyspaceMetadata,
 TableMetadata, protect_name, protect_names)
 from cassandra.policies import WhiteListRoundRobinPolicy
 from cassandra.query import SimpleStatement, ordered_dict_factory, 
TraceUnavailable
-from cassandra.type_codes import DateType
 from cassandra.util import datetime_from_timestamp
 
 # cqlsh should run correctly when run out of a Cassandra source tree,
@@ -263,8 +262,8 @@ if os.path.exists(OLD_HISTORY):
 # END history/config definition
 
 CQL_ERRORS = (
-cassandra.AlreadyExists, cassandra.AuthenticationFailed, 
cassandra.InvalidRequest,
-cassandra.Timeout, cassandra.Unauthorized, cassandra.OperationTimedOut,
+cassandra.AlreadyExists, cassandra.AuthenticationFailed, 
cassandra.CoordinationFailure,
+cassandra.InvalidRequest, cassandra.Timeout, cassandra.Unauthorized, 
cassandra.OperationTimedOut,
 cassandra.cluster.NoHostAvailable,
 cassandra.connection.ConnectionBusy, cassandra.connection.ProtocolError, 
cassandra.connection.ConnectionException,
 cassandra.protocol.ErrorMessage, cassandra.protocol.InternalError, 
cassandra.query.TraceUnavailable

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

[tylerhobbs]

Merge branch 'cassandra-3.0' into cassandra-3.7

Conflicts:
CHANGES.txt


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

Branch: refs/heads/trunk
Commit: 22e0a1daa6b4487a4ee8f6636e7ed1c51648bec2
Parents: a2dd005 7a7704e
Author: Tyler Hobbs 
Authored: Fri May 27 15:48:22 2016 -0500
Committer: Tyler Hobbs 
Committed: Fri May 27 15:48:22 2016 -0500

--
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/22e0a1da/CHANGES.txt
--
diff --cc CHANGES.txt
index 0c447f5,d96f3c6..8a854ac
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,6 -1,5 +1,7 @@@
 -3.0.7
 +3.7
 + * Don't use static dataDirectories field in Directories instances 
(CASSANDRA-11647)
 +Merged from 3.0:
+  * cqlsh: Suppress stack trace from Read/WriteFailures (CASSANDRA-11032)
   * Remove unneeded code to repair index summaries that have
 been improperly down-sampled (CASSANDRA-11127)
   * Avoid WriteTimeoutExceptions during commit log replay due to materialized

http://git-wip-us.apache.org/repos/asf/cassandra/blob/22e0a1da/bin/cqlsh.py
--

[1/2] cassandra git commit: cqlsh: Suppress stacktraces for Read/WriteFailures

[tylerhobbs]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.7 a2dd00516 -> 22e0a1daa


cqlsh: Suppress stacktraces for Read/WriteFailures

Patch by Zhongxiang Zheng; reviewed by Tyler Hobbs for CASSANDRA-11032


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

Branch: refs/heads/cassandra-3.7
Commit: 7a7704e5fddb00c877329db93d352e03e2179703
Parents: 6f236c8
Author: Zhongxiang Zheng 
Authored: Fri May 27 13:04:47 2016 -0500
Committer: Tyler Hobbs 
Committed: Fri May 27 15:47:36 2016 -0500

--
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 5 ++---
 2 files changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7a7704e5/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 103eff0..d96f3c6 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.7
+ * cqlsh: Suppress stack trace from Read/WriteFailures (CASSANDRA-11032)
  * Remove unneeded code to repair index summaries that have
been improperly down-sampled (CASSANDRA-11127)
  * Avoid WriteTimeoutExceptions during commit log replay due to materialized

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7a7704e5/bin/cqlsh.py
--
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 0c60a52..9dc7b77 100644
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -152,7 +152,6 @@ from cassandra.metadata import (ColumnMetadata, 
KeyspaceMetadata,
 TableMetadata, protect_name, protect_names)
 from cassandra.policies import WhiteListRoundRobinPolicy
 from cassandra.query import SimpleStatement, ordered_dict_factory, 
TraceUnavailable
-from cassandra.type_codes import DateType
 from cassandra.util import datetime_from_timestamp
 
 # cqlsh should run correctly when run out of a Cassandra source tree,
@@ -263,8 +262,8 @@ if os.path.exists(OLD_HISTORY):
 # END history/config definition
 
 CQL_ERRORS = (
-cassandra.AlreadyExists, cassandra.AuthenticationFailed, 
cassandra.InvalidRequest,
-cassandra.Timeout, cassandra.Unauthorized, cassandra.OperationTimedOut,
+cassandra.AlreadyExists, cassandra.AuthenticationFailed, 
cassandra.CoordinationFailure,
+cassandra.InvalidRequest, cassandra.Timeout, cassandra.Unauthorized, 
cassandra.OperationTimedOut,
 cassandra.cluster.NoHostAvailable,
 cassandra.connection.ConnectionBusy, cassandra.connection.ProtocolError, 
cassandra.connection.ConnectionException,
 cassandra.protocol.ErrorMessage, cassandra.protocol.InternalError, 
cassandra.query.TraceUnavailable

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

[tylerhobbs]

Merge branch 'cassandra-3.7' into trunk


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

Branch: refs/heads/trunk
Commit: 692d9992db6cb78fbbf285070faec00d7ffbe8e3
Parents: 5ca8052 22e0a1d
Author: Tyler Hobbs 
Authored: Fri May 27 15:48:30 2016 -0500
Committer: Tyler Hobbs 
Committed: Fri May 27 15:48:30 2016 -0500

--
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)
--


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

[2/2] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.7

[tylerhobbs]

Merge branch 'cassandra-3.0' into cassandra-3.7

Conflicts:
CHANGES.txt


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

Branch: refs/heads/cassandra-3.7
Commit: 22e0a1daa6b4487a4ee8f6636e7ed1c51648bec2
Parents: a2dd005 7a7704e
Author: Tyler Hobbs 
Authored: Fri May 27 15:48:22 2016 -0500
Committer: Tyler Hobbs 
Committed: Fri May 27 15:48:22 2016 -0500

--
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/22e0a1da/CHANGES.txt
--
diff --cc CHANGES.txt
index 0c447f5,d96f3c6..8a854ac
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,6 -1,5 +1,7 @@@
 -3.0.7
 +3.7
 + * Don't use static dataDirectories field in Directories instances 
(CASSANDRA-11647)
 +Merged from 3.0:
+  * cqlsh: Suppress stack trace from Read/WriteFailures (CASSANDRA-11032)
   * Remove unneeded code to repair index summaries that have
 been improperly down-sampled (CASSANDRA-11127)
   * Avoid WriteTimeoutExceptions during commit log replay due to materialized

http://git-wip-us.apache.org/repos/asf/cassandra/blob/22e0a1da/bin/cqlsh.py
--

cassandra git commit: cqlsh: Suppress stacktraces for Read/WriteFailures

[tylerhobbs]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 6f236c801 -> 7a7704e5f


cqlsh: Suppress stacktraces for Read/WriteFailures

Patch by Zhongxiang Zheng; reviewed by Tyler Hobbs for CASSANDRA-11032


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

Branch: refs/heads/cassandra-3.0
Commit: 7a7704e5fddb00c877329db93d352e03e2179703
Parents: 6f236c8
Author: Zhongxiang Zheng 
Authored: Fri May 27 13:04:47 2016 -0500
Committer: Tyler Hobbs 
Committed: Fri May 27 15:47:36 2016 -0500

--
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 5 ++---
 2 files changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7a7704e5/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 103eff0..d96f3c6 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.7
+ * cqlsh: Suppress stack trace from Read/WriteFailures (CASSANDRA-11032)
  * Remove unneeded code to repair index summaries that have
been improperly down-sampled (CASSANDRA-11127)
  * Avoid WriteTimeoutExceptions during commit log replay due to materialized

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7a7704e5/bin/cqlsh.py
--
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 0c60a52..9dc7b77 100644
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -152,7 +152,6 @@ from cassandra.metadata import (ColumnMetadata, 
KeyspaceMetadata,
 TableMetadata, protect_name, protect_names)
 from cassandra.policies import WhiteListRoundRobinPolicy
 from cassandra.query import SimpleStatement, ordered_dict_factory, 
TraceUnavailable
-from cassandra.type_codes import DateType
 from cassandra.util import datetime_from_timestamp
 
 # cqlsh should run correctly when run out of a Cassandra source tree,
@@ -263,8 +262,8 @@ if os.path.exists(OLD_HISTORY):
 # END history/config definition
 
 CQL_ERRORS = (
-cassandra.AlreadyExists, cassandra.AuthenticationFailed, 
cassandra.InvalidRequest,
-cassandra.Timeout, cassandra.Unauthorized, cassandra.OperationTimedOut,
+cassandra.AlreadyExists, cassandra.AuthenticationFailed, 
cassandra.CoordinationFailure,
+cassandra.InvalidRequest, cassandra.Timeout, cassandra.Unauthorized, 
cassandra.OperationTimedOut,
 cassandra.cluster.NoHostAvailable,
 cassandra.connection.ConnectionBusy, cassandra.connection.ProtocolError, 
cassandra.connection.ConnectionException,
 cassandra.protocol.ErrorMessage, cassandra.protocol.InternalError, 
cassandra.query.TraceUnavailable

[jira] [Updated] (CASSANDRA-11912) Remove DatabaseDescriptor import from AbstractType

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan updated CASSANDRA-11912:

Component/s: Core
 Configuration

> Remove DatabaseDescriptor import from AbstractType
> --
>
> Key: CASSANDRA-11912
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11912
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration, Core
>Reporter: Jeremiah Jordan
> Fix For: 3.0.x, 3.x
>
>
> CASSANDRA-9530 added an import of DatabaseDescriptor in AbstractType, this 
> import breaks Thrift based java code which uses AbstractType based classes to 
> deserialize types.  The max size value should be give to AbstractType in some 
> other way that doesn't require importing DatabaseDescriptor.



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

[jira] [Updated] (CASSANDRA-11912) Remove DatabaseDescriptor import from AbstractType

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan updated CASSANDRA-11912:

Issue Type: Bug  (was: Improvement)

> Remove DatabaseDescriptor import from AbstractType
> --
>
> Key: CASSANDRA-11912
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11912
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Core
>Reporter: Jeremiah Jordan
> Fix For: 3.0.x, 3.x
>
>
> CASSANDRA-9530 added an import of DatabaseDescriptor in AbstractType, this 
> import breaks Thrift based java code which uses AbstractType based classes to 
> deserialize types.  The max size value should be give to AbstractType in some 
> other way that doesn't require importing DatabaseDescriptor.



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

[jira] [Created] (CASSANDRA-11912) Remove DatabaseDescriptor import from AbstractType

[Jeremiah Jordan (JIRA)]

Jeremiah Jordan created CASSANDRA-11912:
---

 Summary: Remove DatabaseDescriptor import from AbstractType
 Key: CASSANDRA-11912
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11912
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jeremiah Jordan
 Fix For: 3.0.x, 3.x


CASSANDRA-9530 added an import of DatabaseDescriptor in AbstractType, this 
import breaks Thrift based java code which uses AbstractType based classes to 
deserialize types.  The max size value should be give to AbstractType in some 
other way that doesn't require importing DatabaseDescriptor.



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

[jira] [Updated] (CASSANDRA-11911) CQLSSTableWriter should allow for unset fields

[Matt Kopit (JIRA)]

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

Matt Kopit updated CASSANDRA-11911:
---
Description: 
If you are using CQLSSTableWriter to bulk load data into sstables the only way 
to handle fields without values is by setting them to NULL, which results in 
the generation of a tombstoned field in the resulting sstable. For a large 
dataset this can result in a large number of tombstones.

CQLSSTableWriter is currently instantiated with a single INSERT statement, so 
it's not an option to modify the insert statement to specify different fields 
on a per-row basis.

Here are three potential solutions to this problem:
1. Change the default behavior of how NULLs are handled so those fields are 
treated as UNSET and will never be written to the sstable.
2. Create a configuration option for CQLSSTableWriter that governs whether 
NULLs should be ignored.
3. Invent a new constant that represents an UNSET value which can be used in 
place of NULL.

  was:
If you are using CQLSSTableWriter to bulk load data into sstables the only way 
to handle fields without values is by setting them to NULL, which results in 
the generation of a tombstoned field in the resulting sstable. For a large 
dataset this can result in a large number of tombstones.

CQLSSTableWriter is currently instantiated with a single INSERT statement, so 
it's not an option to modify the insert statement to specify different fields 
on a per-row basis.

Here are three potential solutions to this problem:
1. Change the default behavior of how NULLs so those fields are not written to 
the sstable
2. Create a configuration option for CQLSSTableWriter that governs whether 
NULLs should be ignored.
3. Invent a new constant that represents an UNSET value which can be used in 
place of NULL


> CQLSSTableWriter should allow for unset fields
> --
>
> Key: CASSANDRA-11911
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11911
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
> Environment: Cassandra 3.0.6
>Reporter: Matt Kopit
>
> If you are using CQLSSTableWriter to bulk load data into sstables the only 
> way to handle fields without values is by setting them to NULL, which results 
> in the generation of a tombstoned field in the resulting sstable. For a large 
> dataset this can result in a large number of tombstones.
> CQLSSTableWriter is currently instantiated with a single INSERT statement, so 
> it's not an option to modify the insert statement to specify different fields 
> on a per-row basis.
> Here are three potential solutions to this problem:
> 1. Change the default behavior of how NULLs are handled so those fields are 
> treated as UNSET and will never be written to the sstable.
> 2. Create a configuration option for CQLSSTableWriter that governs whether 
> NULLs should be ignored.
> 3. Invent a new constant that represents an UNSET value which can be used in 
> place of NULL.



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

[jira] [Created] (CASSANDRA-11911) CQLSSTableWriter should allow for unset fields

[Matt Kopit (JIRA)]

Matt Kopit created CASSANDRA-11911:
--

 Summary: CQLSSTableWriter should allow for unset fields
 Key: CASSANDRA-11911
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11911
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: Cassandra 3.0.6
Reporter: Matt Kopit


If you are using CQLSSTableWriter to bulk load data into sstables the only way 
to handle fields without values is by setting them to NULL, which results in 
the generation of a tombstoned field in the resulting sstable. For a large 
dataset this can result in a large number of tombstones.

CQLSSTableWriter is currently instantiated with a single INSERT statement, so 
it's not an option to modify the insert statement to specify different fields 
on a per-row basis.

Here are three potential solutions to this problem:
1. Change the default behavior of how NULLs so those fields are not written to 
the sstable
2. Create a configuration option for CQLSSTableWriter that governs whether 
NULLs should be ignored.
3. Invent a new constant that represents an UNSET value which can be used in 
place of NULL



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

[jira] [Commented] (CASSANDRA-11763) Failure to read non-shallow pre-3.0 sstable index entries

[T Jake Luciani (JIRA)]

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

T Jake Luciani commented on CASSANDRA-11763:


+1

regarding CASSANDRA-9669 we just need to make sure we release 3.0.7 and 3.7 at 
the same time.

> Failure to read non-shallow pre-3.0 sstable index entries
> -
>
> Key: CASSANDRA-11763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11763
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Robert Stupp
>  Labels: dtest
> Fix For: 3.6
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure in:
> http://cassci.datastax.com/view/Parameterized/job/upgrade_tests-all-custom_branch_runs/12/testReport/upgrade_tests.upgrade_through_versions_test/ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD/rolling_upgrade_test_2/
> Logs are attached, relevant stack trace is here.
> {code}
> ERROR [main] 2016-05-11 16:26:06,555 CassandraDaemon.java:727 - Exception 
> encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:119)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.compactLegacyHints(LegacyHintsMigrator.java:108)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.migrate(LegacyHintsMigrator.java:92)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:321) 
> [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:581)
>  [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:710) 
> [main/:na]
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192) 
> ~[na:1.8.0_51]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:115)
>  ~[main/:na]
>   ... 5 common frames omitted
> Caused by: java.lang.NegativeArraySizeException: null
>   at 
> org.apache.cassandra.db.RowIndexEntry$LegacyShallowIndexedEntry.deserialize(RowIndexEntry.java:519)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.RowIndexEntry$Serializer.deserialize(RowIndexEntry.java:321)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:310)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:265)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner.hasNext(BigTableScanner.java:245)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:374)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:186)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:155)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:150)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:72)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:226)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:82)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:805)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_51]
>   at 

[jira] [Commented] (CASSANDRA-11763) Failure to read non-shallow pre-3.0 sstable index entries

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-11763:
--

Tests for 3.7 + trunk look good (at least, I don't see a regression by the 
patch).

The test is now broken for 3.6 - probably with CASSANDRA-9669, which went into 
3.0 and 3.7, but not into 3.6.

> Failure to read non-shallow pre-3.0 sstable index entries
> -
>
> Key: CASSANDRA-11763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11763
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Robert Stupp
>  Labels: dtest
> Fix For: 3.6
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure in:
> http://cassci.datastax.com/view/Parameterized/job/upgrade_tests-all-custom_branch_runs/12/testReport/upgrade_tests.upgrade_through_versions_test/ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD/rolling_upgrade_test_2/
> Logs are attached, relevant stack trace is here.
> {code}
> ERROR [main] 2016-05-11 16:26:06,555 CassandraDaemon.java:727 - Exception 
> encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:119)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.compactLegacyHints(LegacyHintsMigrator.java:108)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.migrate(LegacyHintsMigrator.java:92)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:321) 
> [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:581)
>  [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:710) 
> [main/:na]
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192) 
> ~[na:1.8.0_51]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:115)
>  ~[main/:na]
>   ... 5 common frames omitted
> Caused by: java.lang.NegativeArraySizeException: null
>   at 
> org.apache.cassandra.db.RowIndexEntry$LegacyShallowIndexedEntry.deserialize(RowIndexEntry.java:519)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.RowIndexEntry$Serializer.deserialize(RowIndexEntry.java:321)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:310)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:265)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner.hasNext(BigTableScanner.java:245)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:374)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:186)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:155)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:150)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:72)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:226)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:82)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:805)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> 

[jira] [Comment Edited] (CASSANDRA-11818) C* does neither recover nor trigger stability inspector on direct memory OOM

[Norman Maurer (JIRA)]

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

Norman Maurer edited comment on CASSANDRA-11818 at 5/27/16 6:14 PM:


[~snazy] Sorry for the late response (busy as always :( )... I wonder if this 
would be something that may be helpful for you in terms of Netty: 
https://github.com/netty/netty/pull/5314


was (Author: norman):
Sorry for the late response (busy as always :( )... I wonder if this would be 
something that may be helpful for you in terms of Netty: 
https://github.com/netty/netty/pull/5314

> C* does neither recover nor trigger stability inspector on direct memory OOM
> 
>
> Key: CASSANDRA-11818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11818
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
> Attachments: 11818-direct-mem-unpooled.png, 11818-direct-mem.png, 
> oom-histo-live.txt, oom-stack.txt
>
>
> The following stack trace is not caught by {{JVMStabilityInspector}}.
> Situation was caused by a load test with a lot of parallel writes and reads 
> against a single node.
> {code}
> ERROR [SharedPool-Worker-1] 2016-05-17 18:38:44,187 Message.java:611 - 
> Unexpected exception during request; channel = [id: 0x1e02351b, 
> L:/127.0.0.1:9042 - R:/127.0.0.1:51087]
> java.lang.OutOfMemoryError: Direct buffer memory
>   at java.nio.Bits.reserveMemory(Bits.java:693) ~[na:1.8.0_92]
>   at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123) 
> ~[na:1.8.0_92]
>   at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) 
> ~[na:1.8.0_92]
>   at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:672) 
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:234) 
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at io.netty.buffer.PoolArena.allocate(PoolArena.java:218) 
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at io.netty.buffer.PoolArena.allocate(PoolArena.java:138) 
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:270)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:177)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:168)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:105)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> org.apache.cassandra.transport.Message$ProtocolEncoder.encode(Message.java:349)
>  ~[main/:na]
>   at 
> org.apache.cassandra.transport.Message$ProtocolEncoder.encode(Message.java:314)
>  ~[main/:na]
>   at 
> io.netty.handler.codec.MessageToMessageEncoder.write(MessageToMessageEncoder.java:89)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:619)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:676)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:612)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher$Flusher.run(Message.java:445)
>  ~[main/:na]
>   at 
> io.netty.util.concurrent.PromiseTask$RunnableAdapter.call(PromiseTask.java:38)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:120)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:374) 
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_92]
> {code}
> The situation does not get better when the load driver is stopped.
> I can reproduce this scenario at will. Managed to get histogram, stack traces 
> and heap dump. Already increased {{-XX:MaxDirectMemorySize}} to {{2g}}.

[jira] [Commented] (CASSANDRA-11032) Full trace returned on ReadFailure by cqlsh

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-11032:
-

Thanks for the patch.  I gave this a quick manual test using 
{{-Dcassandra.test.fail_writes_ks}} and it looks good.

Here are the patches and pending CI tests:
||branch||dtest||
|[CASSANDRA-11032-3.0|https://github.com/thobbs/cassandra/tree/CASSANDRA-11032-3.0]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-11032-3.0-dtest]|
|[CASSANDRA-11032-3.7|https://github.com/thobbs/cassandra/tree/CASSANDRA-11032-3.7]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-11032-3.7-dtest]|
|[CASSANDRA-11032-trunk|https://github.com/thobbs/cassandra/tree/CASSANDRA-11032-trunk]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-11032-trunk-dtest]|

If the tests look good, I'll commit this.

> Full trace returned on ReadFailure by cqlsh
> ---
>
> Key: CASSANDRA-11032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11032
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Chris Splinter
>Assignee: Zhongxiang Zheng
>Priority: Minor
>  Labels: cqlsh, lhf
> Attachments: CASSANDRA-11032-trunk.patch
>
>
> I noticed that the full traceback is returned on a read failure where I 
> expected this to be a one line exception with the ReadFailure message. It is 
> minor, but would it be better to only return the ReadFailure details?
> {code}
> cqlsh> SELECT * FROM test_encryption_ks.test_bad_table;
> Traceback (most recent call last):
>   File "/usr/local/lib/dse/bin/../resources/cassandra/bin/cqlsh.py", line 
> 1276, in perform_simple_statement
> result = future.result()
>   File 
> "/usr/local/lib/dse/resources/cassandra/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py",
>  line 3122, in result
> raise self._final_exception
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation 
> failed - received 0 responses and 1 failures" info={'failures': 1, 
> 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {code}



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

[jira] [Commented] (CASSANDRA-11818) C* does neither recover nor trigger stability inspector on direct memory OOM

[Norman Maurer (JIRA)]

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

Norman Maurer commented on CASSANDRA-11818:
---

Sorry for the late response (busy as always :( )... I wonder if this would be 
something that may be helpful for you in terms of Netty: 
https://github.com/netty/netty/pull/5314

> C* does neither recover nor trigger stability inspector on direct memory OOM
> 
>
> Key: CASSANDRA-11818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11818
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
> Attachments: 11818-direct-mem-unpooled.png, 11818-direct-mem.png, 
> oom-histo-live.txt, oom-stack.txt
>
>
> The following stack trace is not caught by {{JVMStabilityInspector}}.
> Situation was caused by a load test with a lot of parallel writes and reads 
> against a single node.
> {code}
> ERROR [SharedPool-Worker-1] 2016-05-17 18:38:44,187 Message.java:611 - 
> Unexpected exception during request; channel = [id: 0x1e02351b, 
> L:/127.0.0.1:9042 - R:/127.0.0.1:51087]
> java.lang.OutOfMemoryError: Direct buffer memory
>   at java.nio.Bits.reserveMemory(Bits.java:693) ~[na:1.8.0_92]
>   at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123) 
> ~[na:1.8.0_92]
>   at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) 
> ~[na:1.8.0_92]
>   at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:672) 
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:234) 
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at io.netty.buffer.PoolArena.allocate(PoolArena.java:218) 
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at io.netty.buffer.PoolArena.allocate(PoolArena.java:138) 
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:270)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:177)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:168)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:105)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> org.apache.cassandra.transport.Message$ProtocolEncoder.encode(Message.java:349)
>  ~[main/:na]
>   at 
> org.apache.cassandra.transport.Message$ProtocolEncoder.encode(Message.java:314)
>  ~[main/:na]
>   at 
> io.netty.handler.codec.MessageToMessageEncoder.write(MessageToMessageEncoder.java:89)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:619)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:676)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:612)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher$Flusher.run(Message.java:445)
>  ~[main/:na]
>   at 
> io.netty.util.concurrent.PromiseTask$RunnableAdapter.call(PromiseTask.java:38)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:120)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:374) 
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
>  ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_92]
> {code}
> The situation does not get better when the load driver is stopped.
> I can reproduce this scenario at will. Managed to get histogram, stack traces 
> and heap dump. Already increased {{-XX:MaxDirectMemorySize}} to {{2g}}.
> A {{nodetool flush}} causes the daemon to exit (as that direct-memory OOM is 
> caught by {{JVMStabilityInspector}}).



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

[jira] [Updated] (CASSANDRA-11032) Full trace returned on ReadFailure by cqlsh

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-11032:

Assignee: Zhongxiang Zheng
Reviewer: Tyler Hobbs

> Full trace returned on ReadFailure by cqlsh
> ---
>
> Key: CASSANDRA-11032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11032
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Chris Splinter
>Assignee: Zhongxiang Zheng
>Priority: Minor
>  Labels: cqlsh, lhf
> Attachments: CASSANDRA-11032-trunk.patch
>
>
> I noticed that the full traceback is returned on a read failure where I 
> expected this to be a one line exception with the ReadFailure message. It is 
> minor, but would it be better to only return the ReadFailure details?
> {code}
> cqlsh> SELECT * FROM test_encryption_ks.test_bad_table;
> Traceback (most recent call last):
>   File "/usr/local/lib/dse/bin/../resources/cassandra/bin/cqlsh.py", line 
> 1276, in perform_simple_statement
> result = future.result()
>   File 
> "/usr/local/lib/dse/resources/cassandra/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py",
>  line 3122, in result
> raise self._final_exception
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation 
> failed - received 0 responses and 1 failures" info={'failures': 1, 
> 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {code}



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

[jira] [Updated] (CASSANDRA-11127) index_summary_upgrade_test.py is failing

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-11127:

   Resolution: Fixed
Fix Version/s: (was: 3.0.x)
   3.0.7
   3.7
   Status: Resolved  (was: Ready to Commit)

bq. Do you think it's worth to add this at this stage for 2.1 and 2.2 Tyler 
Hobbs? It's such an esoteric edge case now I'm not sure sure it's worth the 
investment, probably not.

I think there would be a little value in that, but I also agree that it's 
probably not the best investment of our time right now.  So, unless somebody 
else feels strongly about this, I'm going to leave that out for now.

Anyway, thanks for the review.  I've committed this to 3.0 as 
{{6f236c801be5b80fe18afc3ecebd4032c19b434d}} and merged up to 3.7 and trunk.

> index_summary_upgrade_test.py is failing
> 
>
> Key: CASSANDRA-11127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11127
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Philip Thompson
>Assignee: Tyler Hobbs
>  Labels: dtest, windows
> Fix For: 3.7, 3.0.7
>
> Attachments: node1_debug.log
>
>
> index_summary_upgrade_test.py is failing on the cassandra-3.0 branch, when 
> run without vnodes. The exception I'm seeing on cassci is different than 
> locally. The cassci failure is 
> [here|http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/157/testReport/index_summary_upgrade_test/TestUpgradeIndexSummary/test_upgrade_index_summary/].
> Locally I see the following:
> {code}
> 'ERROR [SSTableBatchOpen:2] 2016-02-05 15:29:04,304 CassandraDaemon.java:195 
> - Exception in thread 
> Thread[SSTableBatchOpen:2,5,main]\njava.lang.AssertionError: Illegal bounds 
> [4..8); size: 4\n\tat 
> org.apache.cassandra.io.util.Memory.checkBounds(Memory.java:339) 
> ~[main/:na]\n\tat org.apache.cassandra.io.util.Memory.getInt(Memory.java:292) 
> ~[main/:na]\n\tat 
> org.apache.cassandra.io.sstable.IndexSummary.getPositionInSummary(IndexSummary.java:146)
>  ~[main/:na]\n\tat 
> org.apache.cassandra.io.sstable.IndexSummary.getKey(IndexSummary.java:151) 
> ~[main/:na]\n\tat 
> org.apache.cassandra.io.sstable.format.SSTableReader.validateSummarySamplingLevel(SSTableReader.java:928)
>  ~[main/:na]\n\tat 
> org.apache.cassandra.io.sstable.format.SSTableReader.load(SSTableReader.java:748)
>  ~[main/:na]\n\tat 
> org.apache.cassandra.io.sstable.format.SSTableReader.load(SSTableReader.java:705)
>  ~[main/:na]\n\tat 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:491)
>  ~[main/:na]\n\tat 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:374)
>  ~[main/:na]\n\tat 
> org.apache.cassandra.io.sstable.format.SSTableReader$4.run(SSTableReader.java:533)
>  ~[main/:na]\n\tat 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_66]\n\tat java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_66]\n\tat 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_66]\n\tat 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_66]\n\tat java.lang.Thread.run(Thread.java:745) [na:1.8.0_66]']
> {code}
> Node log is attached.



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

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

[tylerhobbs]

Merge branch 'cassandra-3.7' into trunk


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

Branch: refs/heads/trunk
Commit: 5ca8052a9cb6aaf350c25c340bf03069a846f443
Parents: 89f275c a2dd005
Author: Tyler Hobbs 
Authored: Fri May 27 12:38:14 2016 -0500
Committer: Tyler Hobbs 
Committed: Fri May 27 12:38:14 2016 -0500

--
 CHANGES.txt |  2 +
 .../io/sstable/format/SSTableReader.java| 71 +---
 2 files changed, 3 insertions(+), 70 deletions(-)
--


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

[2/2] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.7

[tylerhobbs]

Merge branch 'cassandra-3.0' into cassandra-3.7

Conflicts:
CHANGES.txt
src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java


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

Branch: refs/heads/cassandra-3.7
Commit: a2dd00516988147f3d8a1e01ce330aa93d0024c2
Parents: 867a490 6f236c8
Author: Tyler Hobbs 
Authored: Fri May 27 12:37:55 2016 -0500
Committer: Tyler Hobbs 
Committed: Fri May 27 12:37:55 2016 -0500

--
 CHANGES.txt |  2 +
 .../io/sstable/format/SSTableReader.java| 71 +---
 2 files changed, 3 insertions(+), 70 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a2dd0051/CHANGES.txt
--
diff --cc CHANGES.txt
index 2ceeea9,103eff0..0c447f5
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,6 -1,6 +1,8 @@@
 -3.0.7
 +3.7
 + * Don't use static dataDirectories field in Directories instances 
(CASSANDRA-11647)
 +Merged from 3.0:
+  * Remove unneeded code to repair index summaries that have
+been improperly down-sampled (CASSANDRA-11127)
   * Avoid WriteTimeoutExceptions during commit log replay due to materialized
 view lock contention (CASSANDRA-11891)
   * Prevent OOM failures on SSTable corruption, improve tests for corruption 
detection (CASSANDRA-9530)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a2dd0051/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
--

[1/2] cassandra git commit: Remove unneeded summary repair from CASSANDRA-8993

[tylerhobbs]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.7 867a49009 -> a2dd00516


Remove unneeded summary repair from CASSANDRA-8993

Patch by Tyler Hobbs; review by Paulo Motta for CASSANDRA-11127


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

Branch: refs/heads/cassandra-3.7
Commit: 6f236c801be5b80fe18afc3ecebd4032c19b434d
Parents: 6f02446
Author: Tyler Hobbs 
Authored: Fri May 27 12:35:15 2016 -0500
Committer: Tyler Hobbs 
Committed: Fri May 27 12:35:15 2016 -0500

--
 CHANGES.txt |  2 +
 .../io/sstable/format/SSTableReader.java| 71 +---
 2 files changed, 3 insertions(+), 70 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6f236c80/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 3d166aa..103eff0 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
 3.0.7
+ * Remove unneeded code to repair index summaries that have
+   been improperly down-sampled (CASSANDRA-11127)
  * Avoid WriteTimeoutExceptions during commit log replay due to materialized
view lock contention (CASSANDRA-11891)
  * Prevent OOM failures on SSTable corruption, improve tests for corruption 
detection (CASSANDRA-9530)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6f236c80/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java 
b/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
index 9bb1767..9f2663e 100644
--- a/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
+++ b/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
@@ -744,30 +744,8 @@ public abstract class SSTableReader extends SSTable 
implements SelfRefCounted

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

[tylerhobbs]

Merge branch 'cassandra-3.0' into cassandra-3.7

Conflicts:
CHANGES.txt
src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java


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

Branch: refs/heads/trunk
Commit: a2dd00516988147f3d8a1e01ce330aa93d0024c2
Parents: 867a490 6f236c8
Author: Tyler Hobbs 
Authored: Fri May 27 12:37:55 2016 -0500
Committer: Tyler Hobbs 
Committed: Fri May 27 12:37:55 2016 -0500

--
 CHANGES.txt |  2 +
 .../io/sstable/format/SSTableReader.java| 71 +---
 2 files changed, 3 insertions(+), 70 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a2dd0051/CHANGES.txt
--
diff --cc CHANGES.txt
index 2ceeea9,103eff0..0c447f5
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,6 -1,6 +1,8 @@@
 -3.0.7
 +3.7
 + * Don't use static dataDirectories field in Directories instances 
(CASSANDRA-11647)
 +Merged from 3.0:
+  * Remove unneeded code to repair index summaries that have
+been improperly down-sampled (CASSANDRA-11127)
   * Avoid WriteTimeoutExceptions during commit log replay due to materialized
 view lock contention (CASSANDRA-11891)
   * Prevent OOM failures on SSTable corruption, improve tests for corruption 
detection (CASSANDRA-9530)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a2dd0051/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
--

[1/3] cassandra git commit: Remove unneeded summary repair from CASSANDRA-8993

[tylerhobbs]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 89f275c65 -> 5ca8052a9


Remove unneeded summary repair from CASSANDRA-8993

Patch by Tyler Hobbs; review by Paulo Motta for CASSANDRA-11127


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

Branch: refs/heads/trunk
Commit: 6f236c801be5b80fe18afc3ecebd4032c19b434d
Parents: 6f02446
Author: Tyler Hobbs 
Authored: Fri May 27 12:35:15 2016 -0500
Committer: Tyler Hobbs 
Committed: Fri May 27 12:35:15 2016 -0500

--
 CHANGES.txt |  2 +
 .../io/sstable/format/SSTableReader.java| 71 +---
 2 files changed, 3 insertions(+), 70 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6f236c80/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 3d166aa..103eff0 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
 3.0.7
+ * Remove unneeded code to repair index summaries that have
+   been improperly down-sampled (CASSANDRA-11127)
  * Avoid WriteTimeoutExceptions during commit log replay due to materialized
view lock contention (CASSANDRA-11891)
  * Prevent OOM failures on SSTable corruption, improve tests for corruption 
detection (CASSANDRA-9530)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6f236c80/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java 
b/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
index 9bb1767..9f2663e 100644
--- a/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
+++ b/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
@@ -744,30 +744,8 @@ public abstract class SSTableReader extends SSTable 
implements SelfRefCounted

cassandra git commit: Remove unneeded summary repair from CASSANDRA-8993

[tylerhobbs]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 6f02446f3 -> 6f236c801


Remove unneeded summary repair from CASSANDRA-8993

Patch by Tyler Hobbs; review by Paulo Motta for CASSANDRA-11127


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

Branch: refs/heads/cassandra-3.0
Commit: 6f236c801be5b80fe18afc3ecebd4032c19b434d
Parents: 6f02446
Author: Tyler Hobbs 
Authored: Fri May 27 12:35:15 2016 -0500
Committer: Tyler Hobbs 
Committed: Fri May 27 12:35:15 2016 -0500

--
 CHANGES.txt |  2 +
 .../io/sstable/format/SSTableReader.java| 71 +---
 2 files changed, 3 insertions(+), 70 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6f236c80/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 3d166aa..103eff0 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
 3.0.7
+ * Remove unneeded code to repair index summaries that have
+   been improperly down-sampled (CASSANDRA-11127)
  * Avoid WriteTimeoutExceptions during commit log replay due to materialized
view lock contention (CASSANDRA-11891)
  * Prevent OOM failures on SSTable corruption, improve tests for corruption 
detection (CASSANDRA-9530)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6f236c80/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java 
b/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
index 9bb1767..9f2663e 100644
--- a/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
+++ b/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
@@ -744,30 +744,8 @@ public abstract class SSTableReader extends SSTable 
implements SelfRefCounted

[jira] [Updated] (CASSANDRA-11729) dtest failure in secondary_indexes_test.TestSecondaryIndexes.test_6924_dropping_ks

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe updated CASSANDRA-11729:

Fix Version/s: (was: 3.x)

> dtest failure in 
> secondary_indexes_test.TestSecondaryIndexes.test_6924_dropping_ks
> --
>
> Key: CASSANDRA-11729
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11729
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Russ Hatch
>Assignee: Sam Tunnicliffe
>  Labels: dtest
> Attachments: node1_debug.log.gz, node2_debug.log.gz, 
> node3_debug.log.gz
>
>
> looks to be a single flap. might be worth trying to reproduce. example 
> failure:
> http://cassci.datastax.com/job/trunk_dtest/1204/testReport/secondary_indexes_test/TestSecondaryIndexes/test_6924_dropping_ks
> Failed on CassCI build trunk_dtest #1204



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

[jira] [Resolved] (CASSANDRA-11729) dtest failure in secondary_indexes_test.TestSecondaryIndexes.test_6924_dropping_ks

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe resolved CASSANDRA-11729.
-
Resolution: Won't Fix

I've marked the dtest as flaky in and added a note in the docstring (in 
[638167ff|https://github.com/riptano/cassandra-dtest/commit/638167fff0eb57bcf39e31de237d4c4a1d35a0d4]),
 so closing this now.

> dtest failure in 
> secondary_indexes_test.TestSecondaryIndexes.test_6924_dropping_ks
> --
>
> Key: CASSANDRA-11729
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11729
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Russ Hatch
>Assignee: Sam Tunnicliffe
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1_debug.log.gz, node2_debug.log.gz, 
> node3_debug.log.gz
>
>
> looks to be a single flap. might be worth trying to reproduce. example 
> failure:
> http://cassci.datastax.com/job/trunk_dtest/1204/testReport/secondary_indexes_test/TestSecondaryIndexes/test_6924_dropping_ks
> Failed on CassCI build trunk_dtest #1204



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

[jira] [Commented] (CASSANDRA-11903) Serial reads should not include pending endpoints

[Richard Low (JIRA)]

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

Richard Low commented on CASSANDRA-11903:
-

The write CL is increased by 1 for a pending endpoint so that a quorum of 
non-pending endpoints are written to. That means a regular quorum read is 
guaranteed to see the write and detect if any in progress paxos writes are 
committed.

> Serial reads should not include pending endpoints
> -
>
> Key: CASSANDRA-11903
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11903
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Richard Low
>
> A serial read uses pending endpoints in beginAndRepairPaxos, although the 
> read itself does not. I don't think the pending endpoints are necessary and 
> including them unnecessarily increases paxos work.



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

[jira] [Commented] (CASSANDRA-11258) Repair scheduling - Resource locking API

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-11258:
-

What's the status on that updated design doc on CASSANDRA-10070?

> Repair scheduling - Resource locking API
> 
>
> Key: CASSANDRA-11258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11258
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Minor
> Attachments: newDuration.patch
>
>
> Create a resource locking API & implementation that is able to lock a 
> resource in a specified data center. It should handle priorities to avoid 
> node starvation.



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

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

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan commented on CASSANDRA-9530:


We have Java based thrift code that uses AbstractType/C* marshaling to decode 
things.  I'm guessing other people probably do too, this change breaks that by 
having AbstractType pull in DatabaseDescriptor.

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



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

[jira] [Commented] (CASSANDRA-11303) New inbound throughput parameters for streaming

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11303:
-

Thanks for the update. I will review it next week.

> New inbound throughput parameters for streaming
> ---
>
> Key: CASSANDRA-11303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11303
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Configuration
>Reporter: Satoshi Konno
>Priority: Minor
> Attachments: 11303_inbound_limit_debug_20160419.log, 
> 11303_inbound_nolimit_debug_20160419.log, 
> 11303_inbound_patch_for_trunk_20160419.diff, 
> 11303_inbound_patch_for_trunk_20160525.diff, cassandra_inbound_stream.diff
>
>
> Hi,
> To specify stream throughputs of a node more clearly, I would like to add the 
> following new inbound parameters like existing outbound parameters in the 
> cassandra.yaml.
> - stream_throughput_inbound_megabits_per_sec
> - inter_dc_stream_throughput_outbound_megabits_per_sec  
> We use only the existing outbound parameters now, but it is difficult to 
> control the total throughputs of a node.　In our production network, some 
> critical alerts occurs when a node exceed the specified total throughput 
> which is the sum of the input and output throughputs.
> In our operation of Cassandra, the alerts occurs during the bootstrap or 
> repair processing when a new node is added. In the worst case, we have to 
> stop the operation of the exceed node.
> I have attached the patch under consideration. I would like to add a new 
> limiter class, StreamInboundRateLimiter, and use the limiter class in 
> StreamDeserializer class. I use Row::dataSize( ）to get the input throughput 
> in StreamDeserializer::newPartition(), but I am not sure whether the 
> dataSize() returns the correct data size.
> Can someone please tell me how to do it ?



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

[jira] [Commented] (CASSANDRA-11258) Repair scheduling - Resource locking API

[Marcus Olsson (JIRA)]

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

Marcus Olsson commented on CASSANDRA-11258:
---

I've pushed some new patches to the [same 
branch|https://github.com/emolsson/cassandra/commits/CASSANDRA-11258] based on 
your comments/patches. :)

---

bq. How about renaming renew(int duration) to renew(int newDuration) to make 
this more explicit?
+1

> Repair scheduling - Resource locking API
> 
>
> Key: CASSANDRA-11258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11258
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Minor
> Attachments: newDuration.patch
>
>
> Create a resource locking API & implementation that is able to lock a 
> resource in a specified data center. It should handle priorities to avoid 
> node starvation.



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

[jira] [Assigned] (CASSANDRA-11835) dtest failure in replace_address_test.TestReplaceAddress.replace_with_reset_resume_state_test

[Joel Knighton (JIRA)]

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

Joel Knighton reassigned CASSANDRA-11835:
-

Assignee: Joel Knighton  (was: Craig Kodman)

> dtest failure in 
> replace_address_test.TestReplaceAddress.replace_with_reset_resume_state_test
> -
>
> Key: CASSANDRA-11835
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11835
> Project: Cassandra
>  Issue Type: Test
>Reporter: Philip Thompson
>Assignee: Joel Knighton
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log, node4.log, node4_debug.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.2_offheap_dtest/375/testReport/replace_address_test/TestReplaceAddress/replace_with_reset_resume_state_test
> Failed on CassCI build cassandra-2.2_offheap_dtest #375
> Node4 is started up to replace the killed node3, but fails with this error:
> {code}
> ERROR [main] 2016-05-18 03:08:02,244 CassandraDaemon.java:638 - Exception 
> encountered during startup
> java.lang.RuntimeException: Cannot replace_address /127.0.0.3 because it 
> doesn't exist in gossip
> at 
> org.apache.cassandra.service.StorageService.prepareReplacementInfo(StorageService.java:529)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:775)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:709)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:595)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:300) 
> [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:516)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:625) 
> [main/:na]
> {code}
> Logs are attached.



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

[jira] [Commented] (CASSANDRA-8523) Writes should be sent to a replacement node while it is streaming in data

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-8523:


Initial route I will take is to create a new dead state for replace, that adds 
the node as replacing endpoint to TokenMetadata. When a replacement endpoint is 
added to TokenMetadata, if there's an existing down node with the same IP, then 
we remove it from natural endpoints so the replacement node no longer receive 
reads when it becomes alive in the FD and include the replacement node as 
pending joining endpoint so writes are forwarded to it. After pending ranges 
for replace are calculated the final step is to set the node as alive in the FD 
and change the dead state logic to not mark "alive" dead state nodes as DOWN 
automatically (we will probably rename this nomenclature to a better name, like 
invisible or whatever), so the FD will work as usual and remove the replacing 
endpoint from TokenMetadata (and restore it as a natural endpoint) if it 
becomes down. The current streaming logic will probably be unaffected by this, 
and the node will change its state to NORMAL after stream is finished 
completing the replace procedure.

The only downside I can think of this approach is that we will lose hints 
during a failed replace, but this is not a big deal as hints are an 
optimization, and replace will probably take longer than max_hint_window anyway.

I will start going this route, feel free to give any feedback or let me know if 
I'm missing something on this high level flow.

> Writes should be sent to a replacement node while it is streaming in data
> -
>
> Key: CASSANDRA-8523
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8523
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Richard Wagner
>Assignee: Paulo Motta
> Fix For: 2.1.x
>
>
> In our operations, we make heavy use of replace_address (or 
> replace_address_first_boot) in order to replace broken nodes. We now realize 
> that writes are not sent to the replacement nodes while they are in hibernate 
> state and streaming in data. This runs counter to what our expectations were, 
> especially since we know that writes ARE sent to nodes when they are 
> bootstrapped into the ring.
> It seems like cassandra should arrange to send writes to a node that is in 
> the process of replacing another node, just like it does for a nodes that are 
> bootstraping. I hesitate to phrase this as "we should send writes to a node 
> in hibernate" because the concept of hibernate may be useful in other 
> contexts, as per CASSANDRA-8336. Maybe a new state is needed here?
> Among other things, the fact that we don't get writes during this period 
> makes subsequent repairs more expensive, proportional to the number of writes 
> that we miss (and depending on the amount of data that needs to be streamed 
> during replacement and the time it may take to rebuild secondary indexes, we 
> could miss many many hours worth of writes). It also leaves us more exposed 
> to consistency violations.



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

[jira] [Updated] (CASSANDRA-11910) dtest failure in secondary_indexes_test.TestSecondaryIndexes.test_manual_rebuild_index

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-11910:

Labels: dtest windows  (was: dtest)

> dtest failure in 
> secondary_indexes_test.TestSecondaryIndexes.test_manual_rebuild_index
> --
>
> Key: CASSANDRA-11910
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11910
> Project: Cassandra
>  Issue Type: Test
>Reporter: Craig Kodman
>Assignee: DS Test Eng
>  Labels: dtest, windows
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest_win32/425/testReport/secondary_indexes_test/TestSecondaryIndexes/test_manual_rebuild_index
> Failed on CassCI build trunk_dtest_win32 #425



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

[jira] [Created] (CASSANDRA-11910) dtest failure in secondary_indexes_test.TestSecondaryIndexes.test_manual_rebuild_index

[Craig Kodman (JIRA)]

Craig Kodman created CASSANDRA-11910:


 Summary: dtest failure in 
secondary_indexes_test.TestSecondaryIndexes.test_manual_rebuild_index
 Key: CASSANDRA-11910
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11910
 Project: Cassandra
  Issue Type: Test
Reporter: Craig Kodman
Assignee: DS Test Eng


example failure:

http://cassci.datastax.com/job/trunk_dtest_win32/425/testReport/secondary_indexes_test/TestSecondaryIndexes/test_manual_rebuild_index

Failed on CassCI build trunk_dtest_win32 #425



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

[jira] [Commented] (CASSANDRA-8498) Replaying commit log records that are older than gc_grace is dangerous

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-8498:


bq.  We advise operators not to do this (in order to avoid zombie data), but 
there are cases where it makes sense
If the assumed majority case is "don't do this unless you really know what 
you're doing", I think we should reflect that in our operations. I'm +1 on 
failing to start w/out a specific flag that you know what you're doing, and 
having a relatively verbose log message on failed startup w/out that flag.

> Replaying commit log records that are older than gc_grace is dangerous
> --
>
> Key: CASSANDRA-8498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8498
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benedict
>
> If we replay commit log records that are older than gc_grace we could 
> introduce data corruption to the cluster. We should either (1) fail and 
> suggest a repair, or (2) log an exception. I prefer (1).



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

[jira] [Updated] (CASSANDRA-11853) Improve Cassandra-Stress latency measurement

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-11853:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Added some info to NEWS.txt and licence to lib/licences

Committed {{89f275c6587150907b90ed03ca515b12c0c6ae11}}

Thanks Nitsan! 

> Improve Cassandra-Stress latency measurement
> 
>
> Key: CASSANDRA-11853
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11853
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Nitsan Wakart
>Assignee: Nitsan Wakart
>  Labels: stress
> Fix For: 3.x
>
>
> Currently CS reports latency using a sampling latency container and reporting 
> service time (as opposed to response time from intended schedule) leading to 
> coordinated omission.
> Fixed here:
> https://github.com/nitsanw/cassandra/tree/co-correction



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

[jira] [Updated] (CASSANDRA-11853) Improve Cassandra-Stress latency measurement

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-11853:
---
Fix Version/s: (was: 3.x)
   3.8

> Improve Cassandra-Stress latency measurement
> 
>
> Key: CASSANDRA-11853
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11853
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Nitsan Wakart
>Assignee: Nitsan Wakart
>  Labels: stress
> Fix For: 3.8
>
>
> Currently CS reports latency using a sampling latency container and reporting 
> service time (as opposed to response time from intended schedule) leading to 
> coordinated omission.
> Fixed here:
> https://github.com/nitsanw/cassandra/tree/co-correction



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

[jira] [Updated] (CASSANDRA-11853) Improve Cassandra-Stress latency measurement

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-11853:
---
Labels: stress  (was: )

> Improve Cassandra-Stress latency measurement
> 
>
> Key: CASSANDRA-11853
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11853
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Nitsan Wakart
>Assignee: Nitsan Wakart
>  Labels: stress
> Fix For: 3.8
>
>
> Currently CS reports latency using a sampling latency container and reporting 
> service time (as opposed to response time from intended schedule) leading to 
> coordinated omission.
> Fixed here:
> https://github.com/nitsanw/cassandra/tree/co-correction



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

[2/2] cassandra git commit: Introduce HdrHistogram and response/service/wait separation to stress tool

[jake]

Introduce HdrHistogram and response/service/wait separation to stress tool

Patch by Nitsan Wakart; reviewed by tjake for CASSANDRA-11853


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

Branch: refs/heads/trunk
Commit: 89f275c6587150907b90ed03ca515b12c0c6ae11
Parents: d9b192e
Author: nitsanw 
Authored: Sun May 15 22:40:38 2016 +0200
Committer: T Jake Luciani 
Committed: Fri May 27 11:59:55 2016 -0400

--
 .gitignore  |   1 +
 CHANGES.txt |   1 +
 NEWS.txt|  15 +
 NOTICE.txt  |   3 +
 build.xml   |   1 +
 lib/HdrHistogram-2.1.9.jar  | Bin 0 -> 114165 bytes
 lib/licenses/hdrhistogram-2.1.9.txt | 936 +++
 .../org/apache/cassandra/stress/Operation.java  |  17 +-
 .../apache/cassandra/stress/StressAction.java   | 165 +++-
 .../apache/cassandra/stress/StressMetrics.java  | 135 ++-
 .../stress/operations/FixedOpDistribution.java  |  15 +-
 .../stress/operations/OpDistribution.java   |   9 +-
 .../operations/OpDistributionFactory.java   |  10 +-
 .../stress/operations/PartitionOperation.java   |  11 +-
 .../operations/SampledOpDistribution.java   |  18 +-
 .../SampledOpDistributionFactory.java   |  16 +-
 .../operations/userdefined/TokenRangeQuery.java |   8 +-
 .../cassandra/stress/settings/CliOption.java|   9 +-
 .../settings/SettingsCommandPreDefined.java |  12 +-
 .../cassandra/stress/settings/SettingsLog.java  |  17 +-
 .../cassandra/stress/settings/SettingsRate.java |  30 +-
 .../stress/settings/SettingsSamples.java|  94 --
 .../stress/settings/StressSettings.java |  14 +-
 .../cassandra/stress/util/SampleOfLongs.java| 111 ---
 .../org/apache/cassandra/stress/util/Timer.java | 100 +-
 .../apache/cassandra/stress/util/Timing.java|  24 +-
 .../cassandra/stress/util/TimingInterval.java   | 179 ++--
 .../cassandra/stress/util/TimingIntervals.java  |  14 +-
 28 files changed, 1456 insertions(+), 509 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/89f275c6/.gitignore
--
diff --git a/.gitignore b/.gitignore
index acaa51a..9cb8614 100644
--- a/.gitignore
+++ b/.gitignore
@@ -71,3 +71,4 @@ lib/jsr223/jython/*.jar
 lib/jsr223/jython/cachedir
 lib/jsr223/scala/*.jar
 
+/.ant-targets-build.xml

http://git-wip-us.apache.org/repos/asf/cassandra/blob/89f275c6/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 714ab1a..a70b17d 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.8
+ * Introduce HdrHistogram and response/service/wait separation to stress tool 
(CASSANDRA-11853)
  * entry-weighers in QueryProcessor should respect partitionKeyBindIndexes 
field (CASSANDRA-11718)
  * Support older ant versions (CASSANDRA-11807)
  * Estimate compressed on disk size when deciding if sstable size limit 
reached (CASSANDRA-11623)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/89f275c6/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 2f5e3b5..f8b589f 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,21 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+
+3.8
+===
+
+New features
+
+   - A new option has been added to cassandra-stress "-rate fixed={number}/s"
+ that forces a scheduled rate of operations/sec over time. Using this, 
stress can
+ accurately account for coordinated ommission from the stress process.
+   - The cassandra-stress "-rate limit=" option has been renamed to "-rate 
throttle="
+   - hdr histograms have been added to stress runs, it's output can be saved 
to disk using:
+ "-log hdrfile=" option. This histogram includes response/service/wait 
times when used with the
+ fixed or throttle rate options.  The histogram file can be plotted on
+ http://hdrhistogram.github.io/HdrHistogram/plotFiles.html
+
 3.7
 ===
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/89f275c6/NOTICE.txt
--
diff --git a/NOTICE.txt b/NOTICE.txt
index a20994f..1c552fc 100644
--- a/NOTICE.txt
+++ b/NOTICE.txt
@@ -83,3 +83,6 @@ BSD 3-clause
 ASM
 (http://asm.ow2.org/)
 Copyright 

[jira] [Resolved] (CASSANDRA-8497) Do not replay commit log records for tables that have been repaired since

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs resolved CASSANDRA-8497.

Resolution: Duplicate

Thanks, resolving as a Duplicate, then.

> Do not replay commit log records for tables that have been repaired since
> -
>
> Key: CASSANDRA-8497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8497
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benedict
>Priority: Minor
>
> If somehow we have commit log records around since prior to a repair was 
> completed, and we have repair-aware tombstone collection, then we could 
> potentially reintroduce deleted data. Since we consider repaired data to be 
> completely up-to-date, unless there has been a cross-cluster failure where 
> data only ended up in the commit log, the commit log records will by now be 
> superfluous. Some grace period may be necessary, as with CASSANDRA-6434.



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

[1/2] cassandra git commit: Introduce HdrHistogram and response/service/wait separation to stress tool

[jake]

Repository: cassandra
Updated Branches:
  refs/heads/trunk d9b192e33 -> 89f275c65


http://git-wip-us.apache.org/repos/asf/cassandra/blob/89f275c6/tools/stress/src/org/apache/cassandra/stress/StressMetrics.java
--
diff --git a/tools/stress/src/org/apache/cassandra/stress/StressMetrics.java 
b/tools/stress/src/org/apache/cassandra/stress/StressMetrics.java
index fa36716..668518c 100644
--- a/tools/stress/src/org/apache/cassandra/stress/StressMetrics.java
+++ b/tools/stress/src/org/apache/cassandra/stress/StressMetrics.java
@@ -1,6 +1,6 @@
 package org.apache.cassandra.stress;
 /*
- * 
+ *
  * Licensed to the Apache Software Foundation (ASF) under one
  * or more contributor license agreements.  See the NOTICE file
  * distributed with this work for additional information
@@ -8,53 +8,82 @@ package org.apache.cassandra.stress;
  * to you under the Apache License, Version 2.0 (the
  * "License"); you may not use this file except in compliance
  * with the License.  You may obtain a copy of the License at
- * 
+ *
  *   http://www.apache.org/licenses/LICENSE-2.0
- * 
+ *
  * Unless required by applicable law or agreed to in writing,
  * software distributed under the License is distributed on an
  * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  * KIND, either express or implied.  See the License for the
  * specific language governing permissions and limitations
  * under the License.
- * 
+ *
  */
 
 
+import static java.util.concurrent.TimeUnit.NANOSECONDS;
+
+import java.io.FileNotFoundException;
 import java.io.PrintStream;
 import java.util.Arrays;
 import java.util.List;
 import java.util.Map;
 import java.util.concurrent.Callable;
 import java.util.concurrent.CountDownLatch;
-import java.util.concurrent.ThreadFactory;
 
-import org.apache.cassandra.stress.util.*;
-import org.apache.commons.lang3.time.DurationFormatUtils;
-import org.apache.cassandra.concurrent.NamedThreadFactory;
+import org.HdrHistogram.Histogram;
+import org.HdrHistogram.HistogramLogWriter;
 import org.apache.cassandra.stress.settings.StressSettings;
+import org.apache.cassandra.stress.util.JmxCollector;
+import org.apache.cassandra.stress.util.Timing;
+import org.apache.cassandra.stress.util.TimingInterval;
+import org.apache.cassandra.stress.util.TimingIntervals;
+import org.apache.cassandra.stress.util.Uncertainty;
 import org.apache.cassandra.utils.FBUtilities;
+import org.apache.commons.lang3.time.DurationFormatUtils;
 
 public class StressMetrics
 {
 
-private static final ThreadFactory tf = new 
NamedThreadFactory("StressMetrics");
-
 private final PrintStream output;
 private final Thread thread;
-private volatile boolean stop = false;
-private volatile boolean cancelled = false;
 private final Uncertainty rowRateUncertainty = new Uncertainty();
 private final CountDownLatch stopped = new CountDownLatch(1);
 private final Timing timing;
 private final Callable gcStatsCollector;
+private final HistogramLogWriter histogramWriter;
+private final long epochNs = System.nanoTime();
+private final long epochMs = System.currentTimeMillis();
+
 private volatile JmxCollector.GcStats totalGcStats;
-private final StressSettings settings;
+
+private volatile boolean stop = false;
+private volatile boolean cancelled = false;
 
 public StressMetrics(PrintStream output, final long logIntervalMillis, 
StressSettings settings)
 {
 this.output = output;
-this.settings = settings;
+if(settings.log.hdrFile != null)
+{
+try
+{
+histogramWriter = new HistogramLogWriter(settings.log.hdrFile);
+histogramWriter.outputComment("Logging op latencies for 
Cassandra Stress");
+histogramWriter.outputLogFormatVersion();
+histogramWriter.outputBaseTime(epochMs);
+histogramWriter.setBaseTime(epochMs);
+histogramWriter.outputStartTime(epochMs);
+histogramWriter.outputLegend();
+}
+catch (FileNotFoundException e)
+{
+throw new IllegalArgumentException(e);
+}
+}
+else
+{
+histogramWriter = null;
+}
 Callable gcStatsCollector;
 totalGcStats = new JmxCollector.GcStats(0);
 try
@@ -78,10 +107,10 @@ public class StressMetrics
 };
 }
 this.gcStatsCollector = gcStatsCollector;
-this.timing = new Timing(settings.samples.historyCount, 
settings.samples.reportCount);
+this.timing = new Timing(settings.rate.isFixed);
 
 printHeader("", output);
-thread = tf.newThread(new Runnable()
+thread = new Thread(new Runnable()
 {
 @Override
 public void run()
@@ -125,6 +154,7 @@ public class StressMetrics
 }
 }
 

[jira] [Updated] (CASSANDRA-11738) Re-think the use of Severity in the DynamicEndpointSnitch calculation

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-11738:
--
Assignee: Jonathan Ellis

> Re-think the use of Severity in the DynamicEndpointSnitch calculation
> -
>
> Key: CASSANDRA-11738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11738
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeremiah Jordan
>Assignee: Jonathan Ellis
> Fix For: 3.x
>
>
> CASSANDRA-11737 was opened to allow completely disabling the use of severity 
> in the DynamicEndpointSnitch calculation, but that is a pretty big hammer.  
> There is probably something we can do to better use the score.
> The issue seems to be that severity is given equal weight with latency in the 
> current code, also that severity is only based on disk io.  If you have a 
> node that is CPU bound on something (say catching up on LCS compactions 
> because of bootstrap/repair/replace) the IO wait can be low, but the latency 
> to the node is high.
> Some ideas I had are:
> 1. Allowing a yaml parameter to tune how much impact the severity score has 
> in the calculation.
> 2. Taking CPU load into account as well as IO Wait (this would probably help 
> in the cases I have seen things go sideways)
> 3. Move the -D from CASSANDRA-11737 to being a yaml level setting
> 4. Go back to just relying on Latency and get rid of severity all together.  
> Now that we have rapid read protection, maybe just using latency is enough, 
> as it can help where the predictive nature of IO wait would have been useful.



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

[jira] [Updated] (CASSANDRA-11738) Re-think the use of Severity in the DynamicEndpointSnitch calculation

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11738:

Reviewer: Robert Stupp

> Re-think the use of Severity in the DynamicEndpointSnitch calculation
> -
>
> Key: CASSANDRA-11738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11738
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeremiah Jordan
>Assignee: Jonathan Ellis
> Fix For: 3.x
>
>
> CASSANDRA-11737 was opened to allow completely disabling the use of severity 
> in the DynamicEndpointSnitch calculation, but that is a pretty big hammer.  
> There is probably something we can do to better use the score.
> The issue seems to be that severity is given equal weight with latency in the 
> current code, also that severity is only based on disk io.  If you have a 
> node that is CPU bound on something (say catching up on LCS compactions 
> because of bootstrap/repair/replace) the IO wait can be low, but the latency 
> to the node is high.
> Some ideas I had are:
> 1. Allowing a yaml parameter to tune how much impact the severity score has 
> in the calculation.
> 2. Taking CPU load into account as well as IO Wait (this would probably help 
> in the cases I have seen things go sideways)
> 3. Move the -D from CASSANDRA-11737 to being a yaml level setting
> 4. Go back to just relying on Latency and get rid of severity all together.  
> Now that we have rapid read protection, maybe just using latency is enough, 
> as it can help where the predictive nature of IO wait would have been useful.



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

[jira] [Updated] (CASSANDRA-11152) SOURCE command in CQLSH 3.2 requires that "use keyspace" is in the cql file that you are sourcing

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-11152:
-
Assignee: Stefania

> SOURCE command in CQLSH 3.2 requires that "use keyspace" is in the cql file 
> that you are sourcing
> -
>
> Key: CASSANDRA-11152
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11152
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: CQLSH 3.2.1
>Reporter: Francesco Animali
>Assignee: Stefania
>
> a difference in behaviour between SOURCE command in CQLSH 3.1 and 3.2. 
> In CQLSH 3.1 SOURCE will NOT require "use keyspace" in the cql file that you 
> execute: the "keyspace" directive in the qlshrc file will work and the cql 
> file will be executed.
> In CQLSH 3.2.1, SOURCE command requires that "use keyspace" is in the cql 
> file that you are sourcing, otherwise it throws this error:
> "No keyspace has been specified. USE a keyspace, or explicitly specify 
> keyspace.tablename". 
> The "keyspace" directive in cqlshrc is overridden by source command.
> steps to reproduce:
> create a file called select.cql in your home directory:
> {noformat}
> echo "CONSISTENCY ONE;" > select.cql
> echo "select * from tab;" >> select.cql
> {noformat}
> in cqlsh:
> {noformat}
> create KEYSPACE kspace WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> create TABLE tab ( id int primary key);
> insert into tab (id) VALUES ( 1);
> {noformat}
> Add this to cqlsgrc:
> {noformat}
> [authentication]
> keyspace = kspace
> {noformat}
> Then exit cqlsh and rerun cqlsh using the cqlshrc just modified.
> Note that you are in keyspace "kspace".
> execute:
> {noformat}
> source 'select.cql' 
> {noformat}
> this will have different behaviour in CQLSH 3.2 and 3.1



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

[jira] [Assigned] (CASSANDRA-11900) Cassandra will not start after upgrade to 3.3

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko reassigned CASSANDRA-11900:
-

Assignee: Aleksey Yeschenko

> Cassandra will not start after upgrade to 3.3
> -
>
> Key: CASSANDRA-11900
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11900
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Linux Centos7 3.10.0-327.10.1.el7.x86_64
>Reporter: Chris Bordman
>Assignee: Aleksey Yeschenko
> Fix For: 3.x
>
> Attachments: schema.txt
>
>
> {code}
> INFO  [main] 2016-05-26 08:36:04,922 SystemKeyspace.java:1285 - Detected 
> version upgrade from 2.1.11 to 3.3.0, snapshotting system keyspace
> WARN  [main] 2016-05-26 08:36:05,152 CompressionParams.java:382 - The 
> sstable_compression option has been deprecated. You should use class instead
> ERROR [main] 2016-05-26 08:36:05,162 CassandraDaemon.java:697 - Exception 
> encountered during startup
> java.lang.IllegalStateException: One row required, 2 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:84)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTableTimestamp(LegacySchemaMigrator.java:253)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTable(LegacySchemaMigrator.java:243)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readTables$243(LegacySchemaMigrator.java:237)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at java.util.ArrayList.forEach(Unknown Source) ~[na:1.8.0_74]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTables(LegacySchemaMigrator.java:237)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readKeyspace(LegacySchemaMigrator.java:186)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readSchema$240(LegacySchemaMigrator.java:177)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at java.util.ArrayList.forEach(Unknown Source) ~[na:1.8.0_74]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readSchema(LegacySchemaMigrator.java:177)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.migrate(LegacySchemaMigrator.java:77)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:223) 
> [apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:551)
>  [apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:680) 
> [apache-cassandra-3.3.0.jar:3.3.0]
> {code}



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

[jira] [Updated] (CASSANDRA-11899) Please create a swarm decommission mode

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-11899:
--
Summary: Please create a swarm decommission mode  (was: Please create a 
swarm decommission node)

> Please create a swarm decommission mode
> ---
>
> Key: CASSANDRA-11899
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11899
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Mark Danko
>Priority: Minor
>
> Right now when I remove a node that is up I understand 2 choices.
> nodetool decommission:  The current hosts starts sending out data as the only 
> source. This takes a long time. The one node you want to remove becomes a 
> huge bottle neck (even worse if you want to remove it because it is under 
> performing).
> cassandra stop, then nodetool removenode: This lets all other nodes  that 
> share the keyranges be sources. This runs about 8-16X faster than 
> decommission on my system, but this requires me to run with reduced 
> redundancy when it happens.
> I think it would be really cool if there was a way to decommission a node 
> that is up, and leverage the power of other data sources.
> Request : When you decommission a node all other nodes that share a keyrange 
> should also help in being sources for the data that needs to be copied.  
> Maybe, with options for how far to get the data/balance of load:  old 
> behavior, same rack, same dc, other dc (or some default scheme based on 
> latency between nodes/racks/dcs). 



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

[jira] [Updated] (CASSANDRA-9126) java.lang.RuntimeException: Last written key DecoratedKey >= current key DecoratedKey

[Cyril Scetbon (JIRA)]

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

Cyril Scetbon updated CASSANDRA-9126:
-
Reproduced In: 2.1.12, 2.0.14  (was: 2.0.14, 2.1.11)

> java.lang.RuntimeException: Last written key DecoratedKey >= current key 
> DecoratedKey
> -
>
> Key: CASSANDRA-9126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9126
> Project: Cassandra
>  Issue Type: Bug
>Reporter: srinivasu gottipati
>Priority: Critical
> Attachments: cassandra-system.log
>
>
> Cassandra V: 2.0.14,
> Getting the following exceptions while trying to compact (I see this issue 
> was raised in earlier versions and marked as closed. However it still appears 
> in 2.0.14). In our case, compaction is not getting succeeded and keep failing 
> with this error.:
> {code}java.lang.RuntimeException: Last written key 
> DecoratedKey(3462767860784856708, 
> 354038323137333038305f3330325f31355f474d4543454f) >= current key 
> DecoratedKey(3462334604624154281, 
> 354036333036353334315f3336315f31355f474d4543454f) writing into {code}
> ...
> Stacktrace:{code}
>   at 
> org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:143)
>   at 
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:166)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:167)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60)
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:198)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745){code}
> Any help is greatly appreciated



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

[jira] [Updated] (CASSANDRA-11893) Reenable commented out tests in CompactionsTest

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11893:

Assignee: Sylvain Lebresne

> Reenable commented out tests in CompactionsTest
> ---
>
> Key: CASSANDRA-11893
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11893
> Project: Cassandra
>  Issue Type: Test
>Reporter: Marcus Eriksson
>Assignee: Sylvain Lebresne
>
> CASSANDRA-8099 commented out a bunch of tests in CompactionsTest - we should 
> either make these work again or remove them.



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

[jira] [Updated] (CASSANDRA-11892) Can not replace a dead host

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11892:

Reviewer: Joel Knighton

> Can not replace a dead host
> ---
>
> Key: CASSANDRA-11892
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11892
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
> Attachments: 0001-handle-hibernate-case.patch
>
>
> I got some errors when trying to replace a dead host.
> {code}
> 2016-05-25_20:59:37.61838 ERROR 20:59:37 [main]: Exception encountered during 
> startup
> 2016-05-25_20:59:37.61839 java.lang.UnsupportedOperationException: Cannot 
> replace token 100284002935427428580945058996711341062 which does not exist!
> 2016-05-25_20:59:37.61839   at 
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:925)
>  ~[apache-cassandra-2.1.14+git20160523.7442267.jar:2.1.14+git20160523.7442267]
> 2016-05-25_20:59:37.61839   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:740)
>  ~[apache-cassandra-2.1.14+git20160523.7442267.jar:2.1.14+git20160523.7442267]
> 2016-05-25_20:59:37.61839   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:617)
>  ~[apache-cassandra-2.1.14+git20160523.7442267.jar:2.1.14+git20160523.7442267]
> 2016-05-25_20:59:37.61840   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:389) 
> [apache-cassandra-2.1.14+git20160523.7442267.jar:2.1.14+git20160523.7442267]
> 2016-05-25_20:59:37.61840   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564)
>  [apache-cassandra-2.1.14+git20160523.7442267.jar:2.1.14+git20160523.7442267]
> 2016-05-25_20:59:37.61841   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:653) 
> [apache-cassandra-2.1.14+git20160523.7442267.jar:2.1.14+git20160523.7442267]
> 2016-05-25_20:59:37.61910 Exception encountered during startup: Cannot 
> replace token 100284002935427428580945058996711341062 which does not exist!
> {code}
> the status of the node is DN:
> {code}
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> --  Address  Load   Tokens  OwnsHost ID   
> Rack
> DN  2401:db00:2050:4196:face:0:13:0  809.83 GB  256 ?   null  
> ash5-04-pp
> {code}
> I add some logging and find something like this:
> {code}
> 2016-05-25_20:58:33.44305 INFO  20:58:33 [main]: Gathering node replacement 
> information for /2401:db00:2050:4196:face:0:13:0
> 2016-05-25_20:58:34.36966 INFO  20:58:34 [GossipStage:1]: InetAddress 
> /2401:db00:2050:4196:face:0:13:0 is now DOWN
> 2016-05-25_20:58:41.12167 INFO  20:58:41 [GossipStage:1]: InetAddress 
> /2401:db00:2050:4196:face:0:13:0 is now DOWN
> 2016-05-25_20:58:41.12248 INFO  20:58:41 [GossipStage:1]: Node 
> /2401:db00:2050:4196:face:0:13:0 state STATUS
> 2016-05-25_20:58:41.12250 INFO  20:58:41 [GossipStage:1]: Node 
> /2401:db00:2050:4196:face:0:13:0 movename hibernate
> 2016-05-25_20:58:41.12252 INFO  20:58:41 [GossipStage:1]: Node 
> /2401:db00:2050:4196:face:0:13:0 state LOAD
> {code}
> I find in the StorageService.onChange, we do not handle the "hibernate" 
> VersionValue, does it cause the problem?
> Is it safe to apply the patch to fix it?



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

[jira] [Updated] (CASSANDRA-9126) java.lang.RuntimeException: Last written key DecoratedKey >= current key DecoratedKey

[Cyril Scetbon (JIRA)]

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

Cyril Scetbon updated CASSANDRA-9126:
-
Reproduced In: 2.1.11, 2.0.14  (was: 2.0.14, 2.1.11)

> java.lang.RuntimeException: Last written key DecoratedKey >= current key 
> DecoratedKey
> -
>
> Key: CASSANDRA-9126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9126
> Project: Cassandra
>  Issue Type: Bug
>Reporter: srinivasu gottipati
>Priority: Critical
> Attachments: cassandra-system.log
>
>
> Cassandra V: 2.0.14,
> Getting the following exceptions while trying to compact (I see this issue 
> was raised in earlier versions and marked as closed. However it still appears 
> in 2.0.14). In our case, compaction is not getting succeeded and keep failing 
> with this error.:
> {code}java.lang.RuntimeException: Last written key 
> DecoratedKey(3462767860784856708, 
> 354038323137333038305f3330325f31355f474d4543454f) >= current key 
> DecoratedKey(3462334604624154281, 
> 354036333036353334315f3336315f31355f474d4543454f) writing into {code}
> ...
> Stacktrace:{code}
>   at 
> org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:143)
>   at 
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:166)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:167)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60)
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:198)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745){code}
> Any help is greatly appreciated



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

[jira] [Reopened] (CASSANDRA-9126) java.lang.RuntimeException: Last written key DecoratedKey >= current key DecoratedKey

[Cyril Scetbon (JIRA)]

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

Cyril Scetbon reopened CASSANDRA-9126:
--
Reproduced In: 2.1.11, 2.0.14  (was: 2.0.14)

> java.lang.RuntimeException: Last written key DecoratedKey >= current key 
> DecoratedKey
> -
>
> Key: CASSANDRA-9126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9126
> Project: Cassandra
>  Issue Type: Bug
>Reporter: srinivasu gottipati
>Priority: Critical
> Attachments: cassandra-system.log
>
>
> Cassandra V: 2.0.14,
> Getting the following exceptions while trying to compact (I see this issue 
> was raised in earlier versions and marked as closed. However it still appears 
> in 2.0.14). In our case, compaction is not getting succeeded and keep failing 
> with this error.:
> {code}java.lang.RuntimeException: Last written key 
> DecoratedKey(3462767860784856708, 
> 354038323137333038305f3330325f31355f474d4543454f) >= current key 
> DecoratedKey(3462334604624154281, 
> 354036333036353334315f3336315f31355f474d4543454f) writing into {code}
> ...
> Stacktrace:{code}
>   at 
> org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:143)
>   at 
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:166)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:167)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60)
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:198)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745){code}
> Any help is greatly appreciated



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

[jira] [Updated] (CASSANDRA-11892) Can not replace a dead host

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-11892:
--
Status: Patch Available  (was: Open)

> Can not replace a dead host
> ---
>
> Key: CASSANDRA-11892
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11892
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
> Attachments: 0001-handle-hibernate-case.patch
>
>
> I got some errors when trying to replace a dead host.
> {code}
> 2016-05-25_20:59:37.61838 ERROR 20:59:37 [main]: Exception encountered during 
> startup
> 2016-05-25_20:59:37.61839 java.lang.UnsupportedOperationException: Cannot 
> replace token 100284002935427428580945058996711341062 which does not exist!
> 2016-05-25_20:59:37.61839   at 
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:925)
>  ~[apache-cassandra-2.1.14+git20160523.7442267.jar:2.1.14+git20160523.7442267]
> 2016-05-25_20:59:37.61839   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:740)
>  ~[apache-cassandra-2.1.14+git20160523.7442267.jar:2.1.14+git20160523.7442267]
> 2016-05-25_20:59:37.61839   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:617)
>  ~[apache-cassandra-2.1.14+git20160523.7442267.jar:2.1.14+git20160523.7442267]
> 2016-05-25_20:59:37.61840   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:389) 
> [apache-cassandra-2.1.14+git20160523.7442267.jar:2.1.14+git20160523.7442267]
> 2016-05-25_20:59:37.61840   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564)
>  [apache-cassandra-2.1.14+git20160523.7442267.jar:2.1.14+git20160523.7442267]
> 2016-05-25_20:59:37.61841   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:653) 
> [apache-cassandra-2.1.14+git20160523.7442267.jar:2.1.14+git20160523.7442267]
> 2016-05-25_20:59:37.61910 Exception encountered during startup: Cannot 
> replace token 100284002935427428580945058996711341062 which does not exist!
> {code}
> the status of the node is DN:
> {code}
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> --  Address  Load   Tokens  OwnsHost ID   
> Rack
> DN  2401:db00:2050:4196:face:0:13:0  809.83 GB  256 ?   null  
> ash5-04-pp
> {code}
> I add some logging and find something like this:
> {code}
> 2016-05-25_20:58:33.44305 INFO  20:58:33 [main]: Gathering node replacement 
> information for /2401:db00:2050:4196:face:0:13:0
> 2016-05-25_20:58:34.36966 INFO  20:58:34 [GossipStage:1]: InetAddress 
> /2401:db00:2050:4196:face:0:13:0 is now DOWN
> 2016-05-25_20:58:41.12167 INFO  20:58:41 [GossipStage:1]: InetAddress 
> /2401:db00:2050:4196:face:0:13:0 is now DOWN
> 2016-05-25_20:58:41.12248 INFO  20:58:41 [GossipStage:1]: Node 
> /2401:db00:2050:4196:face:0:13:0 state STATUS
> 2016-05-25_20:58:41.12250 INFO  20:58:41 [GossipStage:1]: Node 
> /2401:db00:2050:4196:face:0:13:0 movename hibernate
> 2016-05-25_20:58:41.12252 INFO  20:58:41 [GossipStage:1]: Node 
> /2401:db00:2050:4196:face:0:13:0 state LOAD
> {code}
> I find in the StorageService.onChange, we do not handle the "hibernate" 
> VersionValue, does it cause the problem?
> Is it safe to apply the patch to fix it?



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

[jira] [Updated] (CASSANDRA-11888) cassandra-env.sh may not work properly with jvm args containing a space

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-11888:
-
Labels: lhf  (was: )

> cassandra-env.sh may not work properly with jvm args containing a space
> ---
>
> Key: CASSANDRA-11888
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11888
> Project: Cassandra
>  Issue Type: Bug
> Environment: linux
>Reporter: Russ Hatch
>Priority: Minor
>  Labels: lhf
>
> When using the JVM_EXTRA_OPTS environment variable, it looks like there's 
> some cases that may not work if an env var contains a space.
> For example, setting:
> {noformat}
> export JVM_EXTRA_OPTS='-XX:OnOutOfMemoryError="echo oh_no"'
> {noformat}
> Results in the jvm not starting because the resultant startup command looks 
> to java like it should load a class called oh_no.
> {noformat}
> Error: Could not find or load main class oh_no
> {noformat}
> I think this results from the last line of cassandra-env.sh, where it does 
> this:
> {noformat}
> JVM_OPTS="$JVM_OPTS $JVM_EXTRA_OPTS"
> {noformat}



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

[jira] [Updated] (CASSANDRA-11872) Don't force PartitionRangeReadCommand for 2ndary index queries on single partition

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-11872:
-
Issue Type: Improvement  (was: Bug)

> Don't force PartitionRangeReadCommand for 2ndary index queries on single 
> partition
> --
>
> Key: CASSANDRA-11872
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11872
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Priority: Minor
> Fix For: 3.x
>
>
> As mentioned multiple times (CASSANDRA-11617, CASSANDRA-11310 and 
> CASSANDRA-11043 at least), we currently force the use of 
> {{PartitionRangeReadCommand}} when a 2ndary index is in use, even if the 
> query is restricted to a single partition. Which is due to technical debt and 
> we should be able to change that after CASSANDRA-8099 and use 
> {{SinglePartitionReadCommand}}, which would be slightly faster and overall 
> more intuitive/logic.
> We mostly need to test carefully that change to make sure we don't break 
> anything.



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

[jira] [Commented] (CASSANDRA-9126) java.lang.RuntimeException: Last written key DecoratedKey >= current key DecoratedKey

[jean carlo rivera ura (JIRA)]

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

jean carlo rivera ura commented on CASSANDRA-9126:
--

[~mambocab] We are using cassandra 2.1.12

In production we got a first error doing a repair (-pr -par)

ERROR [ValidationExecutor:3283] 2016-05-26 09:37:37,911 Validator.java:245 - 
Failed creating a merkle tree for [repair #b16c1f30-2314-11e6-97fe-dd058ca99653 
on pns_fr_prod/pig, (8699512854132214411,8702471448538509513]], /10.98.255.144 
(see log for details)
node021.cassandra.prod.pns.s1.p.fti.net: 
/var/opt/hosting/log/cassandra/system.log-ERROR [ValidationExecutor:3283] 
2016-05-26 09:37:37,913 CassandraDaemon.java:227 - Exception in thread 
Thread[ValidationExecutor:3283,1,main]
node021.cassandra.prod.pns.s1.p.fti.net: 
/var/opt/hosting/log/cassandra/system.log-java.lang.AssertionError: row 
DecoratedKey(8699513492008207074, 434c503031303030303030303036363632323233) 
received out of order wrt DecoratedKey(8702470199759211565, 
4b454e4f42494a52432d435531303330313532323130

We decided to do another a repair over this token range 
8699512854132214411,8702471448538509513 using the next command.

root@node021[SPH][PROD][PnS3]:~$ nodetool repair pns_fr_prod  -st 
8699512854132214411 -et 8702471448538509513
[2016-05-27 14:19:20,768] Starting repair command #37, repairing 1 ranges for 
keyspace pns_fr_prod (parallelism=SEQUENTIAL, full=true)
[2016-05-27 14:19:38,489] Repair session 3dd2f250-2405-11e6-b33f-ab1665ddb9c0 
for range (8699512854132214411,8702471448538509513] failed with error 
org.apache.cassandra.exceptions.RepairException: [repair 
#3dd2f250-2405-11e6-b33f-ab1665ddb9c0 on pns_fr_prod/syndic, 
(8699512854132214411,8702471448538509513]] Validation failed in /10.234.72.137
[2016-05-27 14:19:38,489] Repair command #37 finished
error: nodetool failed, check server logs
-- StackTrace --
java.lang.RuntimeException: nodetool failed, check server logs
at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:292)
at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:204)


Unlike the first time, this error comes from the node 10.234.72.137. Checking 
the log, the node failed creating a merkle tree for the table syndic. This 
table is LCS

ERROR [ValidationExecutor:3427] 2016-05-27 14:19:38,466 Validator.java:245 - 
Failed creating a merkle tree for [repair #3dd2f250-2405-11e6-b33f-ab1665ddb9c0 
on pns_fr_prod/syndic, (8699512854132214411,8702471448538509513]], 
/10.98.255.154 (see log for details)
ERROR [ValidationExecutor:3427] 2016-05-27 14:19:38,467 
CassandraDaemon.java:227 - Exception in thread 
Thread[ValidationExecutor:3427,1,main]
java.lang.AssertionError: row DecoratedKey(8699513197702636918, 
49442d5350502d3130302d54513944486f7333704e68492b387a6e786870653347614d766a683259776a5543446d4b397a393545)
 received out of order wrt DecoratedKey(8702471248515353880, 
49442d5350502d3130302d704a3063676b4446714b5075644b68654273672f686c6a4759767264724f4b6e664d3176765a7a70416d6b)
at org.apache.cassandra.repair.Validator.add(Validator.java:126) 
~[apache-cassandra-2.1.12.jar:2.1.12]
at 
org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:1038)
 ~[apache-cassandra-2.1.12.jar:2.1.12]
at 
org.apache.cassandra.db.compaction.CompactionManager.access$600(CompactionManager.java:89)
 ~[apache-cassandra-2.1.12.jar:2.1.12]
at 
org.apache.cassandra.db.compaction.CompactionManager$9.call(CompactionManager.java:649)
 ~[apache-cassandra-2.1.12.jar:2.1.12]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_60]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_60]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_60]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]

We tried to run again the same repair on the same node with the same tokenrange 
and it finished without error

root@node021[SPH][PROD][PnS3]:~$ nodetool repair pns_fr_prod  -st 
8699512854132214411 -et 8702471448538509513 
[2016-05-27 14:27:00,419] Starting repair command #38, repairing 1 ranges for 
keyspace pns_fr_prod (parallelism=SEQUENTIAL, full=true)
[2016-05-27 14:36:18,239] Repair session 4fcda620-2406-11e6-b33f-ab1665ddb9c0 
for range (8699512854132214411,8702471448538509513] finished
[2016-05-27 14:36:18,239] Repair command #38 finished

It seems this error comes up by hazard. We notice that our first repair -pr 
-par has finished repairing all the tokenranges, but that one we got the error.








> java.lang.RuntimeException: Last written key DecoratedKey >= current key 
> DecoratedKey
> -
>
> Key: CASSANDRA-9126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9126
> 

[jira] [Created] (CASSANDRA-11909) dtest failure in cql_tests.AbortedQueriesTester.remote_query_test

[Craig Kodman (JIRA)]

Craig Kodman created CASSANDRA-11909:


 Summary: dtest failure in 
cql_tests.AbortedQueriesTester.remote_query_test
 Key: CASSANDRA-11909
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11909
 Project: Cassandra
  Issue Type: Test
Reporter: Craig Kodman
Assignee: DS Test Eng


example failure:

http://cassci.datastax.com/job/trunk_dtest/1243/testReport/cql_tests/AbortedQueriesTester/remote_query_test

Failed on CassCI build trunk_dtest #1243



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

[jira] [Commented] (CASSANDRA-8496) Remove MemtablePostFlusher

[T Jake Luciani (JIRA)]

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

T Jake Luciani commented on CASSANDRA-8496:
---

Regarding #6 this is something we have seen before when working on MV code 
CASSANDRA-10231.
I think our existing "fix" is to force blocking flush for any node metadata 
change which is pretty easy to miss.

I think we should consider one of 2 things)
  
  1. Playing system table mutations first (which would require 2 passes)
  2. Keep a simple commit log for only system tables which we would order via a 
single thread. and replay first on startup. 

I guess you could get into the reverse problem here though.  A commit log 
contains old table format changes but the new table metadata has already been 
applied.

> Remove MemtablePostFlusher
> --
>
> Key: CASSANDRA-8496
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8496
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benedict
>Assignee: Branimir Lambov
>Priority: Minor
>
> To improve clearing of the CL, prevent infinite growth, and ensure the prompt 
> completion of tasks waiting on flush in the case of transient errors, large 
> flushes or slow disks, in 2.1 we could eliminate the post flusher altogether. 
> Since we now enforce that Memtables track contiguous ranges, a relatively 
> small change would permit Memtables to know the exact minimum as well as the 
> currently known exact maximum. The CL could easily track the total dirty 
> range, knowing that it must be contiguous, by using an AtomicLong instead of 
> an AtomicInteger, and tracking both the min/max seen, not just the max. The 
> only slight complexity will come in for tracking the _clean_ range as this 
> can now be non-contiguous, if there are 3 memtable flushes covering the same 
> CL segment, and one of them completes later. To solve this we can use an 
> interval tree since these operations are infrequent, so the extra overhead is 
> nominal. Once the interval tree completely overlaps the dirty range, we mark 
> the entire dirty range clean.



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

[jira] [Commented] (CASSANDRA-11670) Error while waiting on bootstrap to complete. Bootstrap will have to be restarted. Stream failed

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-11670:
---

I could be wrong, but I'm not sure this is correct. If you are splitting a 
batch, then you need to ensure that you don't remove any part of it until all 
of the parts got replayed.

> Error while waiting on bootstrap to complete. Bootstrap will have to be 
> restarted. Stream failed
> 
>
> Key: CASSANDRA-11670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11670
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Streaming and Messaging
>Reporter: Anastasia Osintseva
>Assignee: Paulo Motta
> Fix For: 3.0.5
>
>
> I have in cluster 2 DC, in each DC - 2 Nodes. I wanted to add 1 node to each 
> DC. One node has been added successfully after I had made scrubing. 
> Now I'm trying to add node to another DC, but get error: 
> org.apache.cassandra.streaming.StreamException: Stream failed. 
> After scrubing and repair I get the same error.  
> {noformat}
> ERROR [StreamReceiveTask:5] 2016-04-27 00:33:21,082 Keyspace.java:492 - 
> Unknown exception caught while attempting to update MaterializedView! 
> messages_dump.messages
> java.lang.IllegalArgumentException: Mutation of 34974901 bytes is too large 
> for the maxiumum size of 33554432
>   at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:264) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:469) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:384) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:205) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:217) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.batchlog.BatchlogManager.store(BatchlogManager.java:146) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:724) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.db.view.ViewManager.pushViewReplicaUpdates(ViewManager.java:149)
>  ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:487) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:384) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:205) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:217) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.applyUnsafe(Mutation.java:236) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.streaming.StreamReceiveTask$OnCompletionRunnable.run(StreamReceiveTask.java:169)
>  [apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_11]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_11]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_11]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_11]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_11]
> ERROR [StreamReceiveTask:5] 2016-04-27 00:33:21,082 
> StreamReceiveTask.java:214 - Error applying streamed data: 
> java.lang.IllegalArgumentException: Mutation of 34974901 bytes is too large 
> for the maxiumum size of 33554432
>   at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:264) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:469) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:384) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:205) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:217) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.batchlog.BatchlogManager.store(BatchlogManager.java:146) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:724) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.db.view.ViewManager.pushViewReplicaUpdates(ViewManager.java:149)
>  ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at 

[jira] [Created] (CASSANDRA-11908) Track message sizes for dropped mutations

[Jeremiah Jordan (JIRA)]

Jeremiah Jordan created CASSANDRA-11908:
---

 Summary: Track message sizes for dropped mutations
 Key: CASSANDRA-11908
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11908
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jeremiah Jordan


CASSANDRA-10580 and a couple other recent tickets have added more stats for 
tracking dropped messages, it would be good to add the sizes of the messages 
being dropped to those stats.  One of the main things I have seen that can lead 
to stuff taking a long time is just things being too big, it would be nice to 
be able to tell if that was the problem from the dropped messages logs and JMX 
stats.



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

[jira] [Created] (CASSANDRA-11907) 2i behaviour is different in different versions

[Tommy Stendahl (JIRA)]

Tommy Stendahl created CASSANDRA-11907:
--

 Summary: 2i behaviour is different in different versions
 Key: CASSANDRA-11907
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11907
 Project: Cassandra
  Issue Type: Bug
Reporter: Tommy Stendahl


 I think I have found more cases where 2i behave different in different 
Cassandra versions, CASSANDRA-11510 solved one such case but I think there are 
a few more.

I get one behaviour with 2.1.14 and Trunk and I think this is the correct one. 
With 2.2.7 and 3.0.6 the behaviour is different.

To test this I used ccm to setup one node clusters with the different versions, 
I prepared each cluster with these commands:
{code:sql}
CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy', 
'datacenter1': '1' };
CREATE TABLE test.table1 (name text,class int,inter text,foo text,power 
int,PRIMARY KEY (name, class, inter, foo)) WITH CLUSTERING ORDER BY (class 
DESC, inter ASC);
CREATE INDEX table1_power ON test.table1 (power) ;
CREATE TABLE test.table2 (name text,class int,inter text,foo text,power 
int,PRIMARY KEY (name, class, inter, foo)) WITH CLUSTERING ORDER BY (class 
DESC, inter ASC);
CREATE INDEX table2_inter ON test.table2 (inter) ;
{code}

I executed two select quieries on each cluster:
{code:sql}
SELECT * FROM test.table1 where name='R1' AND class>0 AND class<4 AND 
inter='int1' AND power=18 ALLOW FILTERING;
SELECT * FROM test.table2 where name='R1' AND class>0 AND class<4 AND 
inter='int1' AND foo='aa' ALLOW FILTERING;
{code}

On 2.1.14 and Trunk they where successful. But on 2.2.7 and 3.0.6 they failed, 
the first one with {{InvalidRequest: code=2200 [Invalid query] 
message="Clustering column "inter" cannot be restricted (preceding column 
"class" is restricted by a non-EQ relation)"}} and the second one with 
{{InvalidRequest: code=2200 [Invalid query] message="Clustering column "foo" 
cannot be restricted (preceding column "inter" is restricted by a non-EQ 
relation)"}}.

I could get the queries to execute successfully on 2.2.7 and 3.0.6 by creating 
two more 2i:
{code:sql}
CREATE INDEX table1_inter ON test.table1 (inter) ;
CREATE INDEX table2_foo ON test.table2 (foo) ;
{code}



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

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

[Stefano Ortolani (JIRA)]

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

Stefano Ortolani commented on CASSANDRA-11889:
--

Done https://issues.apache.org/jira/browse/CASSANDRA-11906
Let me know if more info are needed.


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

[jira] [Created] (CASSANDRA-11906) Unstable JVM due too many files when anticompacting big LCS tables

[Stefano Ortolani (JIRA)]

Stefano Ortolani created CASSANDRA-11906:


 Summary: Unstable JVM due too many files when anticompacting big 
LCS tables
 Key: CASSANDRA-11906
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11906
 Project: Cassandra
  Issue Type: Bug
Reporter: Stefano Ortolani


I have recently moved from C* 2.1.x to C* 3.0.6. The setup is quite 
heavy:
- 13 nodes with spinning disks
- ~120 GB of data per node
- 50% of CFs are LCS and have quite wide rows.
- 2/3 CFs with LCS have more than 200 SStables

Incremental repairs do not seem to play really well with that.
I have been running some tests node by node by using the -pr option:

{code:xml}
nodetool -h localhost repair -pr keyscheme
{code}

and to my surprise the whole process takes quite some time (1 hour
minimum, 8 hours if I haven't been repairing for 5/6 days).

Yesterday I tried to run the command with the -seq option so to 
decrease the number of simultanoues compactions. After a while
the node on which I was running the repair simply died during
the anticompaction phase with the following
exception in the logs.

{code:xml}
ERROR [metrics-graphite-reporter-1-thread-1] 2016-05-25 21:54:21,868 
ScheduledReporter.java:119 - RuntimeException thrown from 
GraphiteReporter#report. Exception was suppressed.
java.lang.RuntimeException: Failed to list files in 
/data/cassandra/data/keyschema/columnfamily-3996ce80b7ac11e48a9b6776bf484396
at 
org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:57)
 ~[apache-cassandra-3.0.6.jar:3.0.6]
at 
org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:547)
 ~[apache-cassandra-3.0.6.jar:3.0.6]
at 
org.apache.cassandra.db.Directories$SSTableLister.filter(Directories.java:691) 
~[apache-cassandra-3.0.6.jar:3.0.6]
at 
org.apache.cassandra.db.Directories$SSTableLister.listFiles(Directories.java:662)
 ~[apache-cassandra-3.0.6.jar:3.0.6]
at 
org.apache.cassandra.db.Directories$TrueFilesSizeVisitor.(Directories.java:981)
 ~[apache-cassandra-3.0.6.jar:3.0.6]
at 
org.apache.cassandra.db.Directories.getTrueAllocatedSizeIn(Directories.java:893)
 ~[apache-cassandra-3.0.6.jar:3.0.6]
at 
org.apache.cassandra.db.Directories.trueSnapshotsSize(Directories.java:883) 
~[apache-cassandra-3.0.6.jar:3.0.6]
at 
org.apache.cassandra.db.ColumnFamilyStore.trueSnapshotsSize(ColumnFamilyStore.java:2332)
 ~[apache-cassandra-3.0.6.jar:3.0.6]
at 
org.apache.cassandra.metrics.TableMetrics$32.getValue(TableMetrics.java:637) 
~[apache-cassandra-3.0.6.jar:3.0.6]
at 
org.apache.cassandra.metrics.TableMetrics$32.getValue(TableMetrics.java:634) 
~[apache-cassandra-3.0.6.jar:3.0.6]
at 
com.codahale.metrics.graphite.GraphiteReporter.reportGauge(GraphiteReporter.java:281)
 ~[metrics-graphite-3.1.0.jar:3.1.0]
at 
com.codahale.metrics.graphite.GraphiteReporter.report(GraphiteReporter.java:158)
 ~[metrics-graphite-3.1.0.jar:3.1.0]
at 
com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162) 
~[metrics-core-3.1.0.jar:3.1.0]
at 
com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117) 
~[metrics-core-3.1.0.jar:3.1.0]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_91]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
[na:1.8.0_91]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
 [na:1.8.0_91]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
 [na:1.8.0_91]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_91]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_91]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
Caused by: java.lang.RuntimeException: java.nio.file.FileSystemException: 
/data/cassandra/data/keyschema/columnfamily-3996ce80b7ac11e48a9b6776bf484396/ma_txn_anticompactionafterrepair_f20b50d0-22bd-11e6-970f-6f22464f4624.log:
 Too many open files
at org.apache.cassandra.io.util.FileUtils.readLines(FileUtils.java:622) 
~[apache-cassandra-3.0.6.jar:3.0.6]
at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1321) 
~[na:1.8.0_91]
at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169) 
~[na:1.8.0_91]
at 
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) 
~[na:1.8.0_91]
at java.util.Iterator.forEachRemaining(Iterator.java:116) ~[na:1.8.0_91]
at 
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
 ~[na:1.8.0_91]
at 

[jira] [Updated] (CASSANDRA-11763) Failure to read non-shallow pre-3.0 sstable index entries

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-11763:
---
Reviewer: T Jake Luciani

Waiting for test confirmation but that looks like it.

> Failure to read non-shallow pre-3.0 sstable index entries
> -
>
> Key: CASSANDRA-11763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11763
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Robert Stupp
>  Labels: dtest
> Fix For: 3.6
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure in:
> http://cassci.datastax.com/view/Parameterized/job/upgrade_tests-all-custom_branch_runs/12/testReport/upgrade_tests.upgrade_through_versions_test/ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD/rolling_upgrade_test_2/
> Logs are attached, relevant stack trace is here.
> {code}
> ERROR [main] 2016-05-11 16:26:06,555 CassandraDaemon.java:727 - Exception 
> encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:119)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.compactLegacyHints(LegacyHintsMigrator.java:108)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.migrate(LegacyHintsMigrator.java:92)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:321) 
> [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:581)
>  [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:710) 
> [main/:na]
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192) 
> ~[na:1.8.0_51]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:115)
>  ~[main/:na]
>   ... 5 common frames omitted
> Caused by: java.lang.NegativeArraySizeException: null
>   at 
> org.apache.cassandra.db.RowIndexEntry$LegacyShallowIndexedEntry.deserialize(RowIndexEntry.java:519)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.RowIndexEntry$Serializer.deserialize(RowIndexEntry.java:321)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:310)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:265)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner.hasNext(BigTableScanner.java:245)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:374)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:186)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:155)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:150)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:72)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:226)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:82)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:805)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> 

[jira] [Updated] (CASSANDRA-11763) Failure to read non-shallow pre-3.0 sstable index entries

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-11763:
---
Fix Version/s: (was: 3.x)
   3.6

> Failure to read non-shallow pre-3.0 sstable index entries
> -
>
> Key: CASSANDRA-11763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11763
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Robert Stupp
>  Labels: dtest
> Fix For: 3.6
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure in:
> http://cassci.datastax.com/view/Parameterized/job/upgrade_tests-all-custom_branch_runs/12/testReport/upgrade_tests.upgrade_through_versions_test/ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD/rolling_upgrade_test_2/
> Logs are attached, relevant stack trace is here.
> {code}
> ERROR [main] 2016-05-11 16:26:06,555 CassandraDaemon.java:727 - Exception 
> encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:119)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.compactLegacyHints(LegacyHintsMigrator.java:108)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.migrate(LegacyHintsMigrator.java:92)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:321) 
> [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:581)
>  [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:710) 
> [main/:na]
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192) 
> ~[na:1.8.0_51]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:115)
>  ~[main/:na]
>   ... 5 common frames omitted
> Caused by: java.lang.NegativeArraySizeException: null
>   at 
> org.apache.cassandra.db.RowIndexEntry$LegacyShallowIndexedEntry.deserialize(RowIndexEntry.java:519)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.RowIndexEntry$Serializer.deserialize(RowIndexEntry.java:321)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:310)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:265)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner.hasNext(BigTableScanner.java:245)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:374)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:186)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:155)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:150)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:72)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:226)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:82)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:805)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_51]
>   at 
> 

[jira] [Updated] (CASSANDRA-11763) Failure to read non-shallow pre-3.0 sstable index entries

[Robert Stupp (JIRA)]

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

Robert Stupp updated CASSANDRA-11763:
-
Reproduced In: 3.6

> Failure to read non-shallow pre-3.0 sstable index entries
> -
>
> Key: CASSANDRA-11763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11763
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Robert Stupp
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure in:
> http://cassci.datastax.com/view/Parameterized/job/upgrade_tests-all-custom_branch_runs/12/testReport/upgrade_tests.upgrade_through_versions_test/ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD/rolling_upgrade_test_2/
> Logs are attached, relevant stack trace is here.
> {code}
> ERROR [main] 2016-05-11 16:26:06,555 CassandraDaemon.java:727 - Exception 
> encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:119)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.compactLegacyHints(LegacyHintsMigrator.java:108)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.migrate(LegacyHintsMigrator.java:92)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:321) 
> [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:581)
>  [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:710) 
> [main/:na]
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192) 
> ~[na:1.8.0_51]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:115)
>  ~[main/:na]
>   ... 5 common frames omitted
> Caused by: java.lang.NegativeArraySizeException: null
>   at 
> org.apache.cassandra.db.RowIndexEntry$LegacyShallowIndexedEntry.deserialize(RowIndexEntry.java:519)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.RowIndexEntry$Serializer.deserialize(RowIndexEntry.java:321)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:310)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:265)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner.hasNext(BigTableScanner.java:245)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:374)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:186)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:155)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:150)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:72)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:226)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:82)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:805)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_51]
>   at 
> 

[jira] [Updated] (CASSANDRA-11763) Failure to read non-shallow pre-3.0 sstable index entries

[Robert Stupp (JIRA)]

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

Robert Stupp updated CASSANDRA-11763:
-
Summary: Failure to read non-shallow pre-3.0 sstable index entries  (was: 
dtest failure in 
upgrade_tests.upgrade_through_versions_test.ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD.rolling_upgrade_test)

> Failure to read non-shallow pre-3.0 sstable index entries
> -
>
> Key: CASSANDRA-11763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11763
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Robert Stupp
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure in:
> http://cassci.datastax.com/view/Parameterized/job/upgrade_tests-all-custom_branch_runs/12/testReport/upgrade_tests.upgrade_through_versions_test/ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD/rolling_upgrade_test_2/
> Logs are attached, relevant stack trace is here.
> {code}
> ERROR [main] 2016-05-11 16:26:06,555 CassandraDaemon.java:727 - Exception 
> encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:119)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.compactLegacyHints(LegacyHintsMigrator.java:108)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.migrate(LegacyHintsMigrator.java:92)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:321) 
> [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:581)
>  [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:710) 
> [main/:na]
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192) 
> ~[na:1.8.0_51]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:115)
>  ~[main/:na]
>   ... 5 common frames omitted
> Caused by: java.lang.NegativeArraySizeException: null
>   at 
> org.apache.cassandra.db.RowIndexEntry$LegacyShallowIndexedEntry.deserialize(RowIndexEntry.java:519)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.RowIndexEntry$Serializer.deserialize(RowIndexEntry.java:321)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:310)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:265)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner.hasNext(BigTableScanner.java:245)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:374)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:186)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:155)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:150)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:72)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:226)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:82)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:805)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> 

[jira] [Updated] (CASSANDRA-11763) dtest failure in upgrade_tests.upgrade_through_versions_test.ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD.rolling_upgrade_test

[Robert Stupp (JIRA)]

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

Robert Stupp updated CASSANDRA-11763:
-
Status: Patch Available  (was: Open)

||cassandra-3.6|[branch|https://github.com/apache/cassandra/compare/cassandra-3.6...snazy:11763-dtest-upgrade-failure-3.6]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11763-dtest-upgrade-failure-3.6-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11763-dtest-upgrade-failure-3.6-dtest/lastSuccessfulBuild/]
||cassandra-3.7|[branch|https://github.com/apache/cassandra/compare/cassandra-3.7...snazy:11763-dtest-upgrade-failure-3.7]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11763-dtest-upgrade-failure-3.7-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11763-dtest-upgrade-failure-3.7-dtest/lastSuccessfulBuild/]
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:11763-dtest-upgrade-failure-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11763-dtest-upgrade-failure-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11763-dtest-upgrade-failure-trunk-dtest/lastSuccessfulBuild/]

Note: all branches (3.6, 3.7, trunk) contain the same commit (just not merged)

> dtest failure in 
> upgrade_tests.upgrade_through_versions_test.ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD.rolling_upgrade_test
> 
>
> Key: CASSANDRA-11763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11763
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Robert Stupp
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure in:
> http://cassci.datastax.com/view/Parameterized/job/upgrade_tests-all-custom_branch_runs/12/testReport/upgrade_tests.upgrade_through_versions_test/ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD/rolling_upgrade_test_2/
> Logs are attached, relevant stack trace is here.
> {code}
> ERROR [main] 2016-05-11 16:26:06,555 CassandraDaemon.java:727 - Exception 
> encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:119)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.compactLegacyHints(LegacyHintsMigrator.java:108)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.migrate(LegacyHintsMigrator.java:92)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:321) 
> [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:581)
>  [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:710) 
> [main/:na]
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192) 
> ~[na:1.8.0_51]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:115)
>  ~[main/:na]
>   ... 5 common frames omitted
> Caused by: java.lang.NegativeArraySizeException: null
>   at 
> org.apache.cassandra.db.RowIndexEntry$LegacyShallowIndexedEntry.deserialize(RowIndexEntry.java:519)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.RowIndexEntry$Serializer.deserialize(RowIndexEntry.java:321)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:310)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:265)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner.hasNext(BigTableScanner.java:245)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:374)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:186)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:155)
>  

[jira] [Commented] (CASSANDRA-11763) dtest failure in upgrade_tests.upgrade_through_versions_test.ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD.rolling_upgrade_test

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-11763:
--

Still no luck to repro the dtest.
But I figured out how to repro with the modified utest {{LegacySSTableTest}}. 
Without the patch the utest fails during compaction (as indicated by the dtest 
logs) - with the patch it works fine.

Background: 3.6 has a bug (introduced by late refactorings) reading legacy 
non-shallow IndexedEntry objects (the non-shallow ones) since it accidentally 
uses the _new_ format (with vints).

Eligible to merge to 3.6 or 3.7, too?

> dtest failure in 
> upgrade_tests.upgrade_through_versions_test.ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD.rolling_upgrade_test
> 
>
> Key: CASSANDRA-11763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11763
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Robert Stupp
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure in:
> http://cassci.datastax.com/view/Parameterized/job/upgrade_tests-all-custom_branch_runs/12/testReport/upgrade_tests.upgrade_through_versions_test/ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD/rolling_upgrade_test_2/
> Logs are attached, relevant stack trace is here.
> {code}
> ERROR [main] 2016-05-11 16:26:06,555 CassandraDaemon.java:727 - Exception 
> encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:119)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.compactLegacyHints(LegacyHintsMigrator.java:108)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.migrate(LegacyHintsMigrator.java:92)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:321) 
> [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:581)
>  [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:710) 
> [main/:na]
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192) 
> ~[na:1.8.0_51]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:115)
>  ~[main/:na]
>   ... 5 common frames omitted
> Caused by: java.lang.NegativeArraySizeException: null
>   at 
> org.apache.cassandra.db.RowIndexEntry$LegacyShallowIndexedEntry.deserialize(RowIndexEntry.java:519)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.RowIndexEntry$Serializer.deserialize(RowIndexEntry.java:321)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:310)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:265)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner.hasNext(BigTableScanner.java:245)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:374)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:186)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:155)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:150)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:72)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:226)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> 

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

[Branimir Lambov (JIRA)]

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

Branimir Lambov commented on CASSANDRA-11828:
-

With this change the delayed permission to compact that was introduced in 
CASSANDRA-9669 is no longer necessary. The branches below add a commit that 
removes the relevant code:
|[2.2|https://github.com/blambov/cassandra/tree/11828-revert-compaction-wait-2.2]|[utest|http://cassci.datastax.com/job/blambov-11828-revert-compaction-wait-2.2-testall/]|[dtest|http://cassci.datastax.com/job/blambov-11828-revert-compaction-wait-2.2-dtest/]|
|[3.0|https://github.com/blambov/cassandra/tree/11828-revert-compaction-wait-3.0]|[utest|http://cassci.datastax.com/job/blambov-11828-revert-compaction-wait-3.0-testall/]|[dtest|http://cassci.datastax.com/job/blambov-11828-revert-compaction-wait-3.0-dtest/]|
|[trunk|https://github.com/blambov/cassandra/tree/11828-revert-compaction-wait]|[utest|http://cassci.datastax.com/job/blambov-11828-revert-compaction-wait-testall/]|[dtest|http://cassci.datastax.com/job/blambov-11828-revert-compaction-wait-dtest/]|
(doesn't include latest 9669 fix so index failures are expected)

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



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

[jira] [Commented] (CASSANDRA-9669) If sstable flushes complete out of order, on restart we can fail to replay necessary commit log records

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-9669:


LGTM & haven't had a {{CassandraIndexTest}} failure in > 30 runs. 

Although it isn't strictly needed after the previous commit, I've added my 
{{SIM}} change as the sync when flushing non-CFS indexes is totally 
unnecessary. I also added a test in that commit, which would've caught the 
deadlock in the first place. If we're all good with that, I'll commit once CI 
finishes.

||branch||testall||dtest||
|[9669-follow-up-2.2|https://github.com/beobal/cassandra/tree/9669-follow-up-2.2]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9669-follow-up-2.2-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9669-follow-up-2.2-dtest]|
|[9669-follow-up-3.0|https://github.com/beobal/cassandra/tree/9669-follow-up-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9669-follow-up-3.0-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9669-follow-up-3.0-dtest]|
|[9669-follow-up-trunk|https://github.com/beobal/cassandra/tree/9669-follow-up-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9669-follow-up-trunk-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9669-follow-up-trunk-dtest]|


> If sstable flushes complete out of order, on restart we can fail to replay 
> necessary commit log records
> ---
>
> Key: CASSANDRA-9669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9669
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Benedict
>Assignee: Branimir Lambov
>Priority: Critical
>  Labels: correctness
> Fix For: 2.2.7, 3.7, 3.0.7
>
>
> While {{postFlushExecutor}} ensures it never expires CL entries out-of-order, 
> on restart we simply take the maximum replay position of any sstable on disk, 
> and ignore anything prior. 
> It is quite possible for there to be two flushes triggered for a given table, 
> and for the second to finish first by virtue of containing a much smaller 
> quantity of live data (or perhaps the disk is just under less pressure). If 
> we crash before the first sstable has been written, then on restart the data 
> it would have represented will disappear, since we will not replay the CL 
> records.
> This looks to be a bug present since time immemorial, and also seems pretty 
> serious.



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

[jira] [Commented] (CASSANDRA-11905) Index building fails to start CFS.readOrdering when reading

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-11905:
--

+1 on the [3.0 patch|https://github.com/pcmanus/cassandra/commits/11905-3.0]; 
the [3.7 patch|https://github.com/pcmanus/cassandra/commits/11905-3.7] also 
looks OK from a quick look, but I will take another look first thing on Monday, 
as well as checking any CI failures. I agree on pushing it to 3.6 if we can, 
thank you for producing a patch so quickly!

> Index building fails to start CFS.readOrdering when reading
> ---
>
> Key: CASSANDRA-11905
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11905
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Critical
> Fix For: 3.0.x, 3.x
>
>
> This code for indexing partition when building index in 3.0 is:
> {noformat}
> SinglePartitionReadCommand cmd = 
> SinglePartitionReadCommand.fullPartitionRead(cfs.metadata, 
> FBUtilities.nowInSeconds(), key);
> try (OpOrder.Group opGroup = cfs.keyspace.writeOrder.start();
>   UnfilteredRowIterator partition = cmd.queryMemtableAndDisk(cfs, 
> opGroup))
> {
> cfs.indexManager.indexPartition(partition, opGroup, indexes, 
> cmd.nowInSec());
> }
> {noformat}
> which is clearly incorrect as the {{OpOrder}} that {{queryMemtableAndDisk}} 
> expects is the one from {{cfs.readOrdering}}, not the one for writes on the 
> keyspace.
> This wasn't a problem prior to 3.0 as the similar code was using the pager, 
> which ended up properly taking the read {{OpOrder}} internally but I messed 
> this up in CASSANDRA-8099.
> Thanks to [~Stefania] for pointing that out.



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

[jira] [Commented] (CASSANDRA-8497) Do not replay commit log records for tables that have been repaired since

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-8497:


agreed, even for repaired data we still keep the tombstones around for at least 
gcgs

> Do not replay commit log records for tables that have been repaired since
> -
>
> Key: CASSANDRA-8497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8497
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benedict
>Priority: Minor
>
> If somehow we have commit log records around since prior to a repair was 
> completed, and we have repair-aware tombstone collection, then we could 
> potentially reintroduce deleted data. Since we consider repaired data to be 
> completely up-to-date, unless there has been a cross-cluster failure where 
> data only ended up in the commit log, the commit log records will by now be 
> superfluous. Some grace period may be necessary, as with CASSANDRA-6434.



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

[jira] [Commented] (CASSANDRA-11882) Clustering Key with ByteBuffer size > 64k throws Assertion Error

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-11882:
--

Sorry for being slightly annoying, but catching {{Throwable}} in 
{{writeConnected}} is imo right, but it means we can catch stuffs like 
{{OutOfMemoryException}} for which we kind of want to let the JVM die. So 
basically, we should call {{JVMStabilityInspector.inspectThrowable()}} at the 
beginning of the {{catch}} clause. We probably always should have done that in 
fact really, so 3.0 should probably get that part (and yes, the storage engine 
revamp is why you can know have larger than 64k values in clustering). 

> Clustering Key with ByteBuffer size > 64k throws Assertion Error
> 
>
> Key: CASSANDRA-11882
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11882
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Streaming and Messaging
>Reporter: Lerh Chuan Low
> Fix For: 2.1.x
>
> Attachments: 11882-2.1.txt
>
>
> Setup:
> {code}
> CREATE KEYSPACE Blues WITH REPLICATION = { 'class' : 'SimpleStrategy', 
> 'replication_factor' : 2};
> CREATE TABLE test (a text, b text, PRIMARY KEY ((a), b))
> {code}
> There currently doesn't seem to be an existing check for selecting clustering 
> keys that are larger than 64k. So if we proceed to do the following select:
> {code}
> CONSISTENCY ALL;
> SELECT * FROM Blues.test WHERE a = 'foo' AND b = 'something larger than 64k';
> {code}
> An AssertionError is thrown in `ByteBufferUtil` with just a number and an 
> error message detailing 'Coordinator node timed out waiting for replica nodes 
> responses' . Additionally, because an error extends Throwable (it's not a 
> subclass of Exception), it's not caught so the connection between the 
> coordinator node and the other nodes which have the replicas seem to be 
> 'stuck' until it's restarted. Any other subsequent queries, even if it's just 
> SELECT where a = 'foo' and b = 'bar', will always return the Coordinator 
> timing out waiting for replica nodes responses'.



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

[jira] [Commented] (CASSANDRA-10992) Hanging streaming sessions

[mlowicki (JIRA)]

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

mlowicki commented on CASSANDRA-10992:
--

[~pauloricardomg] yes:
{code}
WARN  [Thread-154755] 2016-05-26 17:36:20,625 CompressedInputStream.java:190 - 
Error while reading compressed input stream.
WARN  [STREAM-IN-/10.210.59.151] 2016-05-26 17:36:20,625 
CompressedStreamReader.java:115 - [Stream 14d2bb50-2366-11e6-aff3-094ba808857e] 
Error while reading partition DecoratedKey(-8649238600224809230, 
000933303034383932393204934600) from stream on ks='sync' and 
table='entity_by_id2'.
WARN  [Thread-156292] 2016-05-26 19:52:29,073 CompressedInputStream.java:190 - 
Error while reading compressed input stream.
WARN  [STREAM-IN-/10.210.59.84] 2016-05-26 19:52:29,073 
CompressedStreamReader.java:115 - [Stream 040b4041-2379-11e6-a363-41a0407f7ce6] 
Error while reading partition DecoratedKey(-3970687134714418221, 
000933303533393631373204000276d800) from stream on ks='sync' and 
table='entity_by_id2'.
WARN  [Thread-157643] 2016-05-26 23:17:09,393 CompressedInputStream.java:190 - 
Error while reading compressed input stream.
WARN  [STREAM-IN-/10.210.59.86] 2016-05-26 23:17:09,393 
CompressedStreamReader.java:115 - [Stream 97753900-2395-11e6-b5a2-b9dde4344a60] 
Error while reading partition DecoratedKey(2694075662350043685, 
00093238313135323204808800) from stream on ks='sync' and 
table='entity_by_id2'.
{code}

> Hanging streaming sessions
> --
>
> Key: CASSANDRA-10992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10992
> Project: Cassandra
>  Issue Type: Bug
> Environment: C* 2.1.12, Debian Wheezy
>Reporter: mlowicki
>Assignee: Paulo Motta
> Fix For: 2.1.12
>
> Attachments: apache-cassandra-2.1.12-SNAPSHOT.jar, db1.ams.jstack, 
> db6.analytics.jstack
>
>
> I've started recently running repair using [Cassandra 
> Reaper|https://github.com/spotify/cassandra-reaper]  (built-in {{nodetool 
> repair}} doesn't work for me - CASSANDRA-9935). It behaves fine but I've 
> noticed hanging streaming sessions:
> {code}
> root@db1:~# date
> Sat Jan  9 16:43:00 UTC 2016
> root@db1:~# nt netstats -H | grep total
> Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB 
> total
> Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total
> Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB 
> total
> Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total
> Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB 
> total
> Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total
> Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 
> MB total
> Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total
> Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB 
> total
> Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB 
> total
> root@db1:~# date
> Sat Jan  9 17:45:42 UTC 2016
> root@db1:~# nt netstats -H | grep total
> Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB 
> total
> Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total
> Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB 
> total
> Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total
> Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB 
> total
> Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total
> Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 
> MB total
> Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total
> Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB 
> total
> Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB 
> total
> {code}
> Such sessions are left even when repair job is long time done (confirmed by 
> checking Reaper's and Cassandra's logs). {{streaming_socket_timeout_in_ms}} 
> in cassandra.yaml is set to default value (360).



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

[jira] [Commented] (CASSANDRA-11763) dtest failure in upgrade_tests.upgrade_through_versions_test.ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD.rolling_upgrade_test

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-11763:
--

Hm. I'm unable to run the dtest on my Mac nor on a beefy machine. Both fail 
during the first upgrade from 2.1.14 to 2.2.6 with timeouts.

But I found an issue in {{RowIndexEntry}}, which can definitely cause broken 
reads. There are two options to verify whether that's causing the bug:
# Set {{column_index_cache_size_in_kb}} to {{0}}
# Use [this 
branch|https://github.com/apache/cassandra/compare/trunk...snazy:11763-dtest-upgrade-failure-trunk?expand=1]
 instead of trunk in the dtest


> dtest failure in 
> upgrade_tests.upgrade_through_versions_test.ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD.rolling_upgrade_test
> 
>
> Key: CASSANDRA-11763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11763
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Robert Stupp
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure in:
> http://cassci.datastax.com/view/Parameterized/job/upgrade_tests-all-custom_branch_runs/12/testReport/upgrade_tests.upgrade_through_versions_test/ProtoV3Upgrade_AllVersions_RandomPartitioner_Skips_3_0_x_EndsAt_Trunk_HEAD/rolling_upgrade_test_2/
> Logs are attached, relevant stack trace is here.
> {code}
> ERROR [main] 2016-05-11 16:26:06,555 CassandraDaemon.java:727 - Exception 
> encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:119)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.compactLegacyHints(LegacyHintsMigrator.java:108)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.migrate(LegacyHintsMigrator.java:92)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:321) 
> [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:581)
>  [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:710) 
> [main/:na]
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NegativeArraySizeException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192) 
> ~[na:1.8.0_51]
>   at 
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:115)
>  ~[main/:na]
>   ... 5 common frames omitted
> Caused by: java.lang.NegativeArraySizeException: null
>   at 
> org.apache.cassandra.db.RowIndexEntry$LegacyShallowIndexedEntry.deserialize(RowIndexEntry.java:519)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.RowIndexEntry$Serializer.deserialize(RowIndexEntry.java:321)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:310)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:265)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner.hasNext(BigTableScanner.java:245)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:374)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:186)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:155)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:150)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:72)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:226)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>  

[jira] [Updated] (CASSANDRA-11905) Index building fails to start CFS.readOrdering when reading

[Sylvain Lebresne (JIRA)]

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

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

The fix is pretty simple, we just have to grab the read order and pass it to 
{{queryMemtableAndDisk}}, and that's exactly what I did for 3.0 to optimize for 
minimum amount of change. On 3.7 however, I took a slightly more aggressive 
approach that should hopefully protect against that kind of mistake: I removed 
the {{queryMemtableAndDisk}} method that was taking an {{OpOrder.Group}}, 
leaving only the one taking a {{ReadExecutionController}}, which should in 
itself prevent mistakenly passing a write order. But I also make a few (minor 
overall) additions to {{ReadExecutionController}} so we even validate that the 
controller we use has been properly taken on the right table (to typically 
prevent misusing a base table {{OpOrder.Group}} to read on an index table).

|| 3.0  || 3.7 ||
| [utests|http://cassci.datastax.com/job/pcmanus-11905-3.0-testall/] | 
[utests|http://cassci.datastax.com/job/pcmanus-11905-3.7-testall/] |
| [dtests|http://cassci.datastax.com/job/pcmanus-11905-3.0-dtest/] | 
[dtests|http://cassci.datastax.com/job/pcmanus-11905-3.7-dtest/] |

Note that tests haven't yet run as of this writing, and I didn't started trunk 
cause it's basically the same as 3.7 right now.

I'll note that since that's a fairly serious bug (probably don't reproduce 
often, but could make us remove a sstable that is still being read, potentially 
hard-crashing a node if things are mmapped) and since 3.6 hasn't been voted on 
yet, we might want to consider including that fix.


> Index building fails to start CFS.readOrdering when reading
> ---
>
> Key: CASSANDRA-11905
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11905
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Critical
> Fix For: 3.0.x, 3.x
>
>
> This code for indexing partition when building index in 3.0 is:
> {noformat}
> SinglePartitionReadCommand cmd = 
> SinglePartitionReadCommand.fullPartitionRead(cfs.metadata, 
> FBUtilities.nowInSeconds(), key);
> try (OpOrder.Group opGroup = cfs.keyspace.writeOrder.start();
>   UnfilteredRowIterator partition = cmd.queryMemtableAndDisk(cfs, 
> opGroup))
> {
> cfs.indexManager.indexPartition(partition, opGroup, indexes, 
> cmd.nowInSec());
> }
> {noformat}
> which is clearly incorrect as the {{OpOrder}} that {{queryMemtableAndDisk}} 
> expects is the one from {{cfs.readOrdering}}, not the one for writes on the 
> keyspace.
> This wasn't a problem prior to 3.0 as the similar code was using the pager, 
> which ended up properly taking the read {{OpOrder}} internally but I messed 
> this up in CASSANDRA-8099.
> Thanks to [~Stefania] for pointing that out.



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

[jira] [Updated] (CASSANDRA-11743) Race condition in CommitLog.recover can prevent startup

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-11743:
---
Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

Committed into 2.2 at 6add3c9acc063005198510e9627ae9e783e54e91 and merged into 
3.0, 3.7 and trunk

> Race condition in CommitLog.recover can prevent startup
> ---
>
> Key: CASSANDRA-11743
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11743
> Project: Cassandra
>  Issue Type: Bug
>  Components: Lifecycle
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: 11743-2.2.txt
>
>
> In {{CommitLog::recover}} the list of segments to recover from is determined 
> by removing the files managed by the {{CommitLogSegmentManager}} from the 
> list of files present in the commit log directory. Unfortunatly, due to the 
> way the creation of segments is done there is a time window where a segment 
> file has been created but has not been added yet to the list of segments 
> managed by the {{CommitLogSegmentManager}}. If the filtering ocurs during 
> that time window the Commit log might try to recover from that new segment 
> and crash.   



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

[jira] [Commented] (CASSANDRA-11743) Race condition in CommitLog.recover can prevent startup

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-11743:


Thanks.

> Race condition in CommitLog.recover can prevent startup
> ---
>
> Key: CASSANDRA-11743
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11743
> Project: Cassandra
>  Issue Type: Bug
>  Components: Lifecycle
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: 11743-2.2.txt
>
>
> In {{CommitLog::recover}} the list of segments to recover from is determined 
> by removing the files managed by the {{CommitLogSegmentManager}} from the 
> list of files present in the commit log directory. Unfortunatly, due to the 
> way the creation of segments is done there is a time window where a segment 
> file has been created but has not been added yet to the list of segments 
> managed by the {{CommitLogSegmentManager}}. If the filtering ocurs during 
> that time window the Commit log might try to recover from that new segment 
> and crash.   



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

[jira] [Updated] (CASSANDRA-11743) Race condition in CommitLog.recover can prevent startup

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-11743:
---
Attachment: 11743-2.2.txt

> Race condition in CommitLog.recover can prevent startup
> ---
>
> Key: CASSANDRA-11743
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11743
> Project: Cassandra
>  Issue Type: Bug
>  Components: Lifecycle
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: 11743-2.2.txt
>
>
> In {{CommitLog::recover}} the list of segments to recover from is determined 
> by removing the files managed by the {{CommitLogSegmentManager}} from the 
> list of files present in the commit log directory. Unfortunatly, due to the 
> way the creation of segments is done there is a time window where a segment 
> file has been created but has not been added yet to the list of segments 
> managed by the {{CommitLogSegmentManager}}. If the filtering ocurs during 
> that time window the Commit log might try to recover from that new segment 
> and crash.   



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

[1/4] cassandra git commit: Fix possible race condition in CommitLog.recover

[blerer]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 49278480d -> d9b192e33


Fix possible race condition in CommitLog.recover

patch by Benjamin Lerer; reviewed by Branimir Lambov for CASSANDRA-11743


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

Branch: refs/heads/trunk
Commit: 6add3c9acc063005198510e9627ae9e783e54e91
Parents: 4aa859e
Author: Benjamin Lerer 
Authored: Fri May 27 10:55:23 2016 +0200
Committer: Benjamin Lerer 
Committed: Fri May 27 10:55:23 2016 +0200

--
 CHANGES.txt |  1 +
 .../apache/cassandra/db/commitlog/CommitLog.java|  8 ++--
 .../cassandra/db/commitlog/CommitLogSegment.java| 16 +++-
 3 files changed, 18 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6add3c9a/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f2276f0..7215836 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.7
+ * Fix possible race condition in CommitLog.recover (CASSANDRA-11743)
  * Enable client encryption in sstableloader with cli options (CASSANDRA-11708)
  * Possible memory leak in NIODataInputStream (CASSANDRA-11867)
  * Fix commit log replay after out-of-order flush completion (CASSANDRA-9669)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6add3c9a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
index 7592f48..9a6ba34 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
@@ -130,11 +130,6 @@ public class CommitLog implements CommitLogMBean
 if (allocator.createReserveSegments)
 return 0;
 
-// Allocator could be in the process of initial startup with 0 active 
and available segments. We need to wait for
-// the allocation manager to finish allocation and add it to available 
segments so we don't get an invalid response
-// on allocator.manages(...) below by grabbing a file off the 
filesystem before it's added to the CLQ.
-allocator.allocatingFrom();
-
 FilenameFilter unmanagedFilesFilter = new FilenameFilter()
 {
 public boolean accept(File dir, String name)
@@ -142,7 +137,7 @@ public class CommitLog implements CommitLogMBean
 // we used to try to avoid instantiating commitlog (thus 
creating an empty segment ready for writes)
 // until after recover was finished.  this turns out to be 
fragile; it is less error-prone to go
 // ahead and allow writes before recover(), and just skip 
active segments when we do.
-return CommitLogDescriptor.isValid(name) && 
!allocator.manages(name);
+return CommitLogDescriptor.isValid(name) && 
CommitLogSegment.shouldReplay(name);
 }
 };
 
@@ -435,6 +430,7 @@ public class CommitLog implements CommitLogMBean
 throw new RuntimeException(e);
 }
 allocator.stopUnsafe(deleteSegments);
+CommitLogSegment.resetReplayLimit();
 }
 
 /**

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6add3c9a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
index d748006..b6801d2 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
@@ -64,6 +64,7 @@ public abstract class CommitLogSegment
 
 private final static long idBase;
 private final static AtomicInteger nextId = new AtomicInteger(1);
+private static long replayLimitId;
 static
 {
 long maxId = Long.MIN_VALUE;
@@ -72,7 +73,7 @@ public abstract class CommitLogSegment
 if (CommitLogDescriptor.isValid(file.getName()))
 maxId = 
Math.max(CommitLogDescriptor.fromFileName(file.getName()).id, maxId);
 }
-idBase = Math.max(System.currentTimeMillis(), maxId + 1);
+replayLimitId = idBase = Math.max(System.currentTimeMillis(), maxId + 
1);
 }
 
 // The commit log entry overhead in bytes (int: length + int: head 
checksum + int: 

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

[blerer]

Merge branch cassandra-3.7 into trunk


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

Branch: refs/heads/trunk
Commit: d9b192e33a746fd30b635548719a2ecfdae6d4a1
Parents: 4927848 867a490
Author: Benjamin Lerer 
Authored: Fri May 27 11:10:52 2016 +0200
Committer: Benjamin Lerer 
Committed: Fri May 27 11:11:02 2016 +0200

--
 CHANGES.txt |  1 +
 .../apache/cassandra/db/commitlog/CommitLog.java|  8 ++--
 .../cassandra/db/commitlog/CommitLogSegment.java| 16 +++-
 3 files changed, 18 insertions(+), 7 deletions(-)
--


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

[3/4] cassandra git commit: Merge branch cassandra-3.0 into cassandra-3.7

[blerer]

Merge branch cassandra-3.0 into cassandra-3.7


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

Branch: refs/heads/trunk
Commit: 867a4900994d31accf06daae165c335aaad64fa0
Parents: f24e066 6f02446
Author: Benjamin Lerer 
Authored: Fri May 27 11:09:19 2016 +0200
Committer: Benjamin Lerer 
Committed: Fri May 27 11:09:35 2016 +0200

--
 CHANGES.txt |  1 +
 .../apache/cassandra/db/commitlog/CommitLog.java|  8 ++--
 .../cassandra/db/commitlog/CommitLogSegment.java| 16 +++-
 3 files changed, 18 insertions(+), 7 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/867a4900/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/867a4900/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
--