[jira] [Commented] (CASSANDRA-9666) Provide an alternative to DTCS

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-9666:


I guess I'm finally +1 on getting this committed.

Even though I think DTCS works just as well these days I totally understand 
that people who tried early versions of DTCS say "I'm never touching that 
again". And it would be nice to not have to explain how the windowing works in 
DTCS ever again :)

So, lets deprecate DTCS and commit this.

What we need to do first (imo):
* Rebase patches? Are they up to date [~jjirsa]?
* Review the code
* Add a NEWS.txt entry why we add TWCS and deprecate DTCS
* Document how existing DTCS-users move to TWCS

It would also be nice to have a few existing TWCS-users write about their 
experiences, how much data they have etc, [~jjirsa] I'm sure you know a few, 
could you poke them?

> Provide an alternative to DTCS
> --
>
> Key: CASSANDRA-9666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9666
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 2.1.x, 2.2.x
>
> Attachments: dtcs-twcs-io.png, dtcs-twcs-load.png
>
>
> DTCS is great for time series data, but it comes with caveats that make it 
> difficult to use in production (typical operator behaviors such as bootstrap, 
> removenode, and repair have MAJOR caveats as they relate to 
> max_sstable_age_days, and hints/read repair break the selection algorithm).
> I'm proposing an alternative, TimeWindowCompactionStrategy, that sacrifices 
> the tiered nature of DTCS in order to address some of DTCS' operational 
> shortcomings. I believe it is necessary to propose an alternative rather than 
> simply adjusting DTCS, because it fundamentally removes the tiered nature in 
> order to remove the parameter max_sstable_age_days - the result is very very 
> different, even if it is heavily inspired by DTCS. 
> Specifically, rather than creating a number of windows of ever increasing 
> sizes, this strategy allows an operator to choose the window size, compact 
> with STCS within the first window of that size, and aggressive compact down 
> to a single sstable once that window is no longer current. The window size is 
> a combination of unit (minutes, hours, days) and size (1, etc), such that an 
> operator can expect all data using a block of that size to be compacted 
> together (that is, if your unit is hours, and size is 6, you will create 
> roughly 4 sstables per day, each one containing roughly 6 hours of data). 
> The result addresses a number of the problems with 
> DateTieredCompactionStrategy:
> - At the present time, DTCS’s first window is compacted using an unusual 
> selection criteria, which prefers files with earlier timestamps, but ignores 
> sizes. In TimeWindowCompactionStrategy, the first window data will be 
> compacted with the well tested, fast, reliable STCS. All STCS options can be 
> passed to TimeWindowCompactionStrategy to configure the first window’s 
> compaction behavior.
> - HintedHandoff may put old data in new sstables, but it will have little 
> impact other than slightly reduced efficiency (sstables will cover a wider 
> range, but the old timestamps will not impact sstable selection criteria 
> during compaction)
> - ReadRepair may put old data in new sstables, but it will have little impact 
> other than slightly reduced efficiency (sstables will cover a wider range, 
> but the old timestamps will not impact sstable selection criteria during 
> compaction)
> - Small, old sstables resulting from streams of any kind will be swiftly and 
> aggressively compacted with the other sstables matching their similar 
> maxTimestamp, without causing sstables in neighboring windows to grow in size.
> - The configuration options are explicit and straightforward - the tuning 
> parameters leave little room for error. The window is set in common, easily 
> understandable terms such as “12 hours”, “1 Day”, “30 days”. The 
> minute/hour/day options are granular enough for users keeping data for hours, 
> and users keeping data for years. 
> - There is no explicitly configurable max sstable age, though sstables will 
> naturally stop compacting once new data is written in that window. 
> - Streaming operations can create sstables with old timestamps, and they'll 
> naturally be joined together with sstables in the same time bucket. This is 
> true for bootstrap/repair/sstableloader/removenode. 
> - It remains true that if old data and new data is written into the memtable 
> at the same time, the resulting sstables will be treated as if they were new 
> sstables, however, that no longer negatively impacts the compaction 
> strategy’s selection criteria for older windows. 
> Patch 

[jira] [Updated] (CASSANDRA-11420) Add the JMX metrics to track number of data flushed from memtable to disk

[Dikang Gu (JIRA)]

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

Dikang Gu updated CASSANDRA-11420:
--
 Reviewer: Aleksey Yeschenko
Fix Version/s: 3.x
   Status: Patch Available  (was: Open)

[~iamaleksey], feel free to reassign, thanks!

> Add the JMX metrics to track number of data flushed from memtable to disk
> -
>
> Key: CASSANDRA-11420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11420
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 
> 0001-Add-the-metrics-of-how-many-bytes-we-flushed-from-me.patch
>
>
> 2016-03-24_02:30:38.39936 INFO  02:30:38 Completed flushing 
> /data/cassandra/data/keyspace/column-family/column-family-tmp-ka-295782-Data.db
>  (73.266MiB) for commitlog position ReplayPosition(segmentId=1458717183630, 
> position=3690)
> It would be useful to expose the number of flushed bytes to JMX, so that we 
> can monitor how many bytes are written by application and flushed to disk.



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

[jira] [Updated] (CASSANDRA-11420) Add the JMX metrics to track number of data flushed from memtable to disk

[Dikang Gu (JIRA)]

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

Dikang Gu updated CASSANDRA-11420:
--
Attachment: 0001-Add-the-metrics-of-how-many-bytes-we-flushed-from-me.patch

> Add the JMX metrics to track number of data flushed from memtable to disk
> -
>
> Key: CASSANDRA-11420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11420
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Minor
> Attachments: 
> 0001-Add-the-metrics-of-how-many-bytes-we-flushed-from-me.patch
>
>
> 2016-03-24_02:30:38.39936 INFO  02:30:38 Completed flushing 
> /data/cassandra/data/keyspace/column-family/column-family-tmp-ka-295782-Data.db
>  (73.266MiB) for commitlog position ReplayPosition(segmentId=1458717183630, 
> position=3690)
> It would be useful to expose the number of flushed bytes to JMX, so that we 
> can monitor how many bytes are written by application and flushed to disk.



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

[jira] [Assigned] (CASSANDRA-11420) Add the JMX metrics to track number of data flushed from memtable to disk

[Dikang Gu (JIRA)]

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

Dikang Gu reassigned CASSANDRA-11420:
-

Assignee: Dikang Gu

> Add the JMX metrics to track number of data flushed from memtable to disk
> -
>
> Key: CASSANDRA-11420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11420
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Minor
>
> 2016-03-24_02:30:38.39936 INFO  02:30:38 Completed flushing 
> /data/cassandra/data/keyspace/column-family/column-family-tmp-ka-295782-Data.db
>  (73.266MiB) for commitlog position ReplayPosition(segmentId=1458717183630, 
> position=3690)
> It would be useful to expose the number of flushed bytes to JMX, so that we 
> can monitor how many bytes are written by application and flushed to disk.



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

[jira] [Commented] (CASSANDRA-9935) Repair fails with RuntimeException

[Ruoran Wang (JIRA)]

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

Ruoran Wang commented on CASSANDRA-9935:


Using your nodetool getsstables --hex-format, I found all those hex keys show 
up in two sstables. ()
I checked those two sstables, found two entries in each sstable are exactly the 
same.

> Repair fails with RuntimeException
> --
>
> Key: CASSANDRA-9935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9935
> Project: Cassandra
>  Issue Type: Bug
> Environment: C* 2.1.8, Debian Wheezy
>Reporter: mlowicki
>Assignee: Yuki Morishita
> Fix For: 2.1.x
>
> Attachments: db1.sync.lati.osa.cassandra.log, 
> db5.sync.lati.osa.cassandra.log, system.log.10.210.3.117, 
> system.log.10.210.3.221, system.log.10.210.3.230
>
>
> We had problems with slow repair in 2.1.7 (CASSANDRA-9702) but after upgrade 
> to 2.1.8 it started to work faster but now it fails with:
> {code}
> ...
> [2015-07-29 20:44:03,956] Repair session 23a811b0-3632-11e5-a93e-4963524a8bde 
> for range (-5474076923322749342,-5468600594078911162] finished
> [2015-07-29 20:44:03,957] Repair session 336f8740-3632-11e5-a93e-4963524a8bde 
> for range (-8631877858109464676,-8624040066373718932] finished
> [2015-07-29 20:44:03,957] Repair session 4ccd8430-3632-11e5-a93e-4963524a8bde 
> for range (-5372806541854279315,-5369354119480076785] finished
> [2015-07-29 20:44:03,957] Repair session 59f129f0-3632-11e5-a93e-4963524a8bde 
> for range (8166489034383821955,8168408930184216281] finished
> [2015-07-29 20:44:03,957] Repair session 6ae7a9a0-3632-11e5-a93e-4963524a8bde 
> for range (6084602890817326921,6088328703025510057] finished
> [2015-07-29 20:44:03,957] Repair session 8938e4a0-3632-11e5-a93e-4963524a8bde 
> for range (-781874602493000830,-781745173070807746] finished
> [2015-07-29 20:44:03,957] Repair command #4 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:290)
> at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:202)
> {code}
> After running:
> {code}
> nodetool repair --partitioner-range --parallel --in-local-dc sync
> {code}
> Last records in logs regarding repair are:
> {code}
> INFO  [Thread-173887] 2015-07-29 20:44:03,956 StorageService.java:2952 - 
> Repair session 09ff9e40-3632-11e5-a93e-4963524a8bde for range 
> (-7695808664784761779,-7693529816291585568] finished
> INFO  [Thread-173887] 2015-07-29 20:44:03,956 StorageService.java:2952 - 
> Repair session 17d8d860-3632-11e5-a93e-4963524a8bde for range 
> (806371695398849,8065203836608925992] finished
> INFO  [Thread-173887] 2015-07-29 20:44:03,956 StorageService.java:2952 - 
> Repair session 23a811b0-3632-11e5-a93e-4963524a8bde for range 
> (-5474076923322749342,-5468600594078911162] finished
> INFO  [Thread-173887] 2015-07-29 20:44:03,956 StorageService.java:2952 - 
> Repair session 336f8740-3632-11e5-a93e-4963524a8bde for range 
> (-8631877858109464676,-8624040066373718932] finished
> INFO  [Thread-173887] 2015-07-29 20:44:03,957 StorageService.java:2952 - 
> Repair session 4ccd8430-3632-11e5-a93e-4963524a8bde for range 
> (-5372806541854279315,-5369354119480076785] finished
> INFO  [Thread-173887] 2015-07-29 20:44:03,957 StorageService.java:2952 - 
> Repair session 59f129f0-3632-11e5-a93e-4963524a8bde for range 
> (8166489034383821955,8168408930184216281] finished
> INFO  [Thread-173887] 2015-07-29 20:44:03,957 StorageService.java:2952 - 
> Repair session 6ae7a9a0-3632-11e5-a93e-4963524a8bde for range 
> (6084602890817326921,6088328703025510057] finished
> INFO  [Thread-173887] 2015-07-29 20:44:03,957 StorageService.java:2952 - 
> Repair session 8938e4a0-3632-11e5-a93e-4963524a8bde for range 
> (-781874602493000830,-781745173070807746] finished
> {code}
> but a bit above I see (at least two times in attached log):
> {code}
> ERROR [Thread-173887] 2015-07-29 20:44:03,853 StorageService.java:2959 - 
> Repair session 1b07ea50-3608-11e5-a93e-4963524a8bde for range 
> (5765414319217852786,5781018794516851576] failed with error 
> org.apache.cassandra.exceptions.RepairException: [repair 
> #1b07ea50-3608-11e5-a93e-4963524a8bde on sync/entity_by_id2, 
> (5765414319217852786,5781018794516851576]] Validation failed in /10.195.15.162
> java.util.concurrent.ExecutionException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.RepairException: [repair 
> #1b07ea50-3608-11e5-a93e-4963524a8bde on sync/entity_by_id2, 
> (5765414319217852786,5781018794516851576]] Validation failed in /10.195.15.162
> at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> [na:1.7.0_80]
> at 

[jira] [Commented] (CASSANDRA-9259) Bulk Reading from Cassandra

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-9259:
-

I would like to make sure we are all on the same page and gather any further 
suggestions or thoughts. It would also help very much to have an indication of 
what we are aiming for, in terms of performance. I am not familiar with either 
EDW or HDFS, so it would be helpful to roughly quantify what's considered good.

We can optimize the existing read path by special-casing local reads at CL=1 
and by optimizing any other areas highlighted by the analysis above. The 
underlying classes for reading sstables are the same as those used for 
compaction, so this is a similar approach to the "streaming compaction" 
approach mentioned above, provided we can replace CQL paging with streaming. To 
do this, we can add some options to the {{SELECT}} CQL command. I'm not sure if 
it's required at all, but we can improve or change the CQL rows output format 
if needed. The {{SELECT}} options would allow changing both transfer mechanism 
and output format, if required.

In addition to streaming, if local clients are important, we could also 
consider saving the output to a memory mapped file, or replacing sockets with 
Unix domain pipes, if tests indicate that these are significantly faster 
delivery mechanisms for local clients. 

Some alternatives:

* An off-line tool for scanning sstables. This is in principle simple and 
efficient but it has the disadvantage that it is a new tool, and we already 
have many tools. Because it requires access to sstables, it would not work very 
well for clients running on a different host.
* A JMX/nodetool command, as above, this is again something new and in order to 
implement some remote communication, it would require new plumbing, unless we 
just save data to a file, which again would not be very friendly for remote 
clients.
* A new CQL command, something like {{BULK EXPORT}}. This is very similar to 
the approach described above. It is more work for the drivers however, and the 
functionality is similar to {{SELECT}}, except for delivery and _maybe_ output 
format. I would probably consider this approach, if we are positive that we 
need a new output format.

[~brianmhess], [~rspitzer], [~slebresne] any thoughts?

> Bulk Reading from Cassandra
> ---
>
> Key: CASSANDRA-9259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9259
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Compaction, CQL, Local Write-Read Paths, Streaming and 
> Messaging, Testing
>Reporter:  Brian Hess
>Assignee: Stefania
>Priority: Critical
> Fix For: 3.x
>
> Attachments: bulk-read-benchmark.1.html, 
> bulk-read-jfr-profiles.1.tar.gz, bulk-read-jfr-profiles.2.tar.gz
>
>
> This ticket is following on from the 2015 NGCC.  This ticket is designed to 
> be a place for discussing and designing an approach to bulk reading.
> The goal is to have a bulk reading path for Cassandra.  That is, a path 
> optimized to grab a large portion of the data for a table (potentially all of 
> it).  This is a core element in the Spark integration with Cassandra, and the 
> speed at which Cassandra can deliver bulk data to Spark is limiting the 
> performance of Spark-plus-Cassandra operations.  This is especially of 
> importance as Cassandra will (likely) leverage Spark for internal operations 
> (for example CASSANDRA-8234).
> The core CQL to consider is the following:
> SELECT a, b, c FROM myKs.myTable WHERE Token(partitionKey) > X AND 
> Token(partitionKey) <= Y
> Here, we choose X and Y to be contained within one token range (perhaps 
> considering the primary range of a node without vnodes, for example).  This 
> query pushes 50K-100K rows/sec, which is not very fast if we are doing bulk 
> operations via Spark (or other processing frameworks - ETL, etc).  There are 
> a few causes (e.g., inefficient paging).
> There are a few approaches that could be considered.  First, we consider a 
> new "Streaming Compaction" approach.  The key observation here is that a bulk 
> read from Cassandra is a lot like a major compaction, though instead of 
> outputting a new SSTable we would output CQL rows to a stream/socket/etc.  
> This would be similar to a CompactionTask, but would strip out some 
> unnecessary things in there (e.g., some of the indexing, etc). Predicates and 
> projections could also be encapsulated in this new "StreamingCompactionTask", 
> for example.
> Another approach would be an alternate storage format.  For example, we might 
> employ Parquet (just as an example) to store the same data as in the primary 
> Cassandra storage (aka SSTables).  This is akin to Global Indexes (an 
> alternate storage of the same data 

[jira] [Created] (CASSANDRA-11420) Add the JMX metrics to track number of data flushed from memtable to disk

[Dikang Gu (JIRA)]

Dikang Gu created CASSANDRA-11420:
-

 Summary: Add the JMX metrics to track number of data flushed from 
memtable to disk
 Key: CASSANDRA-11420
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11420
 Project: Cassandra
  Issue Type: Improvement
Reporter: Dikang Gu
Priority: Minor


2016-03-24_02:30:38.39936 INFO  02:30:38 Completed flushing 
/data/cassandra/data/keyspace/column-family/column-family-tmp-ka-295782-Data.db 
(73.266MiB) for commitlog position ReplayPosition(segmentId=1458717183630, 
position=3690)

It would be useful to expose the number of flushed bytes to JMX, so that we can 
monitor how many bytes are written by application and flushed to disk.



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

[jira] [Updated] (CASSANDRA-11320) Improve backoff policy for cqlsh COPY FROM

[Stefania (JIRA)]

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

Stefania updated CASSANDRA-11320:
-
Fix Version/s: 3.0.x

> Improve backoff policy for cqlsh COPY FROM
> --
>
> Key: CASSANDRA-11320
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11320
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
>  Labels: doc-impacting
> Fix For: 3.0.x, 3.x
>
>
> Currently we have an exponential back-off policy in COPY FROM that kicks in 
> when timeouts are received. However there are two limitations:
> * it does not cover new requests and therefore we may not back-off 
> sufficiently to give time to an overloaded server to recover
> * the pause is performed in the receiving thread and therefore we may not 
> process server messages quickly enough
> There is a static throttling mechanism in rows per second from feeder to 
> worker processes (the INGESTRATE) but the feeder has no idea of the load of 
> each worker process. However it's easy to keep track of how many chunks a 
> worker process has yet to read by introducing a bounded semaphore.
> The idea is to move the back-off pauses to the worker processes main thread 
> so as to include all messages, new and retries, not just the retries that 
> timed out. The worker process will not read new chunks during the back-off 
> pauses, and the feeder process can then look at the number of pending chunks 
> before sending new chunks to a worker process.
> [~aholmber], [~aweisberg] what do you think?  



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

[jira] [Commented] (CASSANDRA-11320) Improve backoff policy for cqlsh COPY FROM

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-11320:
--

Testing was OK, this is ready for review.

[~pauloricardomg], [~thobbs], [~aholmber]: any takers?

> Improve backoff policy for cqlsh COPY FROM
> --
>
> Key: CASSANDRA-11320
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11320
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
>  Labels: doc-impacting
> Fix For: 3.x
>
>
> Currently we have an exponential back-off policy in COPY FROM that kicks in 
> when timeouts are received. However there are two limitations:
> * it does not cover new requests and therefore we may not back-off 
> sufficiently to give time to an overloaded server to recover
> * the pause is performed in the receiving thread and therefore we may not 
> process server messages quickly enough
> There is a static throttling mechanism in rows per second from feeder to 
> worker processes (the INGESTRATE) but the feeder has no idea of the load of 
> each worker process. However it's easy to keep track of how many chunks a 
> worker process has yet to read by introducing a bounded semaphore.
> The idea is to move the back-off pauses to the worker processes main thread 
> so as to include all messages, new and retries, not just the retries that 
> timed out. The worker process will not read new chunks during the back-off 
> pauses, and the feeder process can then look at the number of pending chunks 
> before sending new chunks to a worker process.
> [~aholmber], [~aweisberg] what do you think?  



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

[jira] [Updated] (CASSANDRA-11320) Improve backoff policy for cqlsh COPY FROM

[Stefania (JIRA)]

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

Stefania updated CASSANDRA-11320:
-
Tester:   (was: Ariel Weisberg)
Status: Patch Available  (was: Awaiting Feedback)

> Improve backoff policy for cqlsh COPY FROM
> --
>
> Key: CASSANDRA-11320
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11320
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
>  Labels: doc-impacting
> Fix For: 3.x
>
>
> Currently we have an exponential back-off policy in COPY FROM that kicks in 
> when timeouts are received. However there are two limitations:
> * it does not cover new requests and therefore we may not back-off 
> sufficiently to give time to an overloaded server to recover
> * the pause is performed in the receiving thread and therefore we may not 
> process server messages quickly enough
> There is a static throttling mechanism in rows per second from feeder to 
> worker processes (the INGESTRATE) but the feeder has no idea of the load of 
> each worker process. However it's easy to keep track of how many chunks a 
> worker process has yet to read by introducing a bounded semaphore.
> The idea is to move the back-off pauses to the worker processes main thread 
> so as to include all messages, new and retries, not just the retries that 
> timed out. The worker process will not read new chunks during the back-off 
> pauses, and the feeder process can then look at the number of pending chunks 
> before sending new chunks to a worker process.
> [~aholmber], [~aweisberg] what do you think?  



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

[jira] [Commented] (CASSANDRA-8928) Add downgradesstables

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-8928:


LGTM, a few nits in your updated proposal:
* Update {{We will start working with ma (3.0.x) and jb (2.2.x) formats}} to ma 
and la.
* Maybe add [ccm|https://github.com/pauloricardomg/ccm] tool to {{Familiarize 
with Cassandra dtest suit.}}

bq. In addition, do you mean with double cycle support that our 
sstabledowngrader should work correctly with a flow like "ma" -> "ka" -> "la"?

Would be something like ma -> la -> ma -> la -> ma and check the data is 
correct. please note that upgrade from la -> ma is already supported via the 
upgradesstables tool and you would add support to downgrade from ma -> la via 
the sstabledowngrader tool. Actually {{StandaloneUpgrader}} is probably more 
relevant then {{SStableScrubber}} in this context so you should mention this in 
your proposal instead(although sstable scrubber is also important for learning 
purposes because it validates the sstable when reading). You should also 
probably have a look on {{OldFormatIterator}} and {{OldFormatDeserializer}} 
classes to learn how sstables are read in the previous format during your 
familiarization period.

Another thing that could possibly help in your Apache GSoC application is to 
work on a [low hanging fruit 
ticket|https://issues.apache.org/jira/browse/CASSANDRA-11352?jql=project%20%3D%20CASSANDRA%20AND%20status%20%3D%20Open%20AND%20labels%20%3D%20lhf]
 to prove your ability to dive into a complex codebase (CASSANDRA- and 
CASSANDRA-8777 are probably good for beginners). Please note that this is not 
required, but would only be a plus in your application to the Apache selection 
committee and does not need to be done before the application deadline since 
the decision will probably be taken only a few weeks after that.

> Add downgradesstables
> -
>
> Key: CASSANDRA-8928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8928
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Jeremy Hanna
>Priority: Minor
>  Labels: gsoc2016, mentor
>
> As mentioned in other places such as CASSANDRA-8047 and in the wild, 
> sometimes you need to go back.  A downgrade sstables utility would be nice 
> for a lot of reasons and I don't know that supporting going back to the 
> previous major version format would be too much code since we already support 
> reading the previous version.



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

[jira] [Updated] (CASSANDRA-11383) Avoid index segment stitching in RAM which lead to OOM on big SSTable files

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich updated CASSANDRA-11383:

Summary: Avoid index segment stitching in RAM which lead to OOM on big 
SSTable files   (was: SASI index build leads to massive OOM)

> Avoid index segment stitching in RAM which lead to OOM on big SSTable files 
> 
>
> Key: CASSANDRA-11383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11383
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: C* 3.4
>Reporter: DOAN DuyHai
>Assignee: Jordan West
> Fix For: 3.5
>
> Attachments: CASSANDRA-11383.patch, 
> SASI_Index_build_LCS_1G_Max_SSTable_Size_logs.tar.gz, 
> new_system_log_CMS_8GB_OOM.log, system.log_sasi_build_oom
>
>
> 13 bare metal machines
> - 6 cores CPU (12 HT)
> - 64Gb RAM
> - 4 SSD in RAID0
>  JVM settings:
> - G1 GC
> - Xms32G, Xmx32G
> Data set:
>  - ≈ 100Gb/per node
>  - 1.3 Tb cluster-wide
>  - ≈ 20Gb for all SASI indices
> C* settings:
> - concurrent_compactors: 1
> - compaction_throughput_mb_per_sec: 256
> - memtable_heap_space_in_mb: 2048
> - memtable_offheap_space_in_mb: 2048
> I created 9 SASI indices
>  - 8 indices with text field, NonTokenizingAnalyser,  PREFIX mode, 
> case-insensitive
>  - 1 index with numeric field, SPARSE mode
>  After a while, the nodes just gone OOM.
>  I attach log files. You can see a lot of GC happening while index segments 
> are flush to disk. At some point the node OOM ...
> /cc [~xedin]



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

[jira] [Assigned] (CASSANDRA-11225) dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters

[Russ Hatch (JIRA)]

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

Russ Hatch reassigned CASSANDRA-11225:
--

Assignee: Russ Hatch  (was: DS Test Eng)

> dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters
> 
>
> Key: CASSANDRA-11225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11225
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Russ Hatch
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/209/testReport/consistency_test/TestAccuracy/test_simple_strategy_counters
> Failed on CassCI build cassandra-2.1_novnode_dtest #209
> error: "AssertionError: Failed to read value from sufficient number of nodes, 
> required 2 but got 1 - [574, 2]"



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

[jira] [Comment Edited] (CASSANDRA-10943) NullPointer during LegacySchemaMigrator

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko edited comment on CASSANDRA-10943 at 3/23/16 11:27 PM:
-

Pushed a patch that simply future-ports {{calculateIsDense}} logic verbatim to 
3.0 from 2.1/2.2 and calls the method if {{is_dense}} field is missing from the 
migrating tables for any reason. This fixes the potential NPE issue, though 
there is at least one more related problem with {{is_dense}}, for Thrift tables 
that start as dense and get columns added later. I will address that - with 
extra tests - in CASSANDRA-11315.


was (Author: iamaleksey):
Pushed a patch that simply backports {{calculateIsDense}} logic verbatim to 3.0 
and calls the method if {{is_dense}} field is missing from the migrating tables 
for any reason. This fixes the potential NPE issue, though there is at least 
one more related problem with {{is_dense}}, for Thrift tables that start as 
dense and get columns added later. I will address that - with extra tests - in 
CASSANDRA-11315.

> NullPointer during LegacySchemaMigrator
> ---
>
> Key: CASSANDRA-10943
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10943
> Project: Cassandra
>  Issue Type: Bug
> Environment: Debian Jessie
> java version "1.8.0_66"
> Cassandra 2.2.4 -> 3.1.1 migration
>Reporter: Stephan Wienczny
>Assignee: Aleksey Yeschenko
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
> Attachments: 10943.txt
>
>
> I'm trying to upgrade my Cassandra cluster  from 2.2.4 to 3.1.1.
> I used
> {quote}
> nodetool upgradesstables
> nodetool drain
> {quote}
> before upgrading.  
> The result is this:
> {quote}
> INFO  [main] 2015-12-26 22:41:44,114 SystemKeyspace.java:1284 - Detected 
> version upgrade from 2.2.4 to 3.1.1, snapshotting system keyspace
> WARN  [main] 2015-12-26 22:41:44,318 CompressionParams.java:382 - The 
> sstable_compression option has been deprecated. You should use class instead
> ERROR [main] 2015-12-26 22:41:44,427 CassandraDaemon.java:690 - Exception 
> encountered during startup
> java.lang.NullPointerException: null
>   at 
> org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:33)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:24)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:114) 
> ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getBoolean(UntypedResultSet.java:272)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.decodeTableMetadata(LegacySchemaMigrator.java:264)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTableMetadata(LegacySchemaMigrator.java:250)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTable(LegacySchemaMigrator.java:221)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readTables$218(LegacySchemaMigrator.java:214)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_66]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTables(LegacySchemaMigrator.java:214)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readKeyspace(LegacySchemaMigrator.java:163)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readSchema$215(LegacySchemaMigrator.java:154)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_66]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readSchema(LegacySchemaMigrator.java:154)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.migrate(LegacySchemaMigrator.java:77)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:223) 
> [apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:549)
>  [apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:677) 
> [apache-cassandra-3.1.1.jar:3.1.1]
> {quote}



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

[jira] [Updated] (CASSANDRA-10943) NullPointer during LegacySchemaMigrator

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10943:
--
Priority: Minor  (was: Critical)

> NullPointer during LegacySchemaMigrator
> ---
>
> Key: CASSANDRA-10943
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10943
> Project: Cassandra
>  Issue Type: Bug
> Environment: Debian Jessie
> java version "1.8.0_66"
> Cassandra 2.2.4 -> 3.1.1 migration
>Reporter: Stephan Wienczny
>Assignee: Aleksey Yeschenko
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
> Attachments: 10943.txt
>
>
> I'm trying to upgrade my Cassandra cluster  from 2.2.4 to 3.1.1.
> I used
> {quote}
> nodetool upgradesstables
> nodetool drain
> {quote}
> before upgrading.  
> The result is this:
> {quote}
> INFO  [main] 2015-12-26 22:41:44,114 SystemKeyspace.java:1284 - Detected 
> version upgrade from 2.2.4 to 3.1.1, snapshotting system keyspace
> WARN  [main] 2015-12-26 22:41:44,318 CompressionParams.java:382 - The 
> sstable_compression option has been deprecated. You should use class instead
> ERROR [main] 2015-12-26 22:41:44,427 CassandraDaemon.java:690 - Exception 
> encountered during startup
> java.lang.NullPointerException: null
>   at 
> org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:33)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:24)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:114) 
> ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getBoolean(UntypedResultSet.java:272)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.decodeTableMetadata(LegacySchemaMigrator.java:264)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTableMetadata(LegacySchemaMigrator.java:250)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTable(LegacySchemaMigrator.java:221)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readTables$218(LegacySchemaMigrator.java:214)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_66]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTables(LegacySchemaMigrator.java:214)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readKeyspace(LegacySchemaMigrator.java:163)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readSchema$215(LegacySchemaMigrator.java:154)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_66]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readSchema(LegacySchemaMigrator.java:154)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.migrate(LegacySchemaMigrator.java:77)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:223) 
> [apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:549)
>  [apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:677) 
> [apache-cassandra-3.1.1.jar:3.1.1]
> {quote}



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

[jira] [Updated] (CASSANDRA-10943) NullPointer during LegacySchemaMigrator

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10943:
--
Reviewer: Sylvain Lebresne

Pushed a patch that simply backports {{calculateIsDense}} logic verbatim to 3.0 
and calls the method if {{is_dense}} field is missing from the migrating tables 
for any reason. This fixes the potential NPE issue, though there is at least 
one more related problem with {{is_dense}}, for Thrift tables that start as 
dense and get columns added later. I will address that - with extra tests - in 
CASSANDRA-11315.

> NullPointer during LegacySchemaMigrator
> ---
>
> Key: CASSANDRA-10943
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10943
> Project: Cassandra
>  Issue Type: Bug
> Environment: Debian Jessie
> java version "1.8.0_66"
> Cassandra 2.2.4 -> 3.1.1 migration
>Reporter: Stephan Wienczny
>Assignee: Aleksey Yeschenko
>Priority: Critical
> Fix For: 3.0.x, 3.x
>
> Attachments: 10943.txt
>
>
> I'm trying to upgrade my Cassandra cluster  from 2.2.4 to 3.1.1.
> I used
> {quote}
> nodetool upgradesstables
> nodetool drain
> {quote}
> before upgrading.  
> The result is this:
> {quote}
> INFO  [main] 2015-12-26 22:41:44,114 SystemKeyspace.java:1284 - Detected 
> version upgrade from 2.2.4 to 3.1.1, snapshotting system keyspace
> WARN  [main] 2015-12-26 22:41:44,318 CompressionParams.java:382 - The 
> sstable_compression option has been deprecated. You should use class instead
> ERROR [main] 2015-12-26 22:41:44,427 CassandraDaemon.java:690 - Exception 
> encountered during startup
> java.lang.NullPointerException: null
>   at 
> org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:33)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:24)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:114) 
> ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getBoolean(UntypedResultSet.java:272)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.decodeTableMetadata(LegacySchemaMigrator.java:264)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTableMetadata(LegacySchemaMigrator.java:250)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTable(LegacySchemaMigrator.java:221)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readTables$218(LegacySchemaMigrator.java:214)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_66]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTables(LegacySchemaMigrator.java:214)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readKeyspace(LegacySchemaMigrator.java:163)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readSchema$215(LegacySchemaMigrator.java:154)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_66]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readSchema(LegacySchemaMigrator.java:154)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.migrate(LegacySchemaMigrator.java:77)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:223) 
> [apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:549)
>  [apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:677) 
> [apache-cassandra-3.1.1.jar:3.1.1]
> {quote}



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

[jira] [Updated] (CASSANDRA-10943) NullPointer during LegacySchemaMigrator

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10943:
--
Fix Version/s: 3.x
   Status: Patch Available  (was: In Progress)

> NullPointer during LegacySchemaMigrator
> ---
>
> Key: CASSANDRA-10943
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10943
> Project: Cassandra
>  Issue Type: Bug
> Environment: Debian Jessie
> java version "1.8.0_66"
> Cassandra 2.2.4 -> 3.1.1 migration
>Reporter: Stephan Wienczny
>Assignee: Aleksey Yeschenko
>Priority: Critical
> Fix For: 3.0.x, 3.x
>
> Attachments: 10943.txt
>
>
> I'm trying to upgrade my Cassandra cluster  from 2.2.4 to 3.1.1.
> I used
> {quote}
> nodetool upgradesstables
> nodetool drain
> {quote}
> before upgrading.  
> The result is this:
> {quote}
> INFO  [main] 2015-12-26 22:41:44,114 SystemKeyspace.java:1284 - Detected 
> version upgrade from 2.2.4 to 3.1.1, snapshotting system keyspace
> WARN  [main] 2015-12-26 22:41:44,318 CompressionParams.java:382 - The 
> sstable_compression option has been deprecated. You should use class instead
> ERROR [main] 2015-12-26 22:41:44,427 CassandraDaemon.java:690 - Exception 
> encountered during startup
> java.lang.NullPointerException: null
>   at 
> org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:33)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:24)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:114) 
> ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getBoolean(UntypedResultSet.java:272)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.decodeTableMetadata(LegacySchemaMigrator.java:264)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTableMetadata(LegacySchemaMigrator.java:250)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTable(LegacySchemaMigrator.java:221)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readTables$218(LegacySchemaMigrator.java:214)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_66]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTables(LegacySchemaMigrator.java:214)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readKeyspace(LegacySchemaMigrator.java:163)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readSchema$215(LegacySchemaMigrator.java:154)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_66]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readSchema(LegacySchemaMigrator.java:154)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.migrate(LegacySchemaMigrator.java:77)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:223) 
> [apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:549)
>  [apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:677) 
> [apache-cassandra-3.1.1.jar:3.1.1]
> {quote}



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

[jira] [Commented] (CASSANDRA-10943) NullPointer during LegacySchemaMigrator

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10943:
---

||branch||testall||dtest||
|[10943-3.0|https://github.com/iamaleksey/cassandra/tree/10943-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/iamaleksey/job/iamaleksey-10943-3.0-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/iamaleksey/job/iamaleksey-10943-3.0-dtest]|
|[10943-3.5|https://github.com/iamaleksey/cassandra/tree/10943-3.5]|[testall|http://cassci.datastax.com/view/Dev/view/iamaleksey/job/iamaleksey-10943-3.5-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/iamaleksey/job/iamaleksey-10943-3.5-dtest]|
|[10943-3.6|https://github.com/iamaleksey/cassandra/tree/10943-3.6]|[testall|http://cassci.datastax.com/view/Dev/view/iamaleksey/job/iamaleksey-10943-3.6-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/iamaleksey/job/iamaleksey-10943-3.6-dtest]|

> NullPointer during LegacySchemaMigrator
> ---
>
> Key: CASSANDRA-10943
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10943
> Project: Cassandra
>  Issue Type: Bug
> Environment: Debian Jessie
> java version "1.8.0_66"
> Cassandra 2.2.4 -> 3.1.1 migration
>Reporter: Stephan Wienczny
>Assignee: Aleksey Yeschenko
>Priority: Critical
> Fix For: 3.0.x
>
> Attachments: 10943.txt
>
>
> I'm trying to upgrade my Cassandra cluster  from 2.2.4 to 3.1.1.
> I used
> {quote}
> nodetool upgradesstables
> nodetool drain
> {quote}
> before upgrading.  
> The result is this:
> {quote}
> INFO  [main] 2015-12-26 22:41:44,114 SystemKeyspace.java:1284 - Detected 
> version upgrade from 2.2.4 to 3.1.1, snapshotting system keyspace
> WARN  [main] 2015-12-26 22:41:44,318 CompressionParams.java:382 - The 
> sstable_compression option has been deprecated. You should use class instead
> ERROR [main] 2015-12-26 22:41:44,427 CassandraDaemon.java:690 - Exception 
> encountered during startup
> java.lang.NullPointerException: null
>   at 
> org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:33)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:24)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:114) 
> ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getBoolean(UntypedResultSet.java:272)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.decodeTableMetadata(LegacySchemaMigrator.java:264)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTableMetadata(LegacySchemaMigrator.java:250)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTable(LegacySchemaMigrator.java:221)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readTables$218(LegacySchemaMigrator.java:214)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_66]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTables(LegacySchemaMigrator.java:214)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readKeyspace(LegacySchemaMigrator.java:163)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readSchema$215(LegacySchemaMigrator.java:154)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_66]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readSchema(LegacySchemaMigrator.java:154)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.schema.LegacySchemaMigrator.migrate(LegacySchemaMigrator.java:77)
>  ~[apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:223) 
> [apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:549)
>  [apache-cassandra-3.1.1.jar:3.1.1]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:677) 
> [apache-cassandra-3.1.1.jar:3.1.1]
> {quote}



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

[jira] [Updated] (CASSANDRA-11415) dtest failure in jmx_test.TestJMX.cfhistograms_test

[Yuki Morishita (JIRA)]

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

Yuki Morishita updated CASSANDRA-11415:
---
Status: Patch Available  (was: Open)

Basically backported CASSANDRA-10859 to 2.1.
(2.2 and 3.0 are covered in CASSANDRA-11297, so only 2.1 has issue.)

||branch||testall||dtest||
|[11415|https://github.com/yukim/cassandra/tree/11415]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-11415-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-11415-dtest/lastCompletedBuild/testReport/]|


> dtest failure in jmx_test.TestJMX.cfhistograms_test
> ---
>
> Key: CASSANDRA-11415
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11415
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Yuki Morishita
>  Labels: dtest
> Fix For: 2.1.x
>
>
> We are seeing the following stacktrace when running nodetool cfhistograms
> {code}
> java.lang.AssertionError
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.(EstimatedHistogram.java:66)
>   at 
> org.apache.cassandra.tools.NodeProbe.metricPercentilesAsArray(NodeProbe.java:1260)
>   at 
> org.apache.cassandra.tools.NodeTool$CfHistograms.execute(NodeTool.java:1109)
>   at 
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:292)
>   at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:206)
> {code}
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/437/testReport/jmx_test/TestJMX/cfhistograms_test
> Failed on CassCI build cassandra-2.1_dtest #437
> This doesn't appear to be flaky. I can repro locally. It seems like a product 
> issue, but if someone could confirm if it happens out of the test, that would 
> be great.



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

[jira] [Commented] (CASSANDRA-11418) Nodetool status should reflect hibernate/replacing states

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11418:
-

I'm reworking replace in the context of CASSANDRA-9244 and in this 
implementation a node replacing another node is shown as UJ from his or other 
nodes points of view, so this should be less of a problem if that gets merged. 
But we can still use this ticket to improve nodetool status output for other 
hibernating states, and/or maybe show more details if a replacement is taking 
place.

> Nodetool status should reflect hibernate/replacing states
> -
>
> Key: CASSANDRA-11418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11418
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability, Tools
>Reporter: Joel Knighton
>Priority: Minor
> Fix For: 3.x
>
>
> Currently, the four options for state in nodetool status are 
> joining/leaving/moving/normal.
> Joining nodes are determined based on bootstrap tokens, leaving nodes are 
> based on leaving endpoints in TokenMetadata, moving nodes are based on moving 
> endpoints in TokenMetadata.
> This means that a node will appear in normal state when going through a 
> bootstrap with flag replace_address, which can be confusing to operators.
> We should add another state for hibernation/replacing to make this visible. 
> This will require a way to get a list of all hibernating endpoints.



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

[jira] [Created] (CASSANDRA-11419) On local cassandra installations, rack-dc from ROOT/conf isn't honored.

[Anubhav Kale (JIRA)]

Anubhav Kale created CASSANDRA-11419:


 Summary: On local cassandra installations, rack-dc from ROOT/conf 
isn't honored.
 Key: CASSANDRA-11419
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11419
 Project: Cassandra
  Issue Type: Bug
Reporter: Anubhav Kale
Priority: Minor


1. Get the latest sources from trunk, build in eclipse. I am doing this on 
Windows BTW.
2. Run from Eclipse
3. Bug: The change in conf/cassandra-rackdc.properties isn't honored. Instead, 
the one in test/conf/cassandra-rackdc.properties is honored.

Since yaml changes from conf/ are used, why don't we stay consistent for other 
files as well ?




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

[jira] [Updated] (CASSANDRA-11383) SASI index build leads to massive OOM

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich updated CASSANDRA-11383:

 Reviewer: Pavel Yaskevich
Fix Version/s: 3.5

> SASI index build leads to massive OOM
> -
>
> Key: CASSANDRA-11383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11383
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: C* 3.4
>Reporter: DOAN DuyHai
>Assignee: Jordan West
> Fix For: 3.5
>
> Attachments: CASSANDRA-11383.patch, 
> SASI_Index_build_LCS_1G_Max_SSTable_Size_logs.tar.gz, 
> new_system_log_CMS_8GB_OOM.log, system.log_sasi_build_oom
>
>
> 13 bare metal machines
> - 6 cores CPU (12 HT)
> - 64Gb RAM
> - 4 SSD in RAID0
>  JVM settings:
> - G1 GC
> - Xms32G, Xmx32G
> Data set:
>  - ≈ 100Gb/per node
>  - 1.3 Tb cluster-wide
>  - ≈ 20Gb for all SASI indices
> C* settings:
> - concurrent_compactors: 1
> - compaction_throughput_mb_per_sec: 256
> - memtable_heap_space_in_mb: 2048
> - memtable_offheap_space_in_mb: 2048
> I created 9 SASI indices
>  - 8 indices with text field, NonTokenizingAnalyser,  PREFIX mode, 
> case-insensitive
>  - 1 index with numeric field, SPARSE mode
>  After a while, the nodes just gone OOM.
>  I attach log files. You can see a lot of GC happening while index segments 
> are flush to disk. At some point the node OOM ...
> /cc [~xedin]



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

[jira] [Updated] (CASSANDRA-11383) SASI index build leads to massive OOM

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich updated CASSANDRA-11383:

Assignee: Jordan West

> SASI index build leads to massive OOM
> -
>
> Key: CASSANDRA-11383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11383
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: C* 3.4
>Reporter: DOAN DuyHai
>Assignee: Jordan West
> Fix For: 3.5
>
> Attachments: CASSANDRA-11383.patch, 
> SASI_Index_build_LCS_1G_Max_SSTable_Size_logs.tar.gz, 
> new_system_log_CMS_8GB_OOM.log, system.log_sasi_build_oom
>
>
> 13 bare metal machines
> - 6 cores CPU (12 HT)
> - 64Gb RAM
> - 4 SSD in RAID0
>  JVM settings:
> - G1 GC
> - Xms32G, Xmx32G
> Data set:
>  - ≈ 100Gb/per node
>  - 1.3 Tb cluster-wide
>  - ≈ 20Gb for all SASI indices
> C* settings:
> - concurrent_compactors: 1
> - compaction_throughput_mb_per_sec: 256
> - memtable_heap_space_in_mb: 2048
> - memtable_offheap_space_in_mb: 2048
> I created 9 SASI indices
>  - 8 indices with text field, NonTokenizingAnalyser,  PREFIX mode, 
> case-insensitive
>  - 1 index with numeric field, SPARSE mode
>  After a while, the nodes just gone OOM.
>  I attach log files. You can see a lot of GC happening while index segments 
> are flush to disk. At some point the node OOM ...
> /cc [~xedin]



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

[jira] [Updated] (CASSANDRA-11410) Option to specify ProtocolVersion in cassandra-stress

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11410:

Reviewer: T Jake Luciani

> Option to specify ProtocolVersion in cassandra-stress
> -
>
> Key: CASSANDRA-11410
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11410
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Testing, Tools
>Reporter: mck
>Assignee: mck
> Attachments: 11410-trunk.txt
>
>
> Currently {{cassandra-stress}} is hardcoded to 
> ProtocolVersion.NEWEST_SUPPORTED.
> It is not always the true that the cassandra version being stressed is the 
> same as that cassandra-stress is being used from. An example is wanting to 
> use the graphing feature against Cassandra-2.1
> This patch offers the option to specify the ProtocolVersion.



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

[jira] [Updated] (CASSANDRA-11381) Node running with join_ring=false and authentication can not serve requests

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11381:

Reviewer: Joel Knighton

> Node running with join_ring=false and authentication can not serve requests
> ---
>
> Key: CASSANDRA-11381
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11381
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
> Attachments: 11381-2.0.txt, 11381-2.1.txt, 11381-2.2.txt, 
> 11381-3.0.txt, 11381-trunk.txt, dtest-11381-trunk.txt
>
>
> Starting up a node with {{-Dcassandra.join_ring=false}} in a cluster that has 
> authentication configured, eg PasswordAuthenticator, won't be able to serve 
> requests. This is because {{Auth.setup()}} never gets called during the 
> startup.
> Without {{Auth.setup()}} having been called in {{StorageService}} clients 
> connecting to the node fail with the node throwing
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:119)
> at 
> org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1471)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3505)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3489)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
> at 
> com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:695)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:689)
> at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The exception thrown from the 
> [code|https://github.com/apache/cassandra/blob/cassandra-2.0.16/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java#L119]
> {code}
> ResultMessage.Rows rows = 
> authenticateStatement.execute(QueryState.forInternalCalls(), new 
> QueryOptions(consistencyForUser(username),
>   
>Lists.newArrayList(ByteBufferUtil.bytes(username;
> {code}



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

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

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-8844:


Yeah, I kind of brain-barfed that previous comment.

Right now I'm targeting having a cdc_directory and cdc_overflow_directory, 
configurable via yaml. Default for cdc_directory is commitlog/cdc, overflow is 
data/cdc_overflow.

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

[jira] [Commented] (CASSANDRA-11361) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_round_trip_with_rate_file

[Russ Hatch (JIRA)]

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

Russ Hatch commented on CASSANDRA-11361:


no failures out of 250. I think this is good to resolve.

> dtest failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_round_trip_with_rate_file
> --
>
> Key: CASSANDRA-11361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11361
> Project: Cassandra
>  Issue Type: Test
>Reporter: Jim Witschey
>Assignee: Russ Hatch
>  Labels: dtest
>
> This test has started failing recently:
> http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/318/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_round_trip_with_rate_file
> In addition to failing on the offheap-memtable job, it also fails on the 
> vanilla 2.1 job:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_round_trip_with_rate_file/
> which makes me think this isn't just a weird flap. I have not yet seen this 
> failure on versions higher than 2.1.
> Test Eng should take the first crack at debugging this, but if you don't make 
> headway, Stefania added the test in November, so she's probably the person to 
> escalate this to.



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

[jira] [Resolved] (CASSANDRA-11361) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_round_trip_with_rate_file

[Russ Hatch (JIRA)]

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

Russ Hatch resolved CASSANDRA-11361.

Resolution: Cannot Reproduce

> dtest failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_round_trip_with_rate_file
> --
>
> Key: CASSANDRA-11361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11361
> Project: Cassandra
>  Issue Type: Test
>Reporter: Jim Witschey
>Assignee: Russ Hatch
>  Labels: dtest
>
> This test has started failing recently:
> http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/318/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_round_trip_with_rate_file
> In addition to failing on the offheap-memtable job, it also fails on the 
> vanilla 2.1 job:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_round_trip_with_rate_file/
> which makes me think this isn't just a weird flap. I have not yet seen this 
> failure on versions higher than 2.1.
> Test Eng should take the first crack at debugging this, but if you don't make 
> headway, Stefania added the test in November, so she's probably the person to 
> escalate this to.



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

[jira] [Commented] (CASSANDRA-11315) Upgrade from 2.2.5 to 3.0.3 Fails with AssertionError

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-11315:
---

Just use {{UPDATE}} statements to {{SET is_dense = false}} for those columns in 
{{system.schema_columnfamilies}} table.

> Upgrade from 2.2.5 to 3.0.3 Fails with AssertionError
> -
>
> Key: CASSANDRA-11315
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11315
> Project: Cassandra
>  Issue Type: Bug
> Environment: Ubuntu 14.04, Oracle Java 8, Apache Cassandra 2.2.5 -> 
> 3.0.3
>Reporter: Dominik Keil
>Assignee: Aleksey Yeschenko
>Priority: Blocker
> Fix For: 3.0.x, 3.x
>
>
> Hi,
> when trying to upgrade our development cluster from C* 2.2.5 to 3.0.3 
> Cassandra fails during startup.
> Here's the relevant log snippet:
> {noformat}
> [...]
> INFO  [main] 2016-03-08 11:42:01,291 ColumnFamilyStore.java:381 - 
> Initializing system.schema_triggers
> INFO  [main] 2016-03-08 11:42:01,302 ColumnFamilyStore.java:381 - 
> Initializing system.schema_usertypes
> INFO  [main] 2016-03-08 11:42:01,313 ColumnFamilyStore.java:381 - 
> Initializing system.schema_functions
> INFO  [main] 2016-03-08 11:42:01,324 ColumnFamilyStore.java:381 - 
> Initializing system.schema_aggregates
> INFO  [main] 2016-03-08 11:42:01,576 SystemKeyspace.java:1284 - Detected 
> version upgrade from 2.2.5 to 3.0.3, snapshotting system keyspace
> WARN  [main] 2016-03-08 11:42:01,911 CompressionParams.java:382 - The 
> sstable_compression option has been deprecated. You should use class instead
> WARN  [main] 2016-03-08 11:42:01,959 CompressionParams.java:333 - The 
> chunk_length_kb option has been deprecated. You should use chunk_length_in_kb 
> instead
> ERROR [main] 2016-03-08 11:42:02,638 CassandraDaemon.java:692 - Exception 
> encountered during startup
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.db.CompactTables.getCompactValueColumn(CompactTables.java:90)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.config.CFMetaData.rebuild(CFMetaData.java:315) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:291) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at org.apache.cassandra.config.CFMetaData.create(CFMetaData.java:367) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.decodeTableMetadata(LegacySchemaMigrator.java:337)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTableMetadata(LegacySchemaMigrator.java:273)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTable(LegacySchemaMigrator.java:244)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readTables$227(LegacySchemaMigrator.java:237)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_74]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTables(LegacySchemaMigrator.java:237)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readKeyspace(LegacySchemaMigrator.java:186)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readSchema$224(LegacySchemaMigrator.java:177)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_74]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readSchema(LegacySchemaMigrator.java:177)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.migrate(LegacySchemaMigrator.java:77)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:223) 
> [apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:551)
>  [apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:679) 
> [apache-cassandra-3.0.3.jar:3.0.3]
> {noformat}



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

[jira] [Commented] (CASSANDRA-9779) Append-only optimization

[Jon Haddad (JIRA)]

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

Jon Haddad commented on CASSANDRA-9779:
---

This seems like it would cause cluster errors between the point where you 
altered a table and when you pushed new code into production.  I'd -1 this 
based on the volume of problems this is likely to cause for people.

> Append-only optimization
> 
>
> Key: CASSANDRA-9779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9779
> Project: Cassandra
>  Issue Type: New Feature
>  Components: CQL
>Reporter: Jonathan Ellis
> Fix For: 3.x
>
>
> Many common workloads are append-only: that is, they insert new rows but do 
> not update existing ones.  However, Cassandra has no way to infer this and so 
> it must treat all tables as if they may experience updates in the future.
> If we added syntax to tell Cassandra about this ({{WITH INSERTS ONLY}} for 
> instance) then we could do a number of optimizations:
> - Compaction would only need to worry about defragmenting partitions, not 
> rows.  We could default to DTCS or similar.
> - CollationController could stop scanning sstables as soon as it finds a 
> matching row
> - Most importantly, materialized views wouldn't need to worry about deleting 
> prior values, which would eliminate the majority of the MV overhead



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

[jira] [Updated] (CASSANDRA-11078) upgrade_supercolumns_test dtests failing on 2.1

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-11078:

Fix Version/s: (was: 3.x)
   Status: Patch Available  (was: Open)

Surprisingly fixable:
https://github.com/riptano/cassandra-dtest/pull/888

> upgrade_supercolumns_test dtests failing on 2.1
> ---
>
> Key: CASSANDRA-11078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11078
> Project: Cassandra
>  Issue Type: Test
>Reporter: Jim Witschey
>Assignee: Philip Thompson
>  Labels: dtest
>
> This tests in this module fail 
> [here|https://github.com/riptano/cassandra-dtest/blob/18647a3e167f127795e2fe63d73305dddf103716/upgrade_supercolumns_test.py#L213]
>  and 
> [here|https://github.com/riptano/cassandra-dtest/blob/529cd71ad5ac4c2f28ccb5560ddc068f604c7b28/upgrade_supercolumns_test.py#L106]
>  when a call to {{start}} with {{wait_other_notice=True}} times out. It 
> happens consistently on the upgrade path from cassandra-2.1 to 2.2. I haven't 
> seen clear evidence as to whether this is a test failure or a C* bug, so I'll 
> mark it as a test error for the TE team to debug.
> I don't have a CassCI link for this failure - the changes to the tests 
> haven't been merged yet.
> EDIT: changing the title of this ticket since there are multiple similar 
> failures. The failing tests are
> {code}
> upgrade_supercolumns_test.py:TestSCUpgrade.upgrade_with_counters_test failing
> upgrade_supercolumns_test.py:TestSCUpgrade.upgrade_with_index_creation_test
> {code}



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

[jira] [Commented] (CASSANDRA-11361) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_round_trip_with_rate_file

[Russ Hatch (JIRA)]

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

Russ Hatch commented on CASSANDRA-11361:


doing a bulk run here: 
http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/39/

> dtest failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_round_trip_with_rate_file
> --
>
> Key: CASSANDRA-11361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11361
> Project: Cassandra
>  Issue Type: Test
>Reporter: Jim Witschey
>Assignee: Russ Hatch
>  Labels: dtest
>
> This test has started failing recently:
> http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/318/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_round_trip_with_rate_file
> In addition to failing on the offheap-memtable job, it also fails on the 
> vanilla 2.1 job:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_round_trip_with_rate_file/
> which makes me think this isn't just a weird flap. I have not yet seen this 
> failure on versions higher than 2.1.
> Test Eng should take the first crack at debugging this, but if you don't make 
> headway, Stefania added the test in November, so she's probably the person to 
> escalate this to.



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

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

[Nick Bailey (JIRA)]

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

Nick Bailey commented on CASSANDRA-7190:


[~iamaleksey] I don't think CASSANDRA-9587 completely duplicates this. The 
schema we care about here is the latest schema at the time of the snapshot, not 
the schema associated with every sstable in the snapshot. The schema can change 
from sstable to sstable and the changes may be forward compatible but not 
backward compatible.

> Add schema to snapshot manifest
> ---
>
> Key: CASSANDRA-7190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Jonathan Ellis
>Priority: Minor
>
> followup from CASSANDRA-6326



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

[jira] [Commented] (CASSANDRA-11315) Upgrade from 2.2.5 to 3.0.3 Fails with AssertionError

[Christian Spriegel (JIRA)]

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

Christian Spriegel commented on CASSANDRA-11315:


[~iamaleksey]:
How can we explicitly disable dense manually? I would simply rename the columns 
using CQLSH, to give them a CQL3 schema.

btw: I assume MDS_0 has the same issue?

> Upgrade from 2.2.5 to 3.0.3 Fails with AssertionError
> -
>
> Key: CASSANDRA-11315
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11315
> Project: Cassandra
>  Issue Type: Bug
> Environment: Ubuntu 14.04, Oracle Java 8, Apache Cassandra 2.2.5 -> 
> 3.0.3
>Reporter: Dominik Keil
>Assignee: Aleksey Yeschenko
>Priority: Blocker
> Fix For: 3.0.x, 3.x
>
>
> Hi,
> when trying to upgrade our development cluster from C* 2.2.5 to 3.0.3 
> Cassandra fails during startup.
> Here's the relevant log snippet:
> {noformat}
> [...]
> INFO  [main] 2016-03-08 11:42:01,291 ColumnFamilyStore.java:381 - 
> Initializing system.schema_triggers
> INFO  [main] 2016-03-08 11:42:01,302 ColumnFamilyStore.java:381 - 
> Initializing system.schema_usertypes
> INFO  [main] 2016-03-08 11:42:01,313 ColumnFamilyStore.java:381 - 
> Initializing system.schema_functions
> INFO  [main] 2016-03-08 11:42:01,324 ColumnFamilyStore.java:381 - 
> Initializing system.schema_aggregates
> INFO  [main] 2016-03-08 11:42:01,576 SystemKeyspace.java:1284 - Detected 
> version upgrade from 2.2.5 to 3.0.3, snapshotting system keyspace
> WARN  [main] 2016-03-08 11:42:01,911 CompressionParams.java:382 - The 
> sstable_compression option has been deprecated. You should use class instead
> WARN  [main] 2016-03-08 11:42:01,959 CompressionParams.java:333 - The 
> chunk_length_kb option has been deprecated. You should use chunk_length_in_kb 
> instead
> ERROR [main] 2016-03-08 11:42:02,638 CassandraDaemon.java:692 - Exception 
> encountered during startup
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.db.CompactTables.getCompactValueColumn(CompactTables.java:90)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.config.CFMetaData.rebuild(CFMetaData.java:315) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:291) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at org.apache.cassandra.config.CFMetaData.create(CFMetaData.java:367) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.decodeTableMetadata(LegacySchemaMigrator.java:337)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTableMetadata(LegacySchemaMigrator.java:273)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTable(LegacySchemaMigrator.java:244)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readTables$227(LegacySchemaMigrator.java:237)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_74]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTables(LegacySchemaMigrator.java:237)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readKeyspace(LegacySchemaMigrator.java:186)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readSchema$224(LegacySchemaMigrator.java:177)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_74]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readSchema(LegacySchemaMigrator.java:177)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.migrate(LegacySchemaMigrator.java:77)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:223) 
> [apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:551)
>  [apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:679) 
> [apache-cassandra-3.0.3.jar:3.0.3]
> {noformat}



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

[jira] [Commented] (CASSANDRA-11093) processs restarts are failing becase native port and jmx ports are in use

[varun (JIRA)]

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

varun commented on CASSANDRA-11093:
---

Hi, Yes, I was able to test and restart now seems to work fine. Thanks

> processs restarts are failing becase native port and jmx ports are in use
> -
>
> Key: CASSANDRA-11093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11093
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: PROD
>Reporter: varun
>Priority: Minor
>  Labels: lhf
>
> A process restart should automatically take care of this. But it is not and 
> it is a problem.
> The ports are are considered in use even if the process has quit/died/killed 
> but the socket is in a TIME_WAIT state in the TCP FSM 
> (http://tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm).
> tcp 0 0 127.0.0.1:7199 0.0.0.0:* LISTEN 30099/java
> tcp 0 0 192.168.1.2:9160 0.0.0.0:* LISTEN 30099/java
> tcp 0 0 10.130.128.131:58263 10.130.128.131:9042 TIME_WAIT -
> tcp 0 0 10.130.128.131:58262 10.130.128.131:9042 TIME_WAIT -
> tcp 0 0 :::10.130.128.131:9042 :::* LISTEN 30099/java
> tcp 0 0 :::10.130.128.131:9042 :::10.130.128.131:57191 ESTABLISHED 
> 30099/java
> tcp 0 0 :::10.130.128.131:9042 :::10.130.128.131:57190 ESTABLISHED 
> 30099/java
> tcp 0 0 :::10.130.128.131:9042 :::10.176.70.226:37105 ESTABLISHED 
> 30099/java
> tcp 0 0 :::127.0.0.1:42562 :::127.0.0.1:7199 TIME_WAIT -
> tcp 0 0 :::10.130.128.131:57190 :::10.130.128.131:9042 ESTABLISHED 
> 30138/java
> tcp 0 0 :::10.130.128.131:57198 :::10.130.128.131:9042 ESTABLISHED 
> 30138/java
> tcp 0 0 :::10.130.128.131:9042 :::10.176.70.226:37106 ESTABLISHED 
> 30099/java
> tcp 0 0 :::10.130.128.131:57197 :::10.130.128.131:9042 ESTABLISHED 
> 30138/java
> tcp 0 0 :::10.130.128.131:57191 :::10.130.128.131:9042 ESTABLISHED 
> 30138/java
> tcp 0 0 :::10.130.128.131:9042 :::10.130.128.131:57198 ESTABLISHED 
> 30099/java
> tcp 0 0 :::10.130.128.131:9042 :::10.130.128.131:57197 ESTABLISHED 
> 30099/java
> tcp 0 0 :::127.0.0.1:42567 :::127.0.0.1:7199 TIME_WAIT -
> I had to write a restart handler that does a netstat call and looks to make 
> sure all the TIME_WAIT states exhaust before starting the node back up. This 
> happened on 26 of the 56 when a rolling restart was performed. The issue was 
> mostly around JMX port 7199. There was another rollling restart done on the 
> 26 nodes to remediate the JMX ports issue in that restart one node had the 
> issue where port 9042 was considered used after the restart and the process 
> died after a bit of time.
> What needs to be done for port the native port 9042 and JMX port 7199 is to 
> create the underlying TCP socket with SO_REUSEADDR. This eases the 
> restriction and allows the port to be bound by process even if there are 
> sockets open to that port in the TCP FSM, as long as there is no other 
> process listening on that port. There is a Java method available to set this 
> option in java.net.Socket 
> https://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#setReuseAddress%28boolean%29.
> native port 9042: 
> https://github.com/apache/cassandra/blob/4a0d1caa262af3b6f2b6d329e45766b4df845a88/tools/stress/src/org/apache/cassandra/stress/settings/SettingsPort.java#L38
> JMX port 7199: 
> https://github.com/apache/cassandra/blob/4a0d1caa262af3b6f2b6d329e45766b4df845a88/tools/stress/src/org/apache/cassandra/stress/settings/SettingsPort.java#L40
> Looking in the code itself this option is being set on thrift (9160 
> (default)) and internode communication ports, uncrypted (7000 (default)) and 
> SSL encrypted (7001 (default)) .
> https://github.com/apache/cassandra/search?utf8=%E2%9C%93=setReuseAddress
> This needs to be set to native and jmx ports as well.
> References:
> https://unix.stackexchange.com/questions/258379/when-is-a-port-considered-being-used/258380?noredirect=1
> https://stackoverflow.com/questions/23531558/allow-restarting-java-application-with-jmx-monitoring-enabled-immediately
> https://docs.oracle.com/javase/8/docs/technotes/guides/rmi/socketfactory/
> https://github.com/apache/cassandra/search?utf8=%E2%9C%93=setReuseAddress
> https://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#setReuseAddress%28boolean%293
> https://github.com/apache/cassandra/blob/4a0d1caa262af3b6f2b6d329e45766b4df845a88/tools/stress/src/org/apache/cassandra/stress/settings/SettingsPort.java#L38
> https://github.com/apache/cassandra/blob/4a0d1caa262af3b6f2b6d329e45766b4df845a88/tools/stress/src/org/apache/cassandra/stress/settings/SettingsPort.java#L40



--
This message was sent by Atlassian JIRA

[jira] [Commented] (CASSANDRA-8643) merkle tree creation fails with NoSuchElementException

[Thom Valley (JIRA)]

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

Thom Valley commented on CASSANDRA-8643:


Marcus Eriksson, we just hit this error on DSE 4.8.5 / 2.1.13
Have logs, etc. if that is helpful.

> merkle tree creation fails with NoSuchElementException
> --
>
> Key: CASSANDRA-8643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8643
> Project: Cassandra
>  Issue Type: Bug
> Environment: We are running on a three node cluster with three in 
> replication(C* 2.1.1). It uses a default C* installation and STCS.
>Reporter: Jan Karlsson
> Fix For: 2.1.3
>
>
> We have a problem that we encountered during testing over the weekend. 
> During the tests we noticed that repairs started to fail. This error has 
> occured on multiple non-coordinator nodes during repair. It also ran at least 
> once without producing this error.
> We run repair -pr on all nodes on different days. CPU values were around 40% 
> and disk was 50% full.
> From what I understand, the coordinator asked for merkle trees from the other 
> two nodes. However one of the nodes fails to create his merkle tree.
> Unfortunately we do not have a way to reproduce this problem.
> The coordinator receives:
> {noformat}
> 2015-01-09T17:55:57.091+0100  INFO [RepairJobTask:4] RepairJob.java:145 
> [repair #59455950-9820-11e4-b5c1-7797064e1316] requesting merkle trees for 
> censored (to [/xx.90, /xx.98, /xx.82])
> 2015-01-09T17:55:58.516+0100  INFO [AntiEntropyStage:1] 
> RepairSession.java:171 [repair #59455950-9820-11e4-b5c1-7797064e1316] 
> Received merkle tree for censored from /xx.90
> 2015-01-09T17:55:59.581+0100 ERROR [AntiEntropySessions:76] 
> RepairSession.java:303 [repair #59455950-9820-11e4-b5c1-7797064e1316] session 
> completed with the following error
> org.apache.cassandra.exceptions.RepairException: [repair 
> #59455950-9820-11e4-b5c1-7797064e1316 on censored/censored, 
> (-6476420463551243930,-6471459119674373580]] Validation failed in /xx.98
> at 
> org.apache.cassandra.repair.RepairSession.validationComplete(RepairSession.java:166)
>  ~[apache-cassandra-2.1.1.jar:2.1.1]
> at 
> org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:384)
>  ~[apache-cassandra-2.1.1.jar:2.1.1]
> at 
> org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:126)
>  ~[apache-cassandra-2.1.1.jar:2.1.1]
> at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62) 
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  [na:1.7.0_51]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> 2015-01-09T17:55:59.582+0100 ERROR [AntiEntropySessions:76] 
> CassandraDaemon.java:153 Exception in thread 
> Thread[AntiEntropySessions:76,5,RMI Runtime]
> java.lang.RuntimeException: org.apache.cassandra.exceptions.RepairException: 
> [repair #59455950-9820-11e4-b5c1-7797064e1316 on censored/censored, 
> (-6476420463551243930,-6471459119674373580]] Validation failed in /xx.98
> at com.google.common.base.Throwables.propagate(Throwables.java:160) 
> ~[guava-16.0.jar:na]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32) 
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> ~[na:1.7.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
> ~[na:1.7.0_51]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  ~[na:1.7.0_51]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_51]
>at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51] Caused by: 
> org.apache.cassandra.exceptions.RepairException: [repair 
> #59455950-9820-11e4-b5c1-7797064e1316 on censored/censored, 
> (-6476420463551243930,-6471459119674373580]] Validation failed in /xx.98
> at 
> org.apache.cassandra.repair.RepairSession.validationComplete(RepairSession.java:166)
>  ~[apache-cassandra-2.1.1.jar:2.1.1]
> at 
> org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:384)
>  ~[apache-cassandra-2.1.1.jar:2.1.1]
> at 
> org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:126)
>  ~[apache-cassandra-2.1.1.jar:2.1.1]
> at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62) 
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> ... 3 common 

[jira] [Updated] (CASSANDRA-11396) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD.collection_flush_test

[Russ Hatch (JIRA)]

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

Russ Hatch updated CASSANDRA-11396:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD.collection_flush_test
> -
>
> Key: CASSANDRA-11396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11396
> Project: Cassandra
>  Issue Type: Test
>  Components: Testing
>Reporter: Philip Thompson
>Assignee: Russ Hatch
>  Labels: dtest
>
> example failure:
> {code}
> 
> {code}
> http://cassci.datastax.com/job/upgrade_tests-all/25/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD/collection_flush_test
> Failed on CassCI build upgrade_tests-all #25
> It's an inconsistent failure that happens across a number of tests. I'll 
> include all the ones I find here.
> http://cassci.datastax.com/job/upgrade_tests-all/26/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_1_UpTo_2_2_HEAD/static_with_limit_test/
> http://cassci.datastax.com/job/upgrade_tests-all/28/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_2_2_HEAD_UpTo_Trunk/test_data_change_impacting_later_page/
> http://cassci.datastax.com/job/upgrade_tests-all/29/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_1_UpTo_Trunk/range_key_ordered_test/



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

[jira] [Commented] (CASSANDRA-11397) LIKE query on clustering column index returns incorrect results

[Jordan West (JIRA)]

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

Jordan West commented on CASSANDRA-11397:
-

[~beobal] the patch looks good and i've confirmed your fix locally. One small 
piece of feedback: since you fixed things to return a 
{{ClusteringIndexSliceFilter}} I don't think the {{isLike}} check in 
{{PrimaryKeyRestrictionSet#appendTo}} is necessary anymore (i've removed it 
locally without issue). 

> LIKE query on clustering column index returns incorrect results
> ---
>
> Key: CASSANDRA-11397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11397
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>  Labels: sasi
> Fix For: 3.5
>
>
> The way that {{ClusteringIndexFilter}} and {{RowFilter}} are constructed when 
> a {{LIKE}} restriction on a clustering column is present is incorrect. For 
> example:
> {code}
> cqlsh> create table ks.t1 (k text, c1 text, c2 text, c3 text, v text, primary 
> key (k,c1,c2,c3));
> cqlsh> create custom index on ks.t1(c2) using 
> 'org.apache.cassandra.index.sasi.SASIIndex';
> cqlsh> select * from ks.t1;
>  k | c1 | c2 | c3 | v
> ---++++-
>  a | ba | ca | da | val
>  a | bb | cb | db | val
>  a | bc | cc | dc | val
> (3 rows)
>  
> cqlsh> select * from ks.t1 where c1 = 'ba' and c3 = 'da' and c2 LIKE 'c%' 
> ALLOW FILTERING;
>  k | c1 | c2 | c3 | v
> ---++++---
> (0 rows)
> {code}



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

[jira] [Resolved] (CASSANDRA-10868) Skip supercolumns upgrade tests on jdk8

[Philip Thompson (JIRA)]

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

Philip Thompson resolved CASSANDRA-10868.
-
Resolution: Fixed

Jim's PR fixed this ages ago. New failures reasons are being tracked in 
CASSANDRA-11078

> Skip supercolumns upgrade tests on jdk8
> ---
>
> Key: CASSANDRA-10868
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10868
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Jim Witschey
>
> The tests in the {{upgrade_supercolumns_test}} dtest module fail when we test 
> on JDK8 because they attempt to upgrade from 2.0, which will not compile on 
> JDK8:
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/160/testReport/upgrade_supercolumns_test/
> [~rhatch] As we look at how we want to run upgrade tests in the future, we 
> should consider this. In the meantime, I think the best way to deal with this 
> might be to add something to the exclude files in {{conf/}}. That sound 
> reasonable, or is there a better way to do this?



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

[jira] [Commented] (CASSANDRA-11315) Upgrade from 2.2.5 to 3.0.3 Fails with AssertionError

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-11315:
---

Thanks. In the meantime, are you willing to experiment a little in staging, and 
set, manually, {{is_dense}} to {{false}} on all of those tables - using cqlsh - 
in 2.2.5, and then upgrade to 3.0.latest, see if you can read the data 
successfully then?

> Upgrade from 2.2.5 to 3.0.3 Fails with AssertionError
> -
>
> Key: CASSANDRA-11315
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11315
> Project: Cassandra
>  Issue Type: Bug
> Environment: Ubuntu 14.04, Oracle Java 8, Apache Cassandra 2.2.5 -> 
> 3.0.3
>Reporter: Dominik Keil
>Assignee: Aleksey Yeschenko
>Priority: Blocker
> Fix For: 3.0.x, 3.x
>
>
> Hi,
> when trying to upgrade our development cluster from C* 2.2.5 to 3.0.3 
> Cassandra fails during startup.
> Here's the relevant log snippet:
> {noformat}
> [...]
> INFO  [main] 2016-03-08 11:42:01,291 ColumnFamilyStore.java:381 - 
> Initializing system.schema_triggers
> INFO  [main] 2016-03-08 11:42:01,302 ColumnFamilyStore.java:381 - 
> Initializing system.schema_usertypes
> INFO  [main] 2016-03-08 11:42:01,313 ColumnFamilyStore.java:381 - 
> Initializing system.schema_functions
> INFO  [main] 2016-03-08 11:42:01,324 ColumnFamilyStore.java:381 - 
> Initializing system.schema_aggregates
> INFO  [main] 2016-03-08 11:42:01,576 SystemKeyspace.java:1284 - Detected 
> version upgrade from 2.2.5 to 3.0.3, snapshotting system keyspace
> WARN  [main] 2016-03-08 11:42:01,911 CompressionParams.java:382 - The 
> sstable_compression option has been deprecated. You should use class instead
> WARN  [main] 2016-03-08 11:42:01,959 CompressionParams.java:333 - The 
> chunk_length_kb option has been deprecated. You should use chunk_length_in_kb 
> instead
> ERROR [main] 2016-03-08 11:42:02,638 CassandraDaemon.java:692 - Exception 
> encountered during startup
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.db.CompactTables.getCompactValueColumn(CompactTables.java:90)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.config.CFMetaData.rebuild(CFMetaData.java:315) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:291) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at org.apache.cassandra.config.CFMetaData.create(CFMetaData.java:367) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.decodeTableMetadata(LegacySchemaMigrator.java:337)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTableMetadata(LegacySchemaMigrator.java:273)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTable(LegacySchemaMigrator.java:244)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readTables$227(LegacySchemaMigrator.java:237)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_74]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTables(LegacySchemaMigrator.java:237)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readKeyspace(LegacySchemaMigrator.java:186)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readSchema$224(LegacySchemaMigrator.java:177)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_74]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readSchema(LegacySchemaMigrator.java:177)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.migrate(LegacySchemaMigrator.java:77)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:223) 
> [apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:551)
>  [apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:679) 
> [apache-cassandra-3.0.3.jar:3.0.3]
> {noformat}



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

[jira] [Commented] (CASSANDRA-11315) Upgrade from 2.2.5 to 3.0.3 Fails with AssertionError

[Christian Spriegel (JIRA)]

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

Christian Spriegel commented on CASSANDRA-11315:


[~iamaleksey]:
The Auth_0 keyspace was bascially created by CLI. It is one of the keyspaces 
created by our automated testsuite (it seems someone connected his IDE to the D 
system, so the schema was created there).

One thing that is special: After creation, the tests modify the keyspace via 
the thrift API:
{code}
// update gc grace seconds to 0
final Cluster cluster = keyspace.getCluster();
final String keyspaceName = 
keyspace.getKeyspace().getKeyspaceName();
final KeyspaceDefinition keyspaceDefinition = 
cluster.describeKeyspace(keyspaceName);
final List cfDefs = 
keyspaceDefinition.getCfDefs();
for (final ColumnFamilyDefinition cfDef : cfDefs)
{
cfDef.setGcGraceSeconds(0);
cfDef.setMemtableFlushAfterMins(Integer.MAX_VALUE);
cfDef.setReadRepairChance(0.0);
cfDef.setKeyCacheSavePeriodInSeconds(Integer.MAX_VALUE);
cluster.updateColumnFamily(cfDef);
}
{code}


> Upgrade from 2.2.5 to 3.0.3 Fails with AssertionError
> -
>
> Key: CASSANDRA-11315
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11315
> Project: Cassandra
>  Issue Type: Bug
> Environment: Ubuntu 14.04, Oracle Java 8, Apache Cassandra 2.2.5 -> 
> 3.0.3
>Reporter: Dominik Keil
>Assignee: Aleksey Yeschenko
>Priority: Blocker
> Fix For: 3.0.x, 3.x
>
>
> Hi,
> when trying to upgrade our development cluster from C* 2.2.5 to 3.0.3 
> Cassandra fails during startup.
> Here's the relevant log snippet:
> {noformat}
> [...]
> INFO  [main] 2016-03-08 11:42:01,291 ColumnFamilyStore.java:381 - 
> Initializing system.schema_triggers
> INFO  [main] 2016-03-08 11:42:01,302 ColumnFamilyStore.java:381 - 
> Initializing system.schema_usertypes
> INFO  [main] 2016-03-08 11:42:01,313 ColumnFamilyStore.java:381 - 
> Initializing system.schema_functions
> INFO  [main] 2016-03-08 11:42:01,324 ColumnFamilyStore.java:381 - 
> Initializing system.schema_aggregates
> INFO  [main] 2016-03-08 11:42:01,576 SystemKeyspace.java:1284 - Detected 
> version upgrade from 2.2.5 to 3.0.3, snapshotting system keyspace
> WARN  [main] 2016-03-08 11:42:01,911 CompressionParams.java:382 - The 
> sstable_compression option has been deprecated. You should use class instead
> WARN  [main] 2016-03-08 11:42:01,959 CompressionParams.java:333 - The 
> chunk_length_kb option has been deprecated. You should use chunk_length_in_kb 
> instead
> ERROR [main] 2016-03-08 11:42:02,638 CassandraDaemon.java:692 - Exception 
> encountered during startup
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.db.CompactTables.getCompactValueColumn(CompactTables.java:90)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.config.CFMetaData.rebuild(CFMetaData.java:315) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:291) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at org.apache.cassandra.config.CFMetaData.create(CFMetaData.java:367) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.decodeTableMetadata(LegacySchemaMigrator.java:337)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTableMetadata(LegacySchemaMigrator.java:273)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTable(LegacySchemaMigrator.java:244)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readTables$227(LegacySchemaMigrator.java:237)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_74]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTables(LegacySchemaMigrator.java:237)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readKeyspace(LegacySchemaMigrator.java:186)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readSchema$224(LegacySchemaMigrator.java:177)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_74]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readSchema(LegacySchemaMigrator.java:177)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.migrate(LegacySchemaMigrator.java:77)
>  

[jira] [Commented] (CASSANDRA-11315) Upgrade from 2.2.5 to 3.0.3 Fails with AssertionError

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-11315:
---

The issue is ultimately that your tables in 'Auth_0' keyspace all have 
{{is_dense}} set to {{true}} in {{system.schema_columnfamilies}}, while it 
should be false for all of them.

How and when did you create that keyspace with the tables in the first place? 
Were you using cli or cqlsh? What version of C* did that first happen in?

> Upgrade from 2.2.5 to 3.0.3 Fails with AssertionError
> -
>
> Key: CASSANDRA-11315
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11315
> Project: Cassandra
>  Issue Type: Bug
> Environment: Ubuntu 14.04, Oracle Java 8, Apache Cassandra 2.2.5 -> 
> 3.0.3
>Reporter: Dominik Keil
>Assignee: Aleksey Yeschenko
>Priority: Blocker
> Fix For: 3.0.x, 3.x
>
>
> Hi,
> when trying to upgrade our development cluster from C* 2.2.5 to 3.0.3 
> Cassandra fails during startup.
> Here's the relevant log snippet:
> {noformat}
> [...]
> INFO  [main] 2016-03-08 11:42:01,291 ColumnFamilyStore.java:381 - 
> Initializing system.schema_triggers
> INFO  [main] 2016-03-08 11:42:01,302 ColumnFamilyStore.java:381 - 
> Initializing system.schema_usertypes
> INFO  [main] 2016-03-08 11:42:01,313 ColumnFamilyStore.java:381 - 
> Initializing system.schema_functions
> INFO  [main] 2016-03-08 11:42:01,324 ColumnFamilyStore.java:381 - 
> Initializing system.schema_aggregates
> INFO  [main] 2016-03-08 11:42:01,576 SystemKeyspace.java:1284 - Detected 
> version upgrade from 2.2.5 to 3.0.3, snapshotting system keyspace
> WARN  [main] 2016-03-08 11:42:01,911 CompressionParams.java:382 - The 
> sstable_compression option has been deprecated. You should use class instead
> WARN  [main] 2016-03-08 11:42:01,959 CompressionParams.java:333 - The 
> chunk_length_kb option has been deprecated. You should use chunk_length_in_kb 
> instead
> ERROR [main] 2016-03-08 11:42:02,638 CassandraDaemon.java:692 - Exception 
> encountered during startup
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.db.CompactTables.getCompactValueColumn(CompactTables.java:90)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.config.CFMetaData.rebuild(CFMetaData.java:315) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:291) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at org.apache.cassandra.config.CFMetaData.create(CFMetaData.java:367) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.decodeTableMetadata(LegacySchemaMigrator.java:337)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTableMetadata(LegacySchemaMigrator.java:273)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTable(LegacySchemaMigrator.java:244)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readTables$227(LegacySchemaMigrator.java:237)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_74]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTables(LegacySchemaMigrator.java:237)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readKeyspace(LegacySchemaMigrator.java:186)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readSchema$224(LegacySchemaMigrator.java:177)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_74]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readSchema(LegacySchemaMigrator.java:177)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.migrate(LegacySchemaMigrator.java:77)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:223) 
> [apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:551)
>  [apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:679) 
> [apache-cassandra-3.0.3.jar:3.0.3]
> {noformat}



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

[jira] [Created] (CASSANDRA-11418) Nodetool status should reflect hibernate/replacing states

[Joel Knighton (JIRA)]

Joel Knighton created CASSANDRA-11418:
-

 Summary: Nodetool status should reflect hibernate/replacing states
 Key: CASSANDRA-11418
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11418
 Project: Cassandra
  Issue Type: Improvement
  Components: Observability, Tools
Reporter: Joel Knighton
Priority: Minor
 Fix For: 3.x


Currently, the four options for state in nodetool status are 
joining/leaving/moving/normal.

Joining nodes are determined based on bootstrap tokens, leaving nodes are based 
on leaving endpoints in TokenMetadata, moving nodes are based on moving 
endpoints in TokenMetadata.

This means that a node will appear in normal state when going through a 
bootstrap with flag replace_address, which can be confusing to operators.

We should add another state for hibernation/replacing to make this visible. 
This will require a way to get a list of all hibernating endpoints.



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

[jira] [Commented] (CASSANDRA-10091) Integrated JMX authn & authz

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-10091:
-

[~tjake],  after some spelunking in the RMI implementation, it seems the 
warning you saw was caused by the overzealous assert that I removed in 
[4f28d1e|https://github.com/beobal/cassandra/commit/4f28d1e4c7d18e47d9edb0908507666b639a39f7].
 When an idle connection times (by default after 12ms), the server tries to 
unexport it, but because the custom exporter barfed on the assert, it never was 
exported in the first place. I experimented with lowering the timeout & adding 
back the assert & can confirm the warn re-appeared, so removing that assert is 
the solution.

Regarding the extra dtests I mentioned, it's actually a bit trickier than I 
first thought. The reason being that the way dtests interact with JMX is by 
attaching the custom Jolokia agent to the running ccm node, which provides its 
own JMX connector server and so bypasses all the built in auth stuff. Jolokia 
can run in proxy mode, whereby it binds to the JMX connector provided by the 
server, but that requires a servlet container to host the HTTP endpoint. As an 
alternative, I've added some more functional tests in 
{{o.a.c.auth.jmx.JMXAuthTest}}, while not covering everything they do exercise 
a real RMI connection so are probably at least somewhat useful.

I've also removed the duplication in {{CassandraLoginModule}} and updated 
NEWS.txt.

dtest pull request [here|https://github.com/riptano/cassandra-dtest/pull/887]


> Integrated JMX authn & authz
> 
>
> Key: CASSANDRA-10091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10091
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Jan Karlsson
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.x
>
>
> It would be useful to authenticate with JMX through Cassandra's internal 
> authentication. This would reduce the overhead of keeping passwords in files 
> on the machine and would consolidate passwords to one location. It would also 
> allow the possibility to handle JMX permissions in Cassandra.
> It could be done by creating our own JMX server and setting custom classes 
> for the authenticator and authorizer. We could then add some parameters where 
> the user could specify what authenticator and authorizer to use in case they 
> want to make their own.
> This could also be done by creating a premain method which creates a jmx 
> server. This would give us the feature without changing the Cassandra code 
> itself. However I believe this would be a good feature to have in Cassandra.
> I am currently working on a solution which creates a JMX server and uses a 
> custom authenticator and authorizer. It is currently build as a premain, 
> however it would be great if we could put this in Cassandra instead.



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

[jira] [Commented] (CASSANDRA-11412) Many sstablescanners opened during repair

[Marcus Olsson (JIRA)]

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

Marcus Olsson commented on CASSANDRA-11412:
---

Hmm.. yes that seems to be a bug. Either we could implement hashCode() and 
equals() on all scanners or we could change (or add a separate) 
{{AbstractCompactionStrategy.getScanners()}} to take a collection of 
{{Range}}. I think the second option would be preferable since we would 
only call {{SSTableReader.getScanner()}} once for each sstable. There is 
already a {{getScanner()}} method that takes [a collection of 
ranges|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java#L1761]
 in SSTableReader. This would also make more sense with LCS since as it is now 
even if we check for equality the LeveledScanner might not always be equal for 
all ranges and create one scanner per range either way.

This would still make it so that we have one scanner per sstable opened at the 
same time though(which would pretty much be the same as pre-CASSANDRA-5220), 
except for when using leveled compaction. So it might be good to only open the 
scanners when needed depending on how many sstables we have. The implementation 
for that would probably be a bit more complex than for LCS since in 
LeveledScanner we work with the assumption that all sstables in a level are 
non-overlapping so we only open one scanner at a time. I think the partition 
iteration for overlapping sstables could be done as:
# Sort all the sstables based on tokens
# Open the first sstable scanner
# Read/merge first partition from all open scanners (and close exhausted 
scanners) and keep the first partition
# Compare the partition to the non-open sstables to see if they may contain a 
partition before or at the same token as the previously read partition, open a 
scanner if that's the case and then read the first partition
# Compare/merge all current partitions and return the first
# Continue at step 3 until all sstables are read

Unless I'm over-thinking this.

> Many sstablescanners opened during repair
> -
>
> Key: CASSANDRA-11412
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11412
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>
> Since CASSANDRA-5220 we open [one sstablescanner per range per 
> sstable|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/compaction/CompactionStrategyManager.java#L374].
>  If compaction gets behind and you are running vnodes with 256 tokens and 
> RF3, this could become a problem (ie, {{768 * number of sstables}} scanners)
> We could probably refactor this similar to the way we handle scanners with 
> LCS - only open the scanner once we need it



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

[jira] [Updated] (CASSANDRA-10643) Implement compaction for a specific token range

[Richard Low (JIRA)]

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

Richard Low updated CASSANDRA-10643:

Reviewer: Jason Brown
  Status: Patch Available  (was: Open)

> Implement compaction for a specific token range
> ---
>
> Key: CASSANDRA-10643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10643
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Vishy Kasar
>Assignee: Vishy Kasar
> Attachments: 10643-trunk-REV01.txt
>
>
> We see repeated cases in production (using LCS) where small number of users 
> generate a large number repeated updates or tombstones. Reading data of such 
> users brings in large amounts of data in to java process. Apart from the read 
> itself being slow for the user, the excessive GC affects other users as well. 
> Our solution so far is to move from LCS to SCS and back. This takes long and 
> is an over kill if the number of outliers is small. For such cases, we can 
> implement the point compaction of a token range. We make the nodetool compact 
> take a starting and ending token range and compact all the SSTables that fall 
> with in that range. We can refuse to compact if the number of sstables is 
> beyond a max_limit.
> Example: 
> nodetool -st 3948291562518219268 -et 3948291562518219269 compact keyspace 
> table



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

[jira] [Commented] (CASSANDRA-11416) No longer able to load backups into new cluster if there was a dropped column

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan commented on CASSANDRA-11416:
-

Yes, you can work around it by replaying your original schema and all changes 
in the new cluster.  But that is a pain for automated backups, so we should 
change this so it doesn't crash out.  A snapshot+describe output should be 
enough to restore a table.

> No longer able to load backups into new cluster if there was a dropped column
> -
>
> Key: CASSANDRA-11416
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11416
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeremiah Jordan
> Fix For: 3.0.x, 3.x
>
>
> The following change to the sstableloader test works in 2.1/2.2 but fails in 
> 3.0+
> https://github.com/JeremiahDJordan/cassandra-dtest/commit/7dc66efb8d24239f0a488ec5a613240531aeb7db
> {code}
> CREATE TABLE test_drop (key text PRIMARY KEY, c1 text, c2 text, c3 text, c4 
> text)
> ...insert data...
> ALTER TABLE test_drop DROP c4
> ...insert more data...
> {code}
> Make a snapshot and save off a describe to backup table test_drop.
> Decide to restore the snapshot to a new cluster.   First restore the schema 
> from describe. (column c4 isn't there)
> {code}
> CREATE TABLE test_drop (key text PRIMARY KEY, c1 text, c2 text, c3 text)
> {code}
> sstableload the snapshot data.
> Works in 2.1/2.2.  Fails in 3.0+ with:
> {code}
> java.lang.RuntimeException: Unknown column c4 during deserialization
> java.lang.RuntimeException: Failed to list files in 
> /var/folders/t4/rlc2b6450qbg92762l9l4mt8gn/T/dtest-3eKv_g/test/node1/data1_copy/ks/drop_one-bcef5280f11b11e5825a43f0253f18b5
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:53)
>   at 
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:544)
>   at 
> org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:76)
>   at 
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:165)
>   at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:104)
> Caused by: java.lang.RuntimeException: Unknown column c4 during 
> deserialization
>   at 
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:331)
>   at 
> org.apache.cassandra.io.sstable.format.SSTableReader.openForBatch(SSTableReader.java:430)
>   at 
> org.apache.cassandra.io.sstable.SSTableLoader.lambda$openSSTables$193(SSTableLoader.java:121)
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.lambda$innerList$184(LogAwareFileLister.java:75)
>   at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
>   at 
> java.util.TreeMap$EntrySpliterator.forEachRemaining(TreeMap.java:2965)
>   at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
>   at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
>   at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
>   at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>   at 
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.innerList(LogAwareFileLister.java:77)
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:49)
>   ... 4 more
> {code}



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

[jira] [Created] (CASSANDRA-11417) dtest failure in replication_test.SnitchConfigurationUpdateTest.test_rf_expand_gossiping_property_file_snitch_multi_dc

[Philip Thompson (JIRA)]

Philip Thompson created CASSANDRA-11417:
---

 Summary: dtest failure in 
replication_test.SnitchConfigurationUpdateTest.test_rf_expand_gossiping_property_file_snitch_multi_dc
 Key: CASSANDRA-11417
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11417
 Project: Cassandra
  Issue Type: Test
Reporter: Philip Thompson
Assignee: DS Test Eng


Error is 
{code}
Unknown table 'rf_test' in keyspace 'testing'
{code}

Just seems like a schema disagreement problem. Presumably we just need to have 
the driver block until schema agreement.

example failure:

http://cassci.datastax.com/job/trunk_offheap_dtest/90/testReport/replication_test/SnitchConfigurationUpdateTest/test_rf_expand_gossiping_property_file_snitch_multi_dc

Failed on CassCI build trunk_offheap_dtest #90



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

[jira] [Updated] (CASSANDRA-10643) Implement compaction for a specific token range

[Vishy Kasar (JIRA)]

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

Vishy Kasar updated CASSANDRA-10643:

Attachment: 10643-trunk-REV01.txt

> Implement compaction for a specific token range
> ---
>
> Key: CASSANDRA-10643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10643
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Vishy Kasar
>Assignee: Vishy Kasar
> Attachments: 10643-trunk-REV01.txt
>
>
> We see repeated cases in production (using LCS) where small number of users 
> generate a large number repeated updates or tombstones. Reading data of such 
> users brings in large amounts of data in to java process. Apart from the read 
> itself being slow for the user, the excessive GC affects other users as well. 
> Our solution so far is to move from LCS to SCS and back. This takes long and 
> is an over kill if the number of outliers is small. For such cases, we can 
> implement the point compaction of a token range. We make the nodetool compact 
> take a starting and ending token range and compact all the SSTables that fall 
> with in that range. We can refuse to compact if the number of sstables is 
> beyond a max_limit.
> Example: 
> nodetool -st 3948291562518219268 -et 3948291562518219269 compact keyspace 
> table



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

[jira] [Commented] (CASSANDRA-11416) No longer able to load backups into new cluster if there was a dropped column

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-11416:
---

I'm assuming you can work around it, at least for now, by adding and dropping 
those columns manually in the new cluster?

> No longer able to load backups into new cluster if there was a dropped column
> -
>
> Key: CASSANDRA-11416
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11416
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeremiah Jordan
> Fix For: 3.0.x, 3.x
>
>
> The following change to the sstableloader test works in 2.1/2.2 but fails in 
> 3.0+
> https://github.com/JeremiahDJordan/cassandra-dtest/commit/7dc66efb8d24239f0a488ec5a613240531aeb7db
> {code}
> CREATE TABLE test_drop (key text PRIMARY KEY, c1 text, c2 text, c3 text, c4 
> text)
> ...insert data...
> ALTER TABLE test_drop DROP c4
> ...insert more data...
> {code}
> Make a snapshot and save off a describe to backup table test_drop.
> Decide to restore the snapshot to a new cluster.   First restore the schema 
> from describe. (column c4 isn't there)
> {code}
> CREATE TABLE test_drop (key text PRIMARY KEY, c1 text, c2 text, c3 text)
> {code}
> sstableload the snapshot data.
> Works in 2.1/2.2.  Fails in 3.0+ with:
> {code}
> java.lang.RuntimeException: Unknown column c4 during deserialization
> java.lang.RuntimeException: Failed to list files in 
> /var/folders/t4/rlc2b6450qbg92762l9l4mt8gn/T/dtest-3eKv_g/test/node1/data1_copy/ks/drop_one-bcef5280f11b11e5825a43f0253f18b5
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:53)
>   at 
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:544)
>   at 
> org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:76)
>   at 
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:165)
>   at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:104)
> Caused by: java.lang.RuntimeException: Unknown column c4 during 
> deserialization
>   at 
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:331)
>   at 
> org.apache.cassandra.io.sstable.format.SSTableReader.openForBatch(SSTableReader.java:430)
>   at 
> org.apache.cassandra.io.sstable.SSTableLoader.lambda$openSSTables$193(SSTableLoader.java:121)
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.lambda$innerList$184(LogAwareFileLister.java:75)
>   at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
>   at 
> java.util.TreeMap$EntrySpliterator.forEachRemaining(TreeMap.java:2965)
>   at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
>   at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
>   at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
>   at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>   at 
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.innerList(LogAwareFileLister.java:77)
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:49)
>   ... 4 more
> {code}



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

[jira] [Updated] (CASSANDRA-11225) dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-11225:

Assignee: DS Test Eng  (was: Philip Thompson)

> dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters
> 
>
> Key: CASSANDRA-11225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11225
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: DS Test Eng
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/209/testReport/consistency_test/TestAccuracy/test_simple_strategy_counters
> Failed on CassCI build cassandra-2.1_novnode_dtest #209
> error: "AssertionError: Failed to read value from sufficient number of nodes, 
> required 2 but got 1 - [574, 2]"



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

[jira] [Commented] (CASSANDRA-11225) dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters

[Philip Thompson (JIRA)]

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

Philip Thompson commented on CASSANDRA-11225:
-

I ran this 300 times:
http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/36/

> dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters
> 
>
> Key: CASSANDRA-11225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11225
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Philip Thompson
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/209/testReport/consistency_test/TestAccuracy/test_simple_strategy_counters
> Failed on CassCI build cassandra-2.1_novnode_dtest #209
> error: "AssertionError: Failed to read value from sufficient number of nodes, 
> required 2 but got 1 - [574, 2]"



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

[jira] [Resolved] (CASSANDRA-11318) dtest failure in replication_test.SnitchConfigurationUpdateTest.test_rf_collapse_property_file_snitch

[Philip Thompson (JIRA)]

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

Philip Thompson resolved CASSANDRA-11318.
-
Resolution: Cannot Reproduce

Did not show up in 300 separate runs:
http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/34/

Closing as Cannot Repro.

> dtest failure in 
> replication_test.SnitchConfigurationUpdateTest.test_rf_collapse_property_file_snitch
> -
>
> Key: CASSANDRA-11318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11318
> Project: Cassandra
>  Issue Type: Test
>Reporter: Jim Witschey
>Assignee: Philip Thompson
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/592/testReport/replication_test/SnitchConfigurationUpdateTest/test_rf_collapse_property_file_snitch
> Failed on CassCI build cassandra-3.0_dtest #592
> The test failed on this line:
> https://github.com/riptano/cassandra-dtest/blob/7a331cda807c96ae107b58017854f0e57996d8c3/replication_test.py#L567
> So, a node's expected move from one rack to another doesn't happen in the 
> allotted timeout time. This is the only flap I've seen. Maybe the thing to do 
> here is increase the timeout and keep an eye on it?



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

[jira] [Resolved] (CASSANDRA-11362) dtest failure in snitch_test.TestGossipingPropertyFileSnitch.test_prefer_local_reconnect_on_listen_address

[Philip Thompson (JIRA)]

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

Philip Thompson resolved CASSANDRA-11362.
-
Resolution: Cannot Reproduce

http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/33/
Did not show up over 300 separate runs. Closing as Cannot Repro

> dtest failure in 
> snitch_test.TestGossipingPropertyFileSnitch.test_prefer_local_reconnect_on_listen_address
> --
>
> Key: CASSANDRA-11362
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11362
> Project: Cassandra
>  Issue Type: Test
>Reporter: Jim Witschey
>Assignee: Philip Thompson
>  Labels: dtest
>
> This is a weird one:
> http://cassci.datastax.com/job/cassandra-2.2_dtest/540/testReport/snitch_test/TestGossipingPropertyFileSnitch/test_prefer_local_reconnect_on_listen_address
> Not sure why the keyspace isn't getting created. At first I thought it was 
> expecting {{keyspace1}} but finding {{Keyspace1}}, but then the test would 
> just never pass.



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

[jira] [Commented] (CASSANDRA-11179) Parallel cleanup can lead to disk space exhaustion

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-11179:


Looks good. Just a couple of comments:
- Would be nice to add a comment to {{parallelAllSSTableOperation}} explaining 
that jobs = 0 means using all compactor threads, so that we remember to 
propagate that to our argument explanations.
- Also, it's not clear what would happen if you specified a jobs higher than 
the number of concurrent compactors. The expectation is probably that it would 
override that selection, so either a warning or the inability to do that would 
be helpful.

> Parallel cleanup can lead to disk space exhaustion
> --
>
> Key: CASSANDRA-11179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11179
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction, Tools
>Reporter: Tyler Hobbs
>Assignee: Marcus Eriksson
>  Labels: doc-impacting
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> In CASSANDRA-5547, we made cleanup (among other things) run in parallel 
> across multiple sstables.  There have been reports on IRC of this leading to 
> disk space exhaustion, because multiple sstables are (almost entirely) 
> rewritten at the same time.  This seems particularly problematic because 
> cleanup is frequently run after a cluster is expanded due to low disk space.
> I'm not really familiar with how we perform free disk space checks now, but 
> it sounds like we can make some improvements here.  It would be good to 
> reduce the concurrency of cleanup operations if there isn't enough free disk 
> space to support this.



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

[jira] [Commented] (CASSANDRA-11349) MerkleTree mismatch when multiple range tombstones exists for the same partition and interval

[Fabien Rousseau (JIRA)]

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

Fabien Rousseau commented on CASSANDRA-11349:
-

Nice patch.

I will be able to test it on a dev environment either this week or at the 
beginning of next week.

There is still one case not covered (though not sure it can happen).
Suppose that in SSTable 1, there is a range tombstone covering the columns "a" 
through "g" at time t1, and in SSTable 2, there is a range tombstone covering 
the columns "c" through "d" at time t2.
If those two SSTable are merged (for example on another replica), it will be 
split in 3 range tombstones in one SSTable (one range tombstone "a" -> "b" at 
t1, "c" -> "d" at t2, "e" -> "f" at t1).
Computing the merkle tree for those two hosts will still be different (not the 
same range tombstones).

As said above, not sure if it can happen, and anyway, this patch is a good 
improvement and probably fits 99% cases.



> MerkleTree mismatch when multiple range tombstones exists for the same 
> partition and interval
> -
>
> Key: CASSANDRA-11349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11349
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Fabien Rousseau
>Assignee: Stefan Podkowinski
>  Labels: repair
> Fix For: 2.1.x, 2.2.x
>
> Attachments: 11349-2.1.patch
>
>
> We observed that repair, for some of our clusters, streamed a lot of data and 
> many partitions were "out of sync".
> Moreover, the read repair mismatch ratio is around 3% on those clusters, 
> which is really high.
> After investigation, it appears that, if two range tombstones exists for a 
> partition for the same range/interval, they're both included in the merkle 
> tree computation.
> But, if for some reason, on another node, the two range tombstones were 
> already compacted into a single range tombstone, this will result in a merkle 
> tree difference.
> Currently, this is clearly bad because MerkleTree differences are dependent 
> on compactions (and if a partition is deleted and created multiple times, the 
> only way to ensure that repair "works correctly"/"don't overstream data" is 
> to major compact before each repair... which is not really feasible).
> Below is a list of steps allowing to easily reproduce this case:
> {noformat}
> ccm create test -v 2.1.13 -n 2 -s
> ccm node1 cqlsh
> CREATE KEYSPACE test_rt WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 2};
> USE test_rt;
> CREATE TABLE IF NOT EXISTS table1 (
> c1 text,
> c2 text,
> c3 float,
> c4 float,
> PRIMARY KEY ((c1), c2)
> );
> INSERT INTO table1 (c1, c2, c3, c4) VALUES ( 'a', 'b', 1, 2);
> DELETE FROM table1 WHERE c1 = 'a' AND c2 = 'b';
> ctrl ^d
> # now flush only one of the two nodes
> ccm node1 flush 
> ccm node1 cqlsh
> USE test_rt;
> INSERT INTO table1 (c1, c2, c3, c4) VALUES ( 'a', 'b', 1, 3);
> DELETE FROM table1 WHERE c1 = 'a' AND c2 = 'b';
> ctrl ^d
> ccm node1 repair
> # now grep the log and observe that there was some inconstencies detected 
> between nodes (while it shouldn't have detected any)
> ccm node1 showlog | grep "out of sync"
> {noformat}
> Consequences of this are a costly repair, accumulating many small SSTables 
> (up to thousands for a rather short period of time when using VNodes, the 
> time for compaction to absorb those small files), but also an increased size 
> on disk.



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

[jira] [Updated] (CASSANDRA-11415) dtest failure in jmx_test.TestJMX.cfhistograms_test

[Yuki Morishita (JIRA)]

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

Yuki Morishita updated CASSANDRA-11415:
---
Issue Type: Bug  (was: Test)

> dtest failure in jmx_test.TestJMX.cfhistograms_test
> ---
>
> Key: CASSANDRA-11415
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11415
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Yuki Morishita
>  Labels: dtest
> Fix For: 2.1.x
>
>
> We are seeing the following stacktrace when running nodetool cfhistograms
> {code}
> java.lang.AssertionError
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.(EstimatedHistogram.java:66)
>   at 
> org.apache.cassandra.tools.NodeProbe.metricPercentilesAsArray(NodeProbe.java:1260)
>   at 
> org.apache.cassandra.tools.NodeTool$CfHistograms.execute(NodeTool.java:1109)
>   at 
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:292)
>   at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:206)
> {code}
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/437/testReport/jmx_test/TestJMX/cfhistograms_test
> Failed on CassCI build cassandra-2.1_dtest #437
> This doesn't appear to be flaky. I can repro locally. It seems like a product 
> issue, but if someone could confirm if it happens out of the test, that would 
> be great.



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

[jira] [Assigned] (CASSANDRA-11415) dtest failure in jmx_test.TestJMX.cfhistograms_test

[Yuki Morishita (JIRA)]

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

Yuki Morishita reassigned CASSANDRA-11415:
--

Assignee: Yuki Morishita  (was: DS Test Eng)

> dtest failure in jmx_test.TestJMX.cfhistograms_test
> ---
>
> Key: CASSANDRA-11415
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11415
> Project: Cassandra
>  Issue Type: Test
>Reporter: Philip Thompson
>Assignee: Yuki Morishita
>  Labels: dtest
> Fix For: 2.1.x
>
>
> We are seeing the following stacktrace when running nodetool cfhistograms
> {code}
> java.lang.AssertionError
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.(EstimatedHistogram.java:66)
>   at 
> org.apache.cassandra.tools.NodeProbe.metricPercentilesAsArray(NodeProbe.java:1260)
>   at 
> org.apache.cassandra.tools.NodeTool$CfHistograms.execute(NodeTool.java:1109)
>   at 
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:292)
>   at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:206)
> {code}
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/437/testReport/jmx_test/TestJMX/cfhistograms_test
> Failed on CassCI build cassandra-2.1_dtest #437
> This doesn't appear to be flaky. I can repro locally. It seems like a product 
> issue, but if someone could confirm if it happens out of the test, that would 
> be great.



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

[jira] [Commented] (CASSANDRA-11415) dtest failure in jmx_test.TestJMX.cfhistograms_test

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-11415:


I think it is from CASSANDRA-9598 change. It added '-ea' to the script.
We need CASSANDRA-10859 backported to cassandra-2.1 and maybe 2.2.

> dtest failure in jmx_test.TestJMX.cfhistograms_test
> ---
>
> Key: CASSANDRA-11415
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11415
> Project: Cassandra
>  Issue Type: Test
>Reporter: Philip Thompson
>Assignee: DS Test Eng
>  Labels: dtest
> Fix For: 2.1.x
>
>
> We are seeing the following stacktrace when running nodetool cfhistograms
> {code}
> java.lang.AssertionError
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.(EstimatedHistogram.java:66)
>   at 
> org.apache.cassandra.tools.NodeProbe.metricPercentilesAsArray(NodeProbe.java:1260)
>   at 
> org.apache.cassandra.tools.NodeTool$CfHistograms.execute(NodeTool.java:1109)
>   at 
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:292)
>   at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:206)
> {code}
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/437/testReport/jmx_test/TestJMX/cfhistograms_test
> Failed on CassCI build cassandra-2.1_dtest #437
> This doesn't appear to be flaky. I can repro locally. It seems like a product 
> issue, but if someone could confirm if it happens out of the test, that would 
> be great.



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

[jira] [Updated] (CASSANDRA-11416) No longer able to load backups into new cluster if there was a dropped column

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan updated CASSANDRA-11416:

Summary: No longer able to load backups into new cluster if there was a 
dropped column  (was: No longer able to load old backups into new cluster if 
there was a dropped column)

> No longer able to load backups into new cluster if there was a dropped column
> -
>
> Key: CASSANDRA-11416
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11416
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeremiah Jordan
> Fix For: 3.0.x, 3.x
>
>
> The following change to the sstableloader test works in 2.1/2.2 but fails in 
> 3.0+
> https://github.com/JeremiahDJordan/cassandra-dtest/commit/7dc66efb8d24239f0a488ec5a613240531aeb7db
> {code}
> CREATE TABLE test_drop (key text PRIMARY KEY, c1 text, c2 text, c3 text, c4 
> text)
> ...insert data...
> ALTER TABLE test_drop DROP c4
> ...insert more data...
> {code}
> Make a snapshot and save off a describe to backup table test_drop.
> Decide to restore the snapshot to a new cluster.   First restore the schema 
> from describe. (column c4 isn't there)
> {code}
> CREATE TABLE test_drop (key text PRIMARY KEY, c1 text, c2 text, c3 text)
> {code}
> sstableload the snapshot data.
> Works in 2.1/2.2.  Fails in 3.0+ with:
> {code}
> java.lang.RuntimeException: Unknown column c4 during deserialization
> java.lang.RuntimeException: Failed to list files in 
> /var/folders/t4/rlc2b6450qbg92762l9l4mt8gn/T/dtest-3eKv_g/test/node1/data1_copy/ks/drop_one-bcef5280f11b11e5825a43f0253f18b5
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:53)
>   at 
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:544)
>   at 
> org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:76)
>   at 
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:165)
>   at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:104)
> Caused by: java.lang.RuntimeException: Unknown column c4 during 
> deserialization
>   at 
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:331)
>   at 
> org.apache.cassandra.io.sstable.format.SSTableReader.openForBatch(SSTableReader.java:430)
>   at 
> org.apache.cassandra.io.sstable.SSTableLoader.lambda$openSSTables$193(SSTableLoader.java:121)
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.lambda$innerList$184(LogAwareFileLister.java:75)
>   at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
>   at 
> java.util.TreeMap$EntrySpliterator.forEachRemaining(TreeMap.java:2965)
>   at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
>   at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
>   at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
>   at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>   at 
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.innerList(LogAwareFileLister.java:77)
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:49)
>   ... 4 more
> {code}



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

[jira] [Created] (CASSANDRA-11416) No longer able to load old backups into new cluster if there was a dropped column

[Jeremiah Jordan (JIRA)]

Jeremiah Jordan created CASSANDRA-11416:
---

 Summary: No longer able to load old backups into new cluster if 
there was a dropped column
 Key: CASSANDRA-11416
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11416
 Project: Cassandra
  Issue Type: Bug
Reporter: Jeremiah Jordan


The following change to the sstableloader test works in 2.1/2.2 but fails in 
3.0+

https://github.com/JeremiahDJordan/cassandra-dtest/commit/7dc66efb8d24239f0a488ec5a613240531aeb7db

{code}
CREATE TABLE test_drop (key text PRIMARY KEY, c1 text, c2 text, c3 text, c4 
text)
...insert data...
ALTER TABLE test_drop DROP c4
...insert more data...
{code}

Make a snapshot and save off a describe to backup table test_drop.

Decide to restore the snapshot to a new cluster.   First restore the schema 
from describe. (column c4 isn't there)

{code}
CREATE TABLE test_drop (key text PRIMARY KEY, c1 text, c2 text, c3 text)
{code}

sstableload the snapshot data.

Works in 2.1/2.2.  Fails in 3.0+ with:

{code}
java.lang.RuntimeException: Unknown column c4 during deserialization
java.lang.RuntimeException: Failed to list files in 
/var/folders/t4/rlc2b6450qbg92762l9l4mt8gn/T/dtest-3eKv_g/test/node1/data1_copy/ks/drop_one-bcef5280f11b11e5825a43f0253f18b5
at 
org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:53)
at 
org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:544)
at 
org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:76)
at 
org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:165)
at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:104)
Caused by: java.lang.RuntimeException: Unknown column c4 during deserialization
at 
org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:331)
at 
org.apache.cassandra.io.sstable.format.SSTableReader.openForBatch(SSTableReader.java:430)
at 
org.apache.cassandra.io.sstable.SSTableLoader.lambda$openSSTables$193(SSTableLoader.java:121)
at 
org.apache.cassandra.db.lifecycle.LogAwareFileLister.lambda$innerList$184(LogAwareFileLister.java:75)
at 
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
at 
java.util.TreeMap$EntrySpliterator.forEachRemaining(TreeMap.java:2965)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at 
java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at 
java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at 
org.apache.cassandra.db.lifecycle.LogAwareFileLister.innerList(LogAwareFileLister.java:77)
at 
org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:49)
... 4 more
{code}



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

[jira] [Comment Edited] (CASSANDRA-11414) dtest failure in bootstrap_test.TestBootstrap.resumable_bootstrap_test

[Paulo Motta (JIRA)]

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

Paulo Motta edited comment on CASSANDRA-11414 at 3/23/16 5:35 PM:
--

I'd say changing the stress write CL to TWO would fix this (we must keep the 
read CL at ONE though)


was (Author: pauloricardomg):
I'd say changing the stress read and/or write CL to QUORUM would fix this.

> dtest failure in bootstrap_test.TestBootstrap.resumable_bootstrap_test
> --
>
> Key: CASSANDRA-11414
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11414
> Project: Cassandra
>  Issue Type: Test
>  Components: Testing
>Reporter: Philip Thompson
>Assignee: DS Test Eng
>  Labels: dtest
>
> Stress is failing to read back all data. We can see this output from the 
> stress read
> {code}
> java.io.IOException: Operation x0 on key(s) [314c384f304f4c325030]: Data 
> returned was not validated
>   at org.apache.cassandra.stress.Operation.error(Operation.java:138)
>   at 
> org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:116)
>   at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:101)
>   at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:109)
>   at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:261)
>   at 
> org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:327)
> java.io.IOException: Operation x0 on key(s) [33383438363931353131]: Data 
> returned was not validated
>   at org.apache.cassandra.stress.Operation.error(Operation.java:138)
>   at 
> org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:116)
>   at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:101)
>   at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:109)
>   at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:261)
>   at 
> org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:327)
> FAILURE
> {code}
> Started happening with build 1075. Does not appear flaky on CI.
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1076/testReport/bootstrap_test/TestBootstrap/resumable_bootstrap_test
> Failed on CassCI build trunk_dtest #1076



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

[jira] [Updated] (CASSANDRA-11416) No longer able to load old backups into new cluster if there was a dropped column

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan updated CASSANDRA-11416:

Fix Version/s: 3.x
   3.0.x

> No longer able to load old backups into new cluster if there was a dropped 
> column
> -
>
> Key: CASSANDRA-11416
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11416
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeremiah Jordan
> Fix For: 3.0.x, 3.x
>
>
> The following change to the sstableloader test works in 2.1/2.2 but fails in 
> 3.0+
> https://github.com/JeremiahDJordan/cassandra-dtest/commit/7dc66efb8d24239f0a488ec5a613240531aeb7db
> {code}
> CREATE TABLE test_drop (key text PRIMARY KEY, c1 text, c2 text, c3 text, c4 
> text)
> ...insert data...
> ALTER TABLE test_drop DROP c4
> ...insert more data...
> {code}
> Make a snapshot and save off a describe to backup table test_drop.
> Decide to restore the snapshot to a new cluster.   First restore the schema 
> from describe. (column c4 isn't there)
> {code}
> CREATE TABLE test_drop (key text PRIMARY KEY, c1 text, c2 text, c3 text)
> {code}
> sstableload the snapshot data.
> Works in 2.1/2.2.  Fails in 3.0+ with:
> {code}
> java.lang.RuntimeException: Unknown column c4 during deserialization
> java.lang.RuntimeException: Failed to list files in 
> /var/folders/t4/rlc2b6450qbg92762l9l4mt8gn/T/dtest-3eKv_g/test/node1/data1_copy/ks/drop_one-bcef5280f11b11e5825a43f0253f18b5
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:53)
>   at 
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:544)
>   at 
> org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:76)
>   at 
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:165)
>   at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:104)
> Caused by: java.lang.RuntimeException: Unknown column c4 during 
> deserialization
>   at 
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:331)
>   at 
> org.apache.cassandra.io.sstable.format.SSTableReader.openForBatch(SSTableReader.java:430)
>   at 
> org.apache.cassandra.io.sstable.SSTableLoader.lambda$openSSTables$193(SSTableLoader.java:121)
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.lambda$innerList$184(LogAwareFileLister.java:75)
>   at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
>   at 
> java.util.TreeMap$EntrySpliterator.forEachRemaining(TreeMap.java:2965)
>   at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
>   at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
>   at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
>   at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>   at 
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.innerList(LogAwareFileLister.java:77)
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:49)
>   ... 4 more
> {code}



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

[jira] [Commented] (CASSANDRA-11414) dtest failure in bootstrap_test.TestBootstrap.resumable_bootstrap_test

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11414:
-

I'd say changing the stress read and/or write CL to QUORUM would fix this.

> dtest failure in bootstrap_test.TestBootstrap.resumable_bootstrap_test
> --
>
> Key: CASSANDRA-11414
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11414
> Project: Cassandra
>  Issue Type: Test
>  Components: Testing
>Reporter: Philip Thompson
>Assignee: DS Test Eng
>  Labels: dtest
>
> Stress is failing to read back all data. We can see this output from the 
> stress read
> {code}
> java.io.IOException: Operation x0 on key(s) [314c384f304f4c325030]: Data 
> returned was not validated
>   at org.apache.cassandra.stress.Operation.error(Operation.java:138)
>   at 
> org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:116)
>   at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:101)
>   at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:109)
>   at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:261)
>   at 
> org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:327)
> java.io.IOException: Operation x0 on key(s) [33383438363931353131]: Data 
> returned was not validated
>   at org.apache.cassandra.stress.Operation.error(Operation.java:138)
>   at 
> org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:116)
>   at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:101)
>   at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:109)
>   at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:261)
>   at 
> org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:327)
> FAILURE
> {code}
> Started happening with build 1075. Does not appear flaky on CI.
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1076/testReport/bootstrap_test/TestBootstrap/resumable_bootstrap_test
> Failed on CassCI build trunk_dtest #1076



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

[jira] [Created] (CASSANDRA-11415) dtest failure in jmx_test.TestJMX.cfhistograms_test

[Philip Thompson (JIRA)]

Philip Thompson created CASSANDRA-11415:
---

 Summary: dtest failure in jmx_test.TestJMX.cfhistograms_test
 Key: CASSANDRA-11415
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11415
 Project: Cassandra
  Issue Type: Test
Reporter: Philip Thompson
Assignee: DS Test Eng
 Fix For: 2.1.x


We are seeing the following stacktrace when running nodetool cfhistograms

{code}
java.lang.AssertionError
at 
org.apache.cassandra.utils.EstimatedHistogram.(EstimatedHistogram.java:66)
at 
org.apache.cassandra.tools.NodeProbe.metricPercentilesAsArray(NodeProbe.java:1260)
at 
org.apache.cassandra.tools.NodeTool$CfHistograms.execute(NodeTool.java:1109)
at 
org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:292)
at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:206)
{code}

example failure:

http://cassci.datastax.com/job/cassandra-2.1_dtest/437/testReport/jmx_test/TestJMX/cfhistograms_test

Failed on CassCI build cassandra-2.1_dtest #437

This doesn't appear to be flaky. I can repro locally. It seems like a product 
issue, but if someone could confirm if it happens out of the test, that would 
be great.



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

[jira] [Created] (CASSANDRA-11414) dtest failure in bootstrap_test.TestBootstrap.resumable_bootstrap_test

[Philip Thompson (JIRA)]

Philip Thompson created CASSANDRA-11414:
---

 Summary: dtest failure in 
bootstrap_test.TestBootstrap.resumable_bootstrap_test
 Key: CASSANDRA-11414
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11414
 Project: Cassandra
  Issue Type: Test
  Components: Testing
Reporter: Philip Thompson
Assignee: DS Test Eng


Stress is failing to read back all data. We can see this output from the stress 
read
{code}
java.io.IOException: Operation x0 on key(s) [314c384f304f4c325030]: Data 
returned was not validated

at org.apache.cassandra.stress.Operation.error(Operation.java:138)
at 
org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:116)
at 
org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:101)
at 
org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:109)
at 
org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:261)
at 
org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:327)
java.io.IOException: Operation x0 on key(s) [33383438363931353131]: Data 
returned was not validated

at org.apache.cassandra.stress.Operation.error(Operation.java:138)
at 
org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:116)
at 
org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:101)
at 
org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:109)
at 
org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:261)
at 
org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:327)
FAILURE

{code}

Started happening with build 1075. Does not appear flaky on CI.

example failure:

http://cassci.datastax.com/job/trunk_dtest/1076/testReport/bootstrap_test/TestBootstrap/resumable_bootstrap_test

Failed on CassCI build trunk_dtest #1076



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

[jira] [Resolved] (CASSANDRA-11413) dtest failure in cql_tests.AbortedQueriesTester.remote_query_test

[Philip Thompson (JIRA)]

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

Philip Thompson resolved CASSANDRA-11413.
-
Resolution: Fixed

Reverted the ccm PR with https://github.com/pcmanus/ccm/pull/480

> dtest failure in cql_tests.AbortedQueriesTester.remote_query_test
> -
>
> Key: CASSANDRA-11413
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11413
> Project: Cassandra
>  Issue Type: Test
>  Components: Testing
>Reporter: Philip Thompson
>Assignee: Philip Thompson
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1076/testReport/cql_tests/AbortedQueriesTester/remote_query_test
> Failed on CassCI build trunk_dtest #1076
> Also breaking:
> cql_tests.AbortedQueriesTester.materialized_view_test
> topology_test.TestTopology.do_not_join_ring_test
> Broken by https://github.com/pcmanus/ccm/pull/479



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

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

[Philip Thompson (JIRA)]

Philip Thompson created CASSANDRA-11413:
---

 Summary: dtest failure in 
cql_tests.AbortedQueriesTester.remote_query_test
 Key: CASSANDRA-11413
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11413
 Project: Cassandra
  Issue Type: Test
  Components: Testing
Reporter: Philip Thompson
Assignee: Philip Thompson


example failure:

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

Failed on CassCI build trunk_dtest #1076

Also breaking:
cql_tests.AbortedQueriesTester.materialized_view_test
topology_test.TestTopology.do_not_join_ring_test

Broken by https://github.com/pcmanus/ccm/pull/479



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

[jira] [Commented] (CASSANDRA-8969) Add indication in cassandra.yaml that rpc timeouts going too high will cause memory build up

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna commented on CASSANDRA-8969:
-

Not to bikeshed too much but what do you think of making it a little more 
explicit?

{quote}
+# For this reason, you should avoid putting these settings too high. Of course
+# putting them too low is equally ill-advised since clients could get timeouts 
even
+# for successful operations just because the timeout setting is too tight.
+# In other words, if you are timing out requests because of underlying 
resource constraints
+# then increasing the timeout will just cause more problems.
{quote}

> Add indication in cassandra.yaml that rpc timeouts going too high will cause 
> memory build up
> 
>
> Key: CASSANDRA-8969
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8969
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: 8969.txt
>
>
> It would be helpful to communicate that setting the rpc timeouts too high may 
> cause memory problems on the server as it can become overloaded and has to 
> retain the in flight requests in memory.  I'll get this done but just adding 
> the ticket as a placeholder for memory.



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

[jira] [Commented] (CASSANDRA-11310) Allow filtering on clustering columns for queries without secondary indexes

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-11310:
-

I hope this time it should be a bit better. 

Unfortunately, making a {{useFiltering}} boolean variable similar to 
{{usesSecondaryIndexing}} would mean splitting some logic within 
{{StatementRestrictions::needFiltering}} into several places and adding several 
iterations (for example check for whether clustering columns cause indexing and 
whether adding the contains restriction would cause filtering).

Although other than that  - there was one redundant check (for 
{{usesSecondaryIndexing || clusteringColumnRestrictions}} that already happens 
in {{processClusteringColumnRestrictions}}). Clustering column restrictions are 
added without influencing indexing flag now, as {{needFiltering}} is now on 
{{ClusteringColumnRestrictions}}.

I've added test covering {{ORDER}}, {{COMPACT}}, {{static}} columns, overall 
in/across partitions, with different combinations of slices, with frozen 
collections in PK.
New branch is here: https://github.com/ifesdjeen/cassandra/commits/11310-trunk

Thank you.

> Allow filtering on clustering columns for queries without secondary indexes
> ---
>
> Key: CASSANDRA-11310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11310
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Alex Petrov
>  Labels: doc-impacting
> Fix For: 3.x
>
>
> Since CASSANDRA-6377 queries without index filtering non-primary key columns 
> are fully supported.
> It makes sense to also support filtering on clustering-columns.
> {code}
> CREATE TABLE emp_table2 (
> empID int,
> firstname text,
> lastname text,
> b_mon text,
> b_day text,
> b_yr text,
> PRIMARY KEY (empID, b_yr, b_mon, b_day));
> SELECT b_mon,b_day,b_yr,firstname,lastname FROM emp_table2
> WHERE b_mon='oct' ALLOW FILTERING;
> {code}



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

[jira] [Commented] (CASSANDRA-9692) Print sensible units for all log messages

[Giampaolo (JIRA)]

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

Giampaolo commented on CASSANDRA-9692:
--

I added a patch for {{dtest}}. The strange thing was that I had a negative 
compaction ratio like the one below, so I added also the minus sign to the regex
{code}
Compacted (3c496851-f111-11e5-bd49-13f05e23c5c9) 9 sstables to 
[/tmp/dtest-8P7lxi/test/node1/data1/keyspace1/standard1-6881b590f11011e5bd4913f05e23c5c9/ma-28-big,]
 to level=0.  43.792MiB to 43.868MiB (~100% of original) in 18,517ms = 
-4.186KiB/s.  0 total partitions merged to 199,890.  Partition merge counts 
were {1:199890, }
{code}
To make things work, I added also a little change to the {{ccm}}. It's not 
clear to me at the moment if ccm was to change or not. If this is the case, I 
will do a PR on github.

You can find patches on github also: 
[dtest|https://github.com/radicalbit/cassandra-dtest/commit/8a1017398ab55a4648fcc307a9be0644c02602dd]
 and 
[ccm|https://github.com/radicalbit/ccm/commit/bb08b6798f3fda39217f2daf710116a84a3ede84]

> Print sensible units for all log messages
> -
>
> Key: CASSANDRA-9692
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9692
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benedict
>Assignee: Giampaolo
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: 
> Cassandra9692-Rev1-trunk-giampaolo-trapasso-at-radicalbit-io.diff, 
> Cassandra9692-Rev2-trunk-giampaolo.trapasso-at-radicalbit-io.diff, 
> Cassandra9692-trunk-giampaolo-trapasso-at-radicalbit-io.diff, 
> ccm-bb08b6798f3fda39217f2daf710116a84a3ede84.patch, 
> dtests-8a1017398ab55a4648fcc307a9be0644c02602dd.patch
>
>
> Like CASSANDRA-9691, this has bugged me too long. it also adversely impacts 
> log analysis. I've introduced some improvements to the bits I touched for 
> CASSANDRA-9681, but we should do this across the codebase. It's a small 
> investment for a lot of long term clarity in the logs.



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

[jira] [Commented] (CASSANDRA-11405) Server encryption cannot be enabled with the IBM JRE 1.7

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-11405:
-

+1 to Stefan's assessment; we will not back port to < 3.x. That being said, the 
patch is pretty trivial to backport, so you could apply it your own deployment.

> Server encryption cannot be enabled with the IBM JRE 1.7
> 
>
> Key: CASSANDRA-11405
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11405
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: Linux, IBM JRE 1.7
>Reporter: Guillermo Vega-Toro
> Fix For: 2.2.6
>
>
> When enabling server encryption with the IBM JRE (algorithm: IbmX509), an 
> IllegalArgumentException is thrown from the IBM JSSE when the server is 
> started:
> ERROR 10:04:37,326 Exception encountered during startup
> java.lang.IllegalArgumentException: SSLv2Hello
> at com.ibm.jsse2.qb.a(qb.java:50)
> at com.ibm.jsse2.pb.a(pb.java:101)
> at com.ibm.jsse2.pb.(pb.java:77)
> at com.ibm.jsse2.oc.setEnabledProtocols(oc.java:77)
> at 
> org.apache.cassandra.security.SSLFactory.getServerSocket(SSLFactory.java:64)
> at 
> org.apache.cassandra.net.MessagingService.getServerSockets(MessagingService.java:425)
> at 
> org.apache.cassandra.net.MessagingService.listen(MessagingService.java:409)
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:693)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:623)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:515)
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:437)
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:567)
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:656)
> The problem is that the IBM JSSE does not support SSLv2Hello, but this 
> protocol is hard-coded in class org.apache.cassandra.security.SSLFactory:
> public static final String[] ACCEPTED_PROTOCOLS = new String[] {"SSLv2Hello", 
> "TLSv1", "TLSv1.1", "TLSv1.2"};
> public static SSLServerSocket getServerSocket(EncryptionOptions options, 
> InetAddress address, int port) throws IOException
> {
> SSLContext ctx = createSSLContext(options, true);
> SSLServerSocket serverSocket = 
> (SSLServerSocket)ctx.getServerSocketFactory().createServerSocket();
> serverSocket.setReuseAddress(true);
> String[] suits = 
> filterCipherSuites(serverSocket.getSupportedCipherSuites(), 
> options.cipher_suites);
> serverSocket.setEnabledCipherSuites(suits);
> serverSocket.setNeedClientAuth(options.require_client_auth);
> serverSocket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
> serverSocket.bind(new InetSocketAddress(address, port), 500);
> return serverSocket;
> }
> This ACCEPTED_PROTOCOLS array should not be hard-coded. It should rather read 
> the protocols from configuration, or if the algorithm is IbmX509, simply do 
> not call setEnabledProtocols - with the IBM JSSE, the enabled protocol is 
> controlled by the protocol passed to SSLContext.getInstance.



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

[jira] [Resolved] (CASSANDRA-11405) Server encryption cannot be enabled with the IBM JRE 1.7

[Jason Brown (JIRA)]

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

Jason Brown resolved CASSANDRA-11405.
-
Resolution: Won't Fix

> Server encryption cannot be enabled with the IBM JRE 1.7
> 
>
> Key: CASSANDRA-11405
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11405
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: Linux, IBM JRE 1.7
>Reporter: Guillermo Vega-Toro
> Fix For: 2.2.6
>
>
> When enabling server encryption with the IBM JRE (algorithm: IbmX509), an 
> IllegalArgumentException is thrown from the IBM JSSE when the server is 
> started:
> ERROR 10:04:37,326 Exception encountered during startup
> java.lang.IllegalArgumentException: SSLv2Hello
> at com.ibm.jsse2.qb.a(qb.java:50)
> at com.ibm.jsse2.pb.a(pb.java:101)
> at com.ibm.jsse2.pb.(pb.java:77)
> at com.ibm.jsse2.oc.setEnabledProtocols(oc.java:77)
> at 
> org.apache.cassandra.security.SSLFactory.getServerSocket(SSLFactory.java:64)
> at 
> org.apache.cassandra.net.MessagingService.getServerSockets(MessagingService.java:425)
> at 
> org.apache.cassandra.net.MessagingService.listen(MessagingService.java:409)
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:693)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:623)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:515)
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:437)
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:567)
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:656)
> The problem is that the IBM JSSE does not support SSLv2Hello, but this 
> protocol is hard-coded in class org.apache.cassandra.security.SSLFactory:
> public static final String[] ACCEPTED_PROTOCOLS = new String[] {"SSLv2Hello", 
> "TLSv1", "TLSv1.1", "TLSv1.2"};
> public static SSLServerSocket getServerSocket(EncryptionOptions options, 
> InetAddress address, int port) throws IOException
> {
> SSLContext ctx = createSSLContext(options, true);
> SSLServerSocket serverSocket = 
> (SSLServerSocket)ctx.getServerSocketFactory().createServerSocket();
> serverSocket.setReuseAddress(true);
> String[] suits = 
> filterCipherSuites(serverSocket.getSupportedCipherSuites(), 
> options.cipher_suites);
> serverSocket.setEnabledCipherSuites(suits);
> serverSocket.setNeedClientAuth(options.require_client_auth);
> serverSocket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
> serverSocket.bind(new InetSocketAddress(address, port), 500);
> return serverSocket;
> }
> This ACCEPTED_PROTOCOLS array should not be hard-coded. It should rather read 
> the protocols from configuration, or if the algorithm is IbmX509, simply do 
> not call setEnabledProtocols - with the IBM JSSE, the enabled protocol is 
> controlled by the protocol passed to SSLContext.getInstance.



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

[jira] [Commented] (CASSANDRA-8969) Add indication in cassandra.yaml that rpc timeouts going too high will cause memory build up

[J.B. Langston (JIRA)]

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

J.B. Langston commented on CASSANDRA-8969:
--

I agree this could be a good warning to have. I've seen a lot of customers 
naively increase the timeout. Usually it's caused by I/O not keeping up with 
requests, but a lot of users won't take the time to figure that out. They just 
see their application timing out and they see something in cassandra.yaml 
called timeout so they increase it without thinking of the cost.  Now they have 
GC death spiral and OOM to contend with in addition to the original problem.

> Add indication in cassandra.yaml that rpc timeouts going too high will cause 
> memory build up
> 
>
> Key: CASSANDRA-8969
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8969
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: 8969.txt
>
>
> It would be helpful to communicate that setting the rpc timeouts too high may 
> cause memory problems on the server as it can become overloaded and has to 
> retain the in flight requests in memory.  I'll get this done but just adding 
> the ticket as a placeholder for memory.



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

[jira] [Comment Edited] (CASSANDRA-8969) Add indication in cassandra.yaml that rpc timeouts going too high will cause memory build up

[J.B. Langston (JIRA)]

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

J.B. Langston edited comment on CASSANDRA-8969 at 3/23/16 4:19 PM:
---

I agree this could be a good warning to have. I've seen a lot of users naively 
increase the timeout. Usually it's caused by I/O not keeping up with requests, 
but a lot of users won't take the time to figure that out. They just see their 
application timing out and they see something in cassandra.yaml called timeout 
so they increase it without thinking of the cost.  Now they have GC death 
spiral and OOM to contend with in addition to the original problem.


was (Author: jblangs...@datastax.com):
I agree this could be a good warning to have. I've seen a lot of customers 
naively increase the timeout. Usually it's caused by I/O not keeping up with 
requests, but a lot of users won't take the time to figure that out. They just 
see their application timing out and they see something in cassandra.yaml 
called timeout so they increase it without thinking of the cost.  Now they have 
GC death spiral and OOM to contend with in addition to the original problem.

> Add indication in cassandra.yaml that rpc timeouts going too high will cause 
> memory build up
> 
>
> Key: CASSANDRA-8969
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8969
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: 8969.txt
>
>
> It would be helpful to communicate that setting the rpc timeouts too high may 
> cause memory problems on the server as it can become overloaded and has to 
> retain the in flight requests in memory.  I'll get this done but just adding 
> the ticket as a placeholder for memory.



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

[jira] [Commented] (CASSANDRA-8969) Add indication in cassandra.yaml that rpc timeouts going too high will cause memory build up

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan commented on CASSANDRA-8969:


[~slebresne] the issue he is talking about is when a node gets overloaded such 
that requests start backing up.  If I am issuing 100 req/s and something 
happens to stall things for 10 seconds (say some other node that my requests go 
to stalls), with a 1 second timeout I only ever have 100 requests in flight.  
With a 10 second timeout I could have 1000 requests in flight on the 
coordinator.

> Add indication in cassandra.yaml that rpc timeouts going too high will cause 
> memory build up
> 
>
> Key: CASSANDRA-8969
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8969
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: 8969.txt
>
>
> It would be helpful to communicate that setting the rpc timeouts too high may 
> cause memory problems on the server as it can become overloaded and has to 
> retain the in flight requests in memory.  I'll get this done but just adding 
> the ticket as a placeholder for memory.



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

[jira] [Updated] (CASSANDRA-8467) Monitoring UDFs

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-8467:
-
Component/s: Observability

> Monitoring UDFs
> ---
>
> Key: CASSANDRA-8467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8467
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Observability
>Reporter: Robert Stupp
>Priority: Minor
>  Labels: tracing, udf
>
> This thicket's about to add UDF executions to session-tracing.
> Tracing these parameters for UDF invocations could become very interesting.
> * name of UDF
> * # of invocations
> * # of rejected executions
> * min/max/avg execution times
> "Rejected executions" would count UDFs that are not executed because an input 
> parameter is null/empty (CASSANDRA-8374).



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

[jira] [Commented] (CASSANDRA-7962) usage counters on prepared statements, summary and details

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-7962:
-

CASSANDRA-8831 seems to be related to this one.

+10 on having metrics on prepared statements. That would help a lot in practice 
to answer the question: "what's going on in my cluster".

(oh - seems i just volunteered ;) )


> usage counters on prepared statements, summary and details
> --
>
> Key: CASSANDRA-7962
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7962
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Observability
>Reporter: Jonathan Shook
>Priority: Minor
>
> Count the usages of prepared statements on the server side, and expose them 
> via JMX. The original query structure should be included. Provide a nodetool 
> command to see the counts.  Expose a meaningful id which can be used in other 
> places, such as with other JMX clients.  If enumerations are used to identify 
> these for easier discussion, enumerate according to the statement id.
> Allow for "since last access" deltas, or "since server start", and require 
> this parameter to be specified. 
> Show the number of seconds represented by the current data.
> This would allow easier identification of access pattern distribution in the 
> case that prepared statements are being used. It would provide useful metrics 
> for diagnosis, testing, and monitoring.
> nodetool command syntax:
> nodetool ( spusagecountsummary | spusagecountdetails ) ( deltas | alltime ) [ 
> ks [ table ] ]
> Example nodetool outputs:
> nodetool spusagecountsummary deltas appks usertable 
> (count, statement id), since 234233 seconds ago
> 56304 24ad327f9bb2578de663fc92336703dd
> 5 8743b52063cd84097a65d1633f5c74f5
> 1 663fc92336703dd24ad327f9bb2578de
> 0 92336703dd24ad327f9bb2578de663fc
> 0 bb2578de663fc922336703dd24ad327f9
> nodetool spusagecountdetails alltime appks usertable 
> (count, statement id,\n query\n\n), since 234234233 seconds ago
> 56320304 24ad327f9bb2578de663fc92336703dd
> select user from usertable where userid=?;
> 265 8743b52063cd84097a65d1633f5c74f5
> insert into usertable (userid,...) ...
> 11 663fc92336703dd24ad327f9bb2578de
> select tags from tagcloud  where userid=?;
> ... and so forth ...



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

[jira] [Updated] (CASSANDRA-7962) usage counters on prepared statements, summary and details

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-7962:
-
Component/s: Observability

> usage counters on prepared statements, summary and details
> --
>
> Key: CASSANDRA-7962
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7962
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Observability
>Reporter: Jonathan Shook
>Priority: Minor
>
> Count the usages of prepared statements on the server side, and expose them 
> via JMX. The original query structure should be included. Provide a nodetool 
> command to see the counts.  Expose a meaningful id which can be used in other 
> places, such as with other JMX clients.  If enumerations are used to identify 
> these for easier discussion, enumerate according to the statement id.
> Allow for "since last access" deltas, or "since server start", and require 
> this parameter to be specified. 
> Show the number of seconds represented by the current data.
> This would allow easier identification of access pattern distribution in the 
> case that prepared statements are being used. It would provide useful metrics 
> for diagnosis, testing, and monitoring.
> nodetool command syntax:
> nodetool ( spusagecountsummary | spusagecountdetails ) ( deltas | alltime ) [ 
> ks [ table ] ]
> Example nodetool outputs:
> nodetool spusagecountsummary deltas appks usertable 
> (count, statement id), since 234233 seconds ago
> 56304 24ad327f9bb2578de663fc92336703dd
> 5 8743b52063cd84097a65d1633f5c74f5
> 1 663fc92336703dd24ad327f9bb2578de
> 0 92336703dd24ad327f9bb2578de663fc
> 0 bb2578de663fc922336703dd24ad327f9
> nodetool spusagecountdetails alltime appks usertable 
> (count, statement id,\n query\n\n), since 234234233 seconds ago
> 56320304 24ad327f9bb2578de663fc92336703dd
> select user from usertable where userid=?;
> 265 8743b52063cd84097a65d1633f5c74f5
> insert into usertable (userid,...) ...
> 11 663fc92336703dd24ad327f9bb2578de
> select tags from tagcloud  where userid=?;
> ... and so forth ...



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

[jira] [Updated] (CASSANDRA-9692) Print sensible units for all log messages

[Giampaolo (JIRA)]

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

Giampaolo updated CASSANDRA-9692:
-
Attachment: ccm-bb08b6798f3fda39217f2daf710116a84a3ede84.patch
dtests-8a1017398ab55a4648fcc307a9be0644c02602dd.patch

> Print sensible units for all log messages
> -
>
> Key: CASSANDRA-9692
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9692
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benedict
>Assignee: Giampaolo
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: 
> Cassandra9692-Rev1-trunk-giampaolo-trapasso-at-radicalbit-io.diff, 
> Cassandra9692-Rev2-trunk-giampaolo.trapasso-at-radicalbit-io.diff, 
> Cassandra9692-trunk-giampaolo-trapasso-at-radicalbit-io.diff, 
> ccm-bb08b6798f3fda39217f2daf710116a84a3ede84.patch, 
> dtests-8a1017398ab55a4648fcc307a9be0644c02602dd.patch
>
>
> Like CASSANDRA-9691, this has bugged me too long. it also adversely impacts 
> log analysis. I've introduced some improvements to the bits I touched for 
> CASSANDRA-9681, but we should do this across the codebase. It's a small 
> investment for a lot of long term clarity in the logs.



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

[jira] [Commented] (CASSANDRA-8969) Add indication in cassandra.yaml that rpc timeouts going too high will cause memory build up

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-8969:
-

bq. you could potentially have 2x in-flight requests being kept in memory

Not totally sure I follow. Are we talking about the request objects? Because 
those are really tiny and I don't that being that relevant. Besides, the number 
of max in-flight queries is currently really limited by the number of native 
transport threads, and I'm not sure to see in which way a bigger rpc timeouts 
changes much here.

Anyway, feel free to check the attached patch to see if we're talking of the 
same thing with different words. But if we aren't, I'm not sure to understand 
the problem you're mentioning.

> Add indication in cassandra.yaml that rpc timeouts going too high will cause 
> memory build up
> 
>
> Key: CASSANDRA-8969
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8969
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: 8969.txt
>
>
> It would be helpful to communicate that setting the rpc timeouts too high may 
> cause memory problems on the server as it can become overloaded and has to 
> retain the in flight requests in memory.  I'll get this done but just adding 
> the ticket as a placeholder for memory.



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

[jira] [Commented] (CASSANDRA-10769) "received out of order wrt DecoratedKey" after scrub

[Jean-Francois Gosselin (JIRA)]

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

Jean-Francois Gosselin commented on CASSANDRA-10769:


Based on the comments in CASSANDRA-9935 the "AssertionError: row DecoratedKey" 
is still present in 2.1.13.

> "received out of order wrt DecoratedKey" after scrub
> 
>
> Key: CASSANDRA-10769
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10769
> Project: Cassandra
>  Issue Type: Bug
> Environment: C* 2.1.11, Debian Wheezy
>Reporter: mlowicki
>
> After running scrub and cleanup on all nodes in single data center I'm 
> getting:
> {code}
> ERROR [ValidationExecutor:103] 2015-11-25 06:28:21,530 Validator.java:245 - 
> Failed creating a merkle tree for [repair 
> #89fa2b70-933d-11e5-b036-75bb514ae072 on sync/entity_by_id2, 
> (-5867793819051725444,-5865919628027816979]], /10.210.3.221 (see log for 
> details)
> ERROR [ValidationExecutor:103] 2015-11-25 06:28:21,531 
> CassandraDaemon.java:227 - Exception in thread 
> Thread[ValidationExecutor:103,1,main]
> java.lang.AssertionError: row DecoratedKey(-5867787467868737053, 
> 000932373633313036313204808800) received out of order wrt 
> DecoratedKey(-5865937851627253360, 000933313230313737333204c3c700)
> at org.apache.cassandra.repair.Validator.add(Validator.java:127) 
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:1010)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.compaction.CompactionManager.access$600(CompactionManager.java:94)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.compaction.CompactionManager$9.call(CompactionManager.java:622)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
> ~[na:1.7.0_80]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  ~[na:1.7.0_80]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_80]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_80]
> {code}
> What I did is to run repair on other node:
> {code}
> time nodetool repair --in-local-dc
> {code}
> Corresponding log on the node where repair has been started:
> {code}
> ERROR [AntiEntropySessions:414] 2015-11-25 06:28:21,533 
> RepairSession.java:303 - [repair #89fa2b70-933d-11e5-b036-75bb514ae072] 
> session completed with the following error
> org.apache.cassandra.exceptions.RepairException: [repair 
> #89fa2b70-933d-11e5-b036-75bb514ae072 on sync/entity_by_id2, 
> (-5867793819051725444,-5865919628027816979]] Validation failed in 
> /10.210.3.117
> at 
> org.apache.cassandra.repair.RepairSession.validationComplete(RepairSession.java:166)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:406)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:134)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  [na:1.7.0_80]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_80]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_80]
> INFO  [AntiEntropySessions:415] 2015-11-25 06:28:21,533 
> RepairSession.java:260 - [repair #b9458fa0-933d-11e5-b036-75bb514ae072] new 
> session: will sync /10.210.3.221, /10.210.3.118, /10.210.3.117 on range 
> (7119703141488009983,7129744584776466802] for sync.[device_token, entity2, 
> user_stats, user_device, user_quota, user_store, user_device_progress, 
> entity_by_id2]
> ERROR [AntiEntropySessions:414] 2015-11-25 06:28:21,533 
> CassandraDaemon.java:227 - Exception in thread 
> Thread[AntiEntropySessions:414,5,RMI Runtime]
> java.lang.RuntimeException: org.apache.cassandra.exceptions.RepairException: 
> [repair #89fa2b70-933d-11e5-b036-75bb514ae072 on sync/entity_by_id2, 
> (-5867793819051725444,-5865919628027816979]] Validation failed in 
> /10.210.3.117
> at com.google.common.base.Throwables.propagate(Throwables.java:160) 
> ~[guava-16.0.jar:na]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32) 
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> ~[na:1.7.0_80]
> at 

[jira] [Commented] (CASSANDRA-10134) Always require replace_address to replace existing address

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10134:
-

good idea, +1.

> Always require replace_address to replace existing address
> --
>
> Key: CASSANDRA-10134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10134
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Distributed Metadata
>Reporter: Tyler Hobbs
>Assignee: Sam Tunnicliffe
> Fix For: 3.x
>
>
> Normally, when a node is started from a clean state with the same address as 
> an existing down node, it will fail to start with an error like this:
> {noformat}
> ERROR [main] 2015-08-19 15:07:51,577 CassandraDaemon.java:554 - Exception 
> encountered during startup
> java.lang.RuntimeException: A node with address /127.0.0.3 already exists, 
> cancelling join. Use cassandra.replace_address if you want to replace this 
> node.
>   at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:543)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:783)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:720)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:611)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378) 
> [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:537)
>  [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:626) 
> [main/:na]
> {noformat}
> However, if {{auto_bootstrap}} is set to false or the node is in its own seed 
> list, it will not throw this error and will start normally.  The new node 
> then takes over the host ID of the old node (even if the tokens are 
> different), and the only message you will see is a warning in the other 
> nodes' logs:
> {noformat}
> logger.warn("Changing {}'s host ID from {} to {}", endpoint, storedId, 
> hostId);
> {noformat}
> This could cause an operator to accidentally wipe out the token information 
> for a down node without replacing it.  To fix this, we should check for an 
> endpoint collision even if {{auto_bootstrap}} is false or the node is a seed.



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

[jira] [Comment Edited] (CASSANDRA-10134) Always require replace_address to replace existing address

[Joel Knighton (JIRA)]

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

Joel Knighton edited comment on CASSANDRA-10134 at 3/23/16 3:06 PM:


Good point - I don't think the implementation of this needs to. The current 
behavior is:
no bootstrap/seed - no collision check
bootstrap - collision check
replace_address - collision check + require bootstrapping

The implementation could separate this to make replacement/bootstrap 
orthogonal, such that replace_address with bootstrap goes through the same 
machinery as currently, but replace_address with no bootstrap simply overrides 
the collision check.


was (Author: jkni):
Good point - I don't think the implementation of this needs to. The current 
behavior is:
no bootstrap/seed - no collision check
bootstrap - collision check
replace_address - collision check + require bootstrapping

The implementation could separate this to make replacement/bootstrap 
orthogonal, such that replace_address with bootstrap goes through the same 
machinery as currently, but replace_bootstrap with no bootstrap simply 
overrides the collision check.

> Always require replace_address to replace existing address
> --
>
> Key: CASSANDRA-10134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10134
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Distributed Metadata
>Reporter: Tyler Hobbs
>Assignee: Sam Tunnicliffe
> Fix For: 3.x
>
>
> Normally, when a node is started from a clean state with the same address as 
> an existing down node, it will fail to start with an error like this:
> {noformat}
> ERROR [main] 2015-08-19 15:07:51,577 CassandraDaemon.java:554 - Exception 
> encountered during startup
> java.lang.RuntimeException: A node with address /127.0.0.3 already exists, 
> cancelling join. Use cassandra.replace_address if you want to replace this 
> node.
>   at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:543)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:783)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:720)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:611)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378) 
> [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:537)
>  [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:626) 
> [main/:na]
> {noformat}
> However, if {{auto_bootstrap}} is set to false or the node is in its own seed 
> list, it will not throw this error and will start normally.  The new node 
> then takes over the host ID of the old node (even if the tokens are 
> different), and the only message you will see is a warning in the other 
> nodes' logs:
> {noformat}
> logger.warn("Changing {}'s host ID from {} to {}", endpoint, storedId, 
> hostId);
> {noformat}
> This could cause an operator to accidentally wipe out the token information 
> for a down node without replacing it.  To fix this, we should check for an 
> endpoint collision even if {{auto_bootstrap}} is false or the node is a seed.



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

[jira] [Commented] (CASSANDRA-8969) Add indication in cassandra.yaml that rpc timeouts going too high will cause memory build up

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna commented on CASSANDRA-8969:
-

Sorry about the lag in responsiveness on my part.  The idea was that if you set 
it to 2x, then you could potentially have 2x in-flight requests being kept in 
memory on the server in cases where requests get queued up.  I think that's not 
immediately obvious to people who increase it to just avoid client-side 
timeouts.

> Add indication in cassandra.yaml that rpc timeouts going too high will cause 
> memory build up
> 
>
> Key: CASSANDRA-8969
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8969
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: 8969.txt
>
>
> It would be helpful to communicate that setting the rpc timeouts too high may 
> cause memory problems on the server as it can become overloaded and has to 
> retain the in flight requests in memory.  I'll get this done but just adding 
> the ticket as a placeholder for memory.



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

[jira] [Commented] (CASSANDRA-10134) Always require replace_address to replace existing address

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-10134:
---

Good point - I don't think the implementation of this needs to. The current 
behavior is:
no bootstrap/seed - no collision check
bootstrap - collision check
replace_address - collision check + require bootstrapping

The implementation could separate this to make replacement/bootstrap 
orthogonal, such that replace_address with bootstrap goes through the same 
machinery as currently, but replace_bootstrap with no bootstrap simply 
overrides the collision check.

> Always require replace_address to replace existing address
> --
>
> Key: CASSANDRA-10134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10134
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Distributed Metadata
>Reporter: Tyler Hobbs
>Assignee: Sam Tunnicliffe
> Fix For: 3.x
>
>
> Normally, when a node is started from a clean state with the same address as 
> an existing down node, it will fail to start with an error like this:
> {noformat}
> ERROR [main] 2015-08-19 15:07:51,577 CassandraDaemon.java:554 - Exception 
> encountered during startup
> java.lang.RuntimeException: A node with address /127.0.0.3 already exists, 
> cancelling join. Use cassandra.replace_address if you want to replace this 
> node.
>   at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:543)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:783)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:720)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:611)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378) 
> [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:537)
>  [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:626) 
> [main/:na]
> {noformat}
> However, if {{auto_bootstrap}} is set to false or the node is in its own seed 
> list, it will not throw this error and will start normally.  The new node 
> then takes over the host ID of the old node (even if the tokens are 
> different), and the only message you will see is a warning in the other 
> nodes' logs:
> {noformat}
> logger.warn("Changing {}'s host ID from {} to {}", endpoint, storedId, 
> hostId);
> {noformat}
> This could cause an operator to accidentally wipe out the token information 
> for a down node without replacing it.  To fix this, we should check for an 
> endpoint collision even if {{auto_bootstrap}} is false or the node is a seed.



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

[jira] [Commented] (CASSANDRA-11403) Serializer/Version mismatch during upgrades to C* 3.0

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan commented on CASSANDRA-11403:
-

This is on cassandra-3.0 hash 9cfbc31bc29685bd60355a823e0cf261a89858f0

> Serializer/Version mismatch during upgrades to C* 3.0
> -
>
> Key: CASSANDRA-11403
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11403
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Anthony Cozzie
>
> The problem line seems to be:
> {code}
> MessageOut message = 
> readCommand.createMessage(MessagingService.instance().getVersion(endpoint));
> {code}
> SinglePartitionReadCommand then picks the serializer based on the version:
> {code}
> return new MessageOut<>(MessagingService.Verb.READ, this, version < 
> MessagingService.VERSION_30 ? legacyReadCommandSerializer : serializer);
> {code}
> However, OutboundTcpConnectionPool will test the payload size vs the version 
> from its smallMessages connection:
> {code}
> return msg.payloadSize(smallMessages.getTargetVersion()) > 
> LARGE_MESSAGE_THRESHOLD
> {code}
> Which is set when the connection/pool is created:
> {code}
> targetVersion = MessagingService.instance().getVersion(pool.endPoint());
> {code}
> During an upgrade, this state can change between these two calls leading the 
> 3.0 serializer being used on 2.x packets and the following stacktrace:
> ERROR [OptionalTasks:1] 2016-03-07 19:53:06,445  CassandraDaemon.java:195 - 
> Exception in thread Thread[OptionalTasks:1,5,main]
> java.lang.AssertionError: null
>   at 
> org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:632)
>  ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:536)
>  ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:166) 
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:72)
>  ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:609)
>  ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:758)
>  ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.net.MessagingService.sendRR(MessagingService.java:701) 
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.net.MessagingService.sendRRWithFailure(MessagingService.java:684)
>  ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.service.AbstractReadExecutor.makeRequests(AbstractReadExecutor.java:110)
>  ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.service.AbstractReadExecutor.makeDataRequests(AbstractReadExecutor.java:85)
>  ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.service.AbstractReadExecutor$NeverSpeculatingReadExecutor.executeAsync(AbstractReadExecutor.java:214)
>  ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.doInitialQueries(StorageProxy.java:1699)
>  ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1654) 
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1601) 
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1520) 
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:918)
>  ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:251)
>  ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:212)
>  ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:77)
>  ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:237) 
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:252) 
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
>   at 
> 

[jira] [Deleted] (CASSANDRA-11343) Fix bloom filter sizing with LCS

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko deleted CASSANDRA-11343:
--


> Fix bloom filter sizing with LCS
> 
>
> Key: CASSANDRA-11343
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11343
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>
> Since CASSANDRA-7272 we most often over allocate the bloom filter size with 
> LCS



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

[jira] [Updated] (CASSANDRA-11373) Cancelled compaction leading to infinite loop in compaction strategy getNextBackgroundTask

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-11373:

Status: Patch Available  (was: Open)

> Cancelled compaction leading to infinite loop in compaction strategy 
> getNextBackgroundTask
> --
>
> Key: CASSANDRA-11373
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11373
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Eduard Tudenhoefner
>Assignee: Marcus Eriksson
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: jstack.txt
>
>
> Our test is basically running *nodetool repair* on specific keyspaces (such 
> as keyspace1) and the test is also triggering *nodetool compact keyspace1 
> standard1* in the background. 
> And so it looks like running major compactions & repairs lead to that issue 
> when using *LCS*.
> Below is an excerpt from the *thread dump* (the rest is attached)
> {code}
> "CompactionExecutor:2" #33 daemon prio=1 os_prio=4 tid=0x7f5363e64f10 
> nid=0x3c4e waiting for monitor entry [0x7f53340d8000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:252)
>   - waiting to lock <0x0006c9362c80> (a 
> org.apache.cassandra.db.compaction.CompactionStrategyManager)
>   at 
> org.apache.cassandra.db.lifecycle.Tracker.notifySSTableRepairedStatusChanged(Tracker.java:434)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager.performAnticompaction(CompactionManager.java:550)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$7.runMayThrow(CompactionManager.java:465)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   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)
>Locked ownable synchronizers:
>   - <0x0006c9362ca8> (a 
> java.util.concurrent.ThreadPoolExecutor$Worker)
> "CompactionExecutor:1" #32 daemon prio=1 os_prio=4 tid=0x7f5363e618b0 
> nid=0x3c4d runnable [0x7f5334119000]
>java.lang.Thread.State: RUNNABLE
>   at com.google.common.collect.Iterators$7.computeNext(Iterators.java:650)
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
>   at com.google.common.collect.Iterators.addAll(Iterators.java:361)
>   at com.google.common.collect.Iterables.addAll(Iterables.java:354)
>   at 
> org.apache.cassandra.db.compaction.LeveledManifest.getCandidatesFor(LeveledManifest.java:589)
>   at 
> org.apache.cassandra.db.compaction.LeveledManifest.getCompactionCandidates(LeveledManifest.java:349)
>   - locked <0x0006d0f7a6a8> (a 
> org.apache.cassandra.db.compaction.LeveledManifest)
>   at 
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:98)
>   - locked <0x0006d0f7a568> (a 
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy)
>   at 
> org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:95)
>   - locked <0x0006c9362c80> (a 
> org.apache.cassandra.db.compaction.CompactionStrategyManager)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:257)
>   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}
> *CPU usage is at 100%*
> {code}
> top -p 15386
> top - 12:12:40 up  1:28,  1 user,  load average: 1.08, 1.11, 1.16
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> %Cpu(s):  0.3 us,  0.0 sy, 12.4 ni, 87.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 
> st
> KiB Mem:  16433792 total,  8947336 used,  7486456 free,89552 buffers
> KiB Swap:0 total,

[jira] [Updated] (CASSANDRA-11343) Fix bloom filter sizing with LCS

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan updated CASSANDRA-11343:

Component/s: Compaction

> Fix bloom filter sizing with LCS
> 
>
> Key: CASSANDRA-11343
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11343
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> Since CASSANDRA-7272 we most often over allocate the bloom filter size with 
> LCS



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

[jira] [Commented] (CASSANDRA-10134) Always require replace_address to replace existing address

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10134:
-

Will this disallow genuine (but unsafe) scenarios where you want to manually 
replace a node with the same tokens without going through bootstrap, such as 
when you lost part of the data due to a [JBOD disk 
failure|https://docs.datastax.com/en/cassandra/2.0/cassandra/operations/opsRecoverUsingJBOD.html]?
 If so, we should probably update that doc and/or add yet another flag to 
support those.

> Always require replace_address to replace existing address
> --
>
> Key: CASSANDRA-10134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10134
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Distributed Metadata
>Reporter: Tyler Hobbs
>Assignee: Sam Tunnicliffe
> Fix For: 3.x
>
>
> Normally, when a node is started from a clean state with the same address as 
> an existing down node, it will fail to start with an error like this:
> {noformat}
> ERROR [main] 2015-08-19 15:07:51,577 CassandraDaemon.java:554 - Exception 
> encountered during startup
> java.lang.RuntimeException: A node with address /127.0.0.3 already exists, 
> cancelling join. Use cassandra.replace_address if you want to replace this 
> node.
>   at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:543)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:783)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:720)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:611)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378) 
> [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:537)
>  [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:626) 
> [main/:na]
> {noformat}
> However, if {{auto_bootstrap}} is set to false or the node is in its own seed 
> list, it will not throw this error and will start normally.  The new node 
> then takes over the host ID of the old node (even if the tokens are 
> different), and the only message you will see is a warning in the other 
> nodes' logs:
> {noformat}
> logger.warn("Changing {}'s host ID from {} to {}", endpoint, storedId, 
> hostId);
> {noformat}
> This could cause an operator to accidentally wipe out the token information 
> for a down node without replacing it.  To fix this, we should check for an 
> endpoint collision even if {{auto_bootstrap}} is false or the node is a seed.



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

[jira] [Comment Edited] (CASSANDRA-11172) Infinite loop bug adding high-level SSTableReader in compaction

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson edited comment on CASSANDRA-11172 at 3/23/16 2:33 PM:
--

[~marco.zattoo] I think your problem will be fixed with CASSANDRA-11373 - the 
exception you see will abort the compaction and cause the issues mentioned there


was (Author: krummas):
[~marco.zattoo] I think your problem will be fixed with CASSANDRA-11373

> Infinite loop bug adding high-level SSTableReader in compaction
> ---
>
> Key: CASSANDRA-11172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11172
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: DSE 4.x / Cassandra 2.1.11.969
>Reporter: Jeff Ferland
>Assignee: Marcus Eriksson
> Fix For: 2.1.14, 2.2.6, 3.0.4, 3.4
>
> Attachments: beep.txt, tpstats.txt, tpstats_compaction.txt, 
> trapped_in_compaction.txt, trapped_in_compaction_mixed.txt
>
>
> Observed that after a large repair on LCS that sometimes the system will 
> enter an infinite loop with vast amounts of logs lines recording, "Adding 
> high-level (L${LEVEL}) SSTableReader(path='${TABLE}') to candidates"
> This results in an outage of the node and eventual crashing. The log spam 
> quickly rotates out possibly useful earlier debugging.



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

[jira] [Updated] (CASSANDRA-11373) Cancelled compaction leading to infinite loop in compaction strategy getNextBackgroundTask

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-11373:

Fix Version/s: 2.2.x

> Cancelled compaction leading to infinite loop in compaction strategy 
> getNextBackgroundTask
> --
>
> Key: CASSANDRA-11373
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11373
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Eduard Tudenhoefner
>Assignee: Marcus Eriksson
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: jstack.txt
>
>
> Our test is basically running *nodetool repair* on specific keyspaces (such 
> as keyspace1) and the test is also triggering *nodetool compact keyspace1 
> standard1* in the background. 
> And so it looks like running major compactions & repairs lead to that issue 
> when using *LCS*.
> Below is an excerpt from the *thread dump* (the rest is attached)
> {code}
> "CompactionExecutor:2" #33 daemon prio=1 os_prio=4 tid=0x7f5363e64f10 
> nid=0x3c4e waiting for monitor entry [0x7f53340d8000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:252)
>   - waiting to lock <0x0006c9362c80> (a 
> org.apache.cassandra.db.compaction.CompactionStrategyManager)
>   at 
> org.apache.cassandra.db.lifecycle.Tracker.notifySSTableRepairedStatusChanged(Tracker.java:434)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager.performAnticompaction(CompactionManager.java:550)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$7.runMayThrow(CompactionManager.java:465)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   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)
>Locked ownable synchronizers:
>   - <0x0006c9362ca8> (a 
> java.util.concurrent.ThreadPoolExecutor$Worker)
> "CompactionExecutor:1" #32 daemon prio=1 os_prio=4 tid=0x7f5363e618b0 
> nid=0x3c4d runnable [0x7f5334119000]
>java.lang.Thread.State: RUNNABLE
>   at com.google.common.collect.Iterators$7.computeNext(Iterators.java:650)
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
>   at com.google.common.collect.Iterators.addAll(Iterators.java:361)
>   at com.google.common.collect.Iterables.addAll(Iterables.java:354)
>   at 
> org.apache.cassandra.db.compaction.LeveledManifest.getCandidatesFor(LeveledManifest.java:589)
>   at 
> org.apache.cassandra.db.compaction.LeveledManifest.getCompactionCandidates(LeveledManifest.java:349)
>   - locked <0x0006d0f7a6a8> (a 
> org.apache.cassandra.db.compaction.LeveledManifest)
>   at 
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:98)
>   - locked <0x0006d0f7a568> (a 
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy)
>   at 
> org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:95)
>   - locked <0x0006c9362c80> (a 
> org.apache.cassandra.db.compaction.CompactionStrategyManager)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:257)
>   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}
> *CPU usage is at 100%*
> {code}
> top -p 15386
> top - 12:12:40 up  1:28,  1 user,  load average: 1.08, 1.11, 1.16
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> %Cpu(s):  0.3 us,  0.0 sy, 12.4 ni, 87.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 
> st
> KiB Mem:  16433792 total,  8947336 used,  7486456 free,89552 buffers
> KiB Swap:0 total,0 used,0 

[jira] [Updated] (CASSANDRA-11373) Cancelled compaction leading to infinite loop in compaction strategy getNextBackgroundTask

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-11373:

Summary: Cancelled compaction leading to infinite loop in compaction 
strategy getNextBackgroundTask  (was: nodetool repair might get stalled when 
running major compactions at the same time with LCS)

> Cancelled compaction leading to infinite loop in compaction strategy 
> getNextBackgroundTask
> --
>
> Key: CASSANDRA-11373
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11373
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Eduard Tudenhoefner
>Assignee: Marcus Eriksson
> Fix For: 3.0.x, 3.x
>
> Attachments: jstack.txt
>
>
> Our test is basically running *nodetool repair* on specific keyspaces (such 
> as keyspace1) and the test is also triggering *nodetool compact keyspace1 
> standard1* in the background. 
> And so it looks like running major compactions & repairs lead to that issue 
> when using *LCS*.
> Below is an excerpt from the *thread dump* (the rest is attached)
> {code}
> "CompactionExecutor:2" #33 daemon prio=1 os_prio=4 tid=0x7f5363e64f10 
> nid=0x3c4e waiting for monitor entry [0x7f53340d8000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:252)
>   - waiting to lock <0x0006c9362c80> (a 
> org.apache.cassandra.db.compaction.CompactionStrategyManager)
>   at 
> org.apache.cassandra.db.lifecycle.Tracker.notifySSTableRepairedStatusChanged(Tracker.java:434)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager.performAnticompaction(CompactionManager.java:550)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$7.runMayThrow(CompactionManager.java:465)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   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)
>Locked ownable synchronizers:
>   - <0x0006c9362ca8> (a 
> java.util.concurrent.ThreadPoolExecutor$Worker)
> "CompactionExecutor:1" #32 daemon prio=1 os_prio=4 tid=0x7f5363e618b0 
> nid=0x3c4d runnable [0x7f5334119000]
>java.lang.Thread.State: RUNNABLE
>   at com.google.common.collect.Iterators$7.computeNext(Iterators.java:650)
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
>   at com.google.common.collect.Iterators.addAll(Iterators.java:361)
>   at com.google.common.collect.Iterables.addAll(Iterables.java:354)
>   at 
> org.apache.cassandra.db.compaction.LeveledManifest.getCandidatesFor(LeveledManifest.java:589)
>   at 
> org.apache.cassandra.db.compaction.LeveledManifest.getCompactionCandidates(LeveledManifest.java:349)
>   - locked <0x0006d0f7a6a8> (a 
> org.apache.cassandra.db.compaction.LeveledManifest)
>   at 
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:98)
>   - locked <0x0006d0f7a568> (a 
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy)
>   at 
> org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:95)
>   - locked <0x0006c9362c80> (a 
> org.apache.cassandra.db.compaction.CompactionStrategyManager)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:257)
>   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}
> *CPU usage is at 100%*
> {code}
> top -p 15386
> top - 12:12:40 up  1:28,  1 user,  load average: 1.08, 1.11, 1.16
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> %Cpu(s):  0.3 us,  0.0 sy, 12.4 ni, 

[jira] [Commented] (CASSANDRA-11172) Infinite loop bug adding high-level SSTableReader in compaction

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-11172:
-

[~marco.zattoo] I think your problem will be fixed with CASSANDRA-11373

> Infinite loop bug adding high-level SSTableReader in compaction
> ---
>
> Key: CASSANDRA-11172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11172
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: DSE 4.x / Cassandra 2.1.11.969
>Reporter: Jeff Ferland
>Assignee: Marcus Eriksson
> Fix For: 2.1.14, 2.2.6, 3.0.4, 3.4
>
> Attachments: beep.txt, tpstats.txt, tpstats_compaction.txt, 
> trapped_in_compaction.txt, trapped_in_compaction_mixed.txt
>
>
> Observed that after a large repair on LCS that sometimes the system will 
> enter an infinite loop with vast amounts of logs lines recording, "Adding 
> high-level (L${LEVEL}) SSTableReader(path='${TABLE}') to candidates"
> This results in an outage of the node and eventual crashing. The log spam 
> quickly rotates out possibly useful earlier debugging.



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

[jira] [Commented] (CASSANDRA-11279) dtest failure in disk_balance_test.TestDiskBalance.disk_balance_bootstrap_test

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-11279:
-

[~philipthompson] yeah since we only write 10k keys it could be, can you try it?

> dtest failure in disk_balance_test.TestDiskBalance.disk_balance_bootstrap_test
> --
>
> Key: CASSANDRA-11279
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11279
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Philip Thompson
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1011/testReport/disk_balance_test/TestDiskBalance/disk_balance_bootstrap_test
> Failed on CassCI build trunk_dtest #1011
> This looks likely to be a test issue, perhaps we need to relax the assertion 
> here a bit:
> {noformat}
> values not within 20.00% of the max: (474650, 382235, 513385) (node1)
> {noformat}
> This is flaky with several flaps in the last few weeks.



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

[jira] [Updated] (CASSANDRA-11392) Add auto import java.util for UDF code block

[Robert Stupp (JIRA)]

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

Robert Stupp updated CASSANDRA-11392:
-
Assignee: DOAN DuyHai

> Add auto import java.util for UDF code block
> 
>
> Key: CASSANDRA-11392
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11392
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
> Environment: C* 3.4
>Reporter: DOAN DuyHai
>Assignee: DOAN DuyHai
>Priority: Minor
> Fix For: 3.6
>
> Attachments: patch.txt
>
>
> Right now, when creating Java source code for UDF, since we cannot define 
> import, we need to use fully qualified class name, ex:
> {noformat}
> CREATE FUNCTION toSet(li list)
> CALLED ON NULL INPUT
> RETURNS text
> LANGUAGE java
> AS $$
> java.util.Set set = new java.util.HashSet();
> for(String txt: list) {
> set.add(txt);
> }
> return set;
> $$;
> {noformat}
> Classes from {{java.util}} package are so commonly used that it makes 
> developer life easier to import automatically {{java.util.*}} in the 
> {{JavaUDF}} base class so that developers don't need to use FQCN for common 
> classes.
>  The only drawback I can see is the risk of class name clash but since:
> 1. it is not allow to create new class
> 2. classes that can be used in UDF are restricted
>  I don't see serious clash name issues either
> [~snazy] WDYT ?
>  



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

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

[marcuse]

Merge branch 'cassandra-3.0' into cassandra-3.5


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

Branch: refs/heads/trunk
Commit: f47d9769ffc20c29d611972bddae12c44a4df35f
Parents: 4509934 1d1bfae
Author: Marcus Eriksson 
Authored: Wed Mar 23 15:00:34 2016 +0100
Committer: Marcus Eriksson 
Committed: Wed Mar 23 15:00:34 2016 +0100

--
 CHANGES.txt |  1 +
 .../db/compaction/CompactionManager.java| 49 ++--
 2 files changed, 35 insertions(+), 15 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f47d9769/CHANGES.txt
--
diff --cc CHANGES.txt
index 7d74b6e,cf36047..85fca0f
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,7 -1,7 +1,8 @@@
 -3.0.5
 +3.5
 +Merged from 3.0:
+  * Allocate merkletrees with the correct size (CASSANDRA-11390)
   * Support streaming pre-3.0 sstables (CASSANDRA-10990)
 - * Add backpressure to compressed commit log (CASSANDRA-10971)
 + * Add backpressure to compressed or encrypted commit log (CASSANDRA-10971)
   * SSTableExport supports secondary index tables (CASSANDRA-11330)
   * Fix sstabledump to include missing info in debug output (CASSANDRA-11321)
   * Establish and implement canonical bulk reading workload(s) 
(CASSANDRA-10331)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f47d9769/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
--

[1/6] cassandra git commit: Allocate merkletrees with the correct size

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 d479b8d68 -> 1d1bfae58
  refs/heads/cassandra-3.5 4509934f9 -> f47d9769f
  refs/heads/trunk 03b42a299 -> 9b7d5734e


Allocate merkletrees with the correct size

Patch by marcuse; reviewed by Marcus Olsson for CASSANDRA-11390


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

Branch: refs/heads/cassandra-3.0
Commit: 1d1bfae580d44d3b8a4678c5af5767ff17102128
Parents: d479b8d
Author: Marcus Eriksson 
Authored: Mon Mar 21 15:41:32 2016 +0100
Committer: Marcus Eriksson 
Committed: Wed Mar 23 14:54:39 2016 +0100

--
 CHANGES.txt |  1 +
 .../db/compaction/CompactionManager.java| 49 ++--
 2 files changed, 35 insertions(+), 15 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1d1bfae5/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 904206b..cf36047 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.5
+ * Allocate merkletrees with the correct size (CASSANDRA-11390)
  * Support streaming pre-3.0 sstables (CASSANDRA-10990)
  * Add backpressure to compressed commit log (CASSANDRA-10971)
  * SSTableExport supports secondary index tables (CASSANDRA-11330)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1d1bfae5/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java 
b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
index 891f976..7c46fcb 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
@@ -1078,16 +1078,8 @@ public class CompactionManager implements 
CompactionManagerMBean
 
 // Create Merkle trees suitable to hold estimated partitions for 
the given ranges.
 // We blindly assume that a partition is evenly distributed on all 
sstables for now.
-long numPartitions = 0;
-for (SSTableReader sstable : sstables)
-{
-numPartitions += 
sstable.estimatedKeysForRanges(validator.desc.ranges);
-}
 // determine tree depth from number of partitions, but cap at 20 
to prevent large tree.
-int depth = numPartitions > 0 ? (int) 
Math.min(Math.floor(Math.log(numPartitions)), 20) : 0;
-MerkleTrees tree = new MerkleTrees(cfs.getPartitioner());
-tree.addMerkleTrees((int) Math.pow(2, depth), 
validator.desc.ranges);
-
+MerkleTrees tree = createMerkleTrees(sstables, 
validator.desc.ranges, cfs);
 long start = System.nanoTime();
 try (AbstractCompactionStrategy.ScannerList scanners = 
cfs.getCompactionStrategyManager().getScanners(sstables, validator.desc.ranges);
  ValidationCompactionController controller = new 
ValidationCompactionController(cfs, gcBefore);
@@ -1114,15 +1106,11 @@ public class CompactionManager implements 
CompactionManagerMBean
 }
 }
 
-if (logger.isTraceEnabled())
+if (logger.isDebugEnabled())
 {
-// MT serialize may take time
 long duration = 
TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - start);
-logger.trace("Validation finished in {} msec, depth {} for {} 
keys, serialized size {} bytes for {}",
+logger.debug("Validation finished in {} msec, for {}",
  duration,
- depth,
- numPartitions,
- MerkleTrees.serializer.serializedSize(tree, 0),
  validator.desc);
 }
 }
@@ -1133,6 +1121,37 @@ public class CompactionManager implements 
CompactionManagerMBean
 }
 }
 
+private static MerkleTrees createMerkleTrees(Iterable 
sstables, Collection ranges, ColumnFamilyStore cfs)
+{
+MerkleTrees tree = new MerkleTrees(cfs.getPartitioner());
+long allPartitions = 0;
+Map rangePartitionCounts = new HashMap<>();
+for (Range range : ranges)
+{
+long numPartitions = 0;
+for (SSTableReader sstable : sstables)
+numPartitions += 
sstable.estimatedKeysForRanges(Collections.singleton(range));
+rangePartitionCounts.put(range, 

[3/6] cassandra git commit: Allocate merkletrees with the correct size

[marcuse]

Allocate merkletrees with the correct size

Patch by marcuse; reviewed by Marcus Olsson for CASSANDRA-11390


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

Branch: refs/heads/trunk
Commit: 1d1bfae580d44d3b8a4678c5af5767ff17102128
Parents: d479b8d
Author: Marcus Eriksson 
Authored: Mon Mar 21 15:41:32 2016 +0100
Committer: Marcus Eriksson 
Committed: Wed Mar 23 14:54:39 2016 +0100

--
 CHANGES.txt |  1 +
 .../db/compaction/CompactionManager.java| 49 ++--
 2 files changed, 35 insertions(+), 15 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1d1bfae5/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 904206b..cf36047 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.5
+ * Allocate merkletrees with the correct size (CASSANDRA-11390)
  * Support streaming pre-3.0 sstables (CASSANDRA-10990)
  * Add backpressure to compressed commit log (CASSANDRA-10971)
  * SSTableExport supports secondary index tables (CASSANDRA-11330)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1d1bfae5/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java 
b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
index 891f976..7c46fcb 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
@@ -1078,16 +1078,8 @@ public class CompactionManager implements 
CompactionManagerMBean
 
 // Create Merkle trees suitable to hold estimated partitions for 
the given ranges.
 // We blindly assume that a partition is evenly distributed on all 
sstables for now.
-long numPartitions = 0;
-for (SSTableReader sstable : sstables)
-{
-numPartitions += 
sstable.estimatedKeysForRanges(validator.desc.ranges);
-}
 // determine tree depth from number of partitions, but cap at 20 
to prevent large tree.
-int depth = numPartitions > 0 ? (int) 
Math.min(Math.floor(Math.log(numPartitions)), 20) : 0;
-MerkleTrees tree = new MerkleTrees(cfs.getPartitioner());
-tree.addMerkleTrees((int) Math.pow(2, depth), 
validator.desc.ranges);
-
+MerkleTrees tree = createMerkleTrees(sstables, 
validator.desc.ranges, cfs);
 long start = System.nanoTime();
 try (AbstractCompactionStrategy.ScannerList scanners = 
cfs.getCompactionStrategyManager().getScanners(sstables, validator.desc.ranges);
  ValidationCompactionController controller = new 
ValidationCompactionController(cfs, gcBefore);
@@ -1114,15 +1106,11 @@ public class CompactionManager implements 
CompactionManagerMBean
 }
 }
 
-if (logger.isTraceEnabled())
+if (logger.isDebugEnabled())
 {
-// MT serialize may take time
 long duration = 
TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - start);
-logger.trace("Validation finished in {} msec, depth {} for {} 
keys, serialized size {} bytes for {}",
+logger.debug("Validation finished in {} msec, for {}",
  duration,
- depth,
- numPartitions,
- MerkleTrees.serializer.serializedSize(tree, 0),
  validator.desc);
 }
 }
@@ -1133,6 +1121,37 @@ public class CompactionManager implements 
CompactionManagerMBean
 }
 }
 
+private static MerkleTrees createMerkleTrees(Iterable 
sstables, Collection ranges, ColumnFamilyStore cfs)
+{
+MerkleTrees tree = new MerkleTrees(cfs.getPartitioner());
+long allPartitions = 0;
+Map rangePartitionCounts = new HashMap<>();
+for (Range range : ranges)
+{
+long numPartitions = 0;
+for (SSTableReader sstable : sstables)
+numPartitions += 
sstable.estimatedKeysForRanges(Collections.singleton(range));
+rangePartitionCounts.put(range, numPartitions);
+allPartitions += numPartitions;
+}
+
+for (Range range : ranges)
+{
+long numPartitions = rangePartitionCounts.get(range);
+