[jira] [Commented] (CASSANDRA-10995) Consider disabling sstable compression by default in 3.x

[Jim Witschey (JIRA)]

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

Jim Witschey commented on CASSANDRA-10995:
--

One problem we currently have with benchmarking on-disk data size, in 
particular w.r.t. compression, is this: we don't have tools that will generate 
representative, compressible data. It's easy to generate random data 
({{UUID}}s, random strings from {{cassandra-stress}}).

[~iamaleksey] How important is it that we use such a dataset? You'd know better 
than I, but I don't imagine compressibility would effect resource utilization 
other than disk much.

> Consider disabling sstable compression by default in 3.x
> 
>
> Key: CASSANDRA-10995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10995
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Jim Witschey
>
> With the new sstable format introduced in CASSANDRA-8099, it's very likely 
> that enabled sstable compression is no longer the right default option.
> [~slebresne]'s [blog post|http://www.datastax.com/2015/12/storage-engine-30] 
> on the new storage engine has some comparison numbers for 2.2/3.0, with and 
> without compression that show that in many cases compression no longer has a 
> significant effect on sstable sizes - all while sill consuming extra 
> resources for both writes (compression) and reads (decompression).
> We should run a comprehensive set of benchmarks to determine whether or not 
> compression should be switched to 'off' now in 3.x.



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

[jira] [Updated] (CASSANDRA-9012) Triage missing test coverage

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-9012:
--
Assignee: (was: Ariel Weisberg)

> Triage missing test coverage
> 
>
> Key: CASSANDRA-9012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9012
> Project: Cassandra
>  Issue Type: Task
>  Components: Testing
>Reporter: Ariel Weisberg
>  Labels: monthly-release
>
> Review, sort, prioritize. Discuss resulting order and refine as necessary. 



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

[jira] [Updated] (CASSANDRA-9009) Identify, triage, and address missing test coverage

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-9009:
--
Assignee: (was: Ariel Weisberg)

> Identify, triage, and address missing test coverage
> ---
>
> Key: CASSANDRA-9009
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9009
> Project: Cassandra
>  Issue Type: Task
>  Components: Testing
>Reporter: Ariel Weisberg
>  Labels: monthly-release
>
> Identify what is covered and how 
> Triage for priority and what we are going to address explicitly rather then 
> addressing incrementally over time as developers touch the code.
> Create and link JIRAs for adding coverage



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

[jira] [Updated] (CASSANDRA-8152) Cassandra crashes with Native memory allocation failure

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-8152:
--
 Assignee: (was: Ariel Weisberg)
Reproduced In: 2.1.2, 2.1.0  (was: 2.1.0, 2.1.2)

> Cassandra crashes with Native memory allocation failure
> ---
>
> Key: CASSANDRA-8152
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8152
> Project: Cassandra
>  Issue Type: Bug
> Environment: EC2 (i2.xlarge)
>Reporter: Babar Tareen
>Priority: Minor
> Attachments: db06_hs_err_pid26159.log.zip, 
> db_05_hs_err_pid25411.log.zip
>
>
> On a 6 node Cassandra (datastax-community-2.1) cluster running on EC2 
> (i2.xlarge) instances, Jvm hosting the cassandra service randomly crashes 
> with following error.
> {code}
> #
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (malloc) failed to allocate 12288 bytes for 
> committing reserved memory.
> # Possible reasons:
> #   The system is out of physical RAM or swap space
> #   In 32 bit mode, the process size limit was hit
> # Possible solutions:
> #   Reduce memory load on the system
> #   Increase physical memory or swap space
> #   Check if swap backing store is full
> #   Use 64 bit Java on a 64 bit OS
> #   Decrease Java heap size (-Xmx/-Xms)
> #   Decrease number of Java threads
> #   Decrease Java thread stack sizes (-Xss)
> #   Set larger code cache with -XX:ReservedCodeCacheSize=
> # This output file may be truncated or incomplete.
> #
> #  Out of Memory Error (os_linux.cpp:2747), pid=26159, tid=140305605682944
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_60-b19) (build 
> 1.7.0_60-b19)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.60-b09 mixed mode 
> linux-amd64 compressed oops)
> # Failed to write core dump. Core dumps have been disabled. To enable core 
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> ---  T H R E A D  ---
> Current thread (0x08341000):  JavaThread "MemtableFlushWriter:2055" 
> daemon [_thread_new, id=23336, stack(0x7f9b71c56000,0x7f9b71c97000)]
> Stack: [0x7f9b71c56000,0x7f9b71c97000],  sp=0x7f9b71c95820,  free 
> space=254k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> V  [libjvm.so+0x99e7ca]  VMError::report_and_die()+0x2ea
> V  [libjvm.so+0x496fbb]  report_vm_out_of_memory(char const*, int, unsigned 
> long, char const*)+0x9b
> V  [libjvm.so+0x81d81e]  os::Linux::commit_memory_impl(char*, unsigned long, 
> bool)+0xfe
> V  [libjvm.so+0x81d8dc]  os::pd_commit_memory(char*, unsigned long, bool)+0xc
> V  [libjvm.so+0x81565a]  os::commit_memory(char*, unsigned long, bool)+0x2a
> V  [libjvm.so+0x81bdcd]  os::pd_create_stack_guard_pages(char*, unsigned 
> long)+0x6d
> V  [libjvm.so+0x9522de]  JavaThread::create_stack_guard_pages()+0x5e
> V  [libjvm.so+0x958c24]  JavaThread::run()+0x34
> V  [libjvm.so+0x81f7f8]  java_start(Thread*)+0x108
> {code}
> Changes in cassandra-env.sh settings
> {code}
> MAX_HEAP_SIZE="8G"
> HEAP_NEWSIZE="800M"
> JVM_OPTS="$JVM_OPTS -XX:TargetSurvivorRatio=50"
> JVM_OPTS="$JVM_OPTS -XX:+AggressiveOpts"
> JVM_OPTS="$JVM_OPTS -XX:+UseLargePages"
> {code}
> Writes are about 10K-15K/sec and there are very few reads. Cassandra 2.0.9 
> with same settings never crashed. JVM crash logs are attached from two 
> machines.



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

[jira] [Updated] (CASSANDRA-9042) Make trunk always releasable

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-9042:
--
Assignee: (was: Ariel Weisberg)

> Make trunk always releasable
> 
>
> Key: CASSANDRA-9042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9042
> Project: Cassandra
>  Issue Type: Task
>Reporter: Ariel Weisberg
>




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

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

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-9259:
--
Assignee: (was: Ariel Weisberg)

> 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
>Priority: Critical
> Fix For: 3.x
>
>
> 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 optimized for a particular query).  Then, 
> Cassandra can choose to leverage this alternate storage for particular CQL 
> queries (e.g., range scans).
> These are just 2 suggestions to get the conversation going.
> One thing to note is that it will be useful to have this storage segregated 
> by token range so that when you extract via these mechanisms you do not get 
> replications-factor numbers of copies of the data.  That will certainly be an 
> issue for some Spark operations (e.g., counting).  Thus, we will want 
> per-token-range storage (even for single disks), so this will likely leverage 
> CASSANDRA-6696 (though, we'll want to also consider the single disk case).
> It is also worth discussing what the success criteria is here.  It is 
> unlikely to be as fast as EDW or HDFS performance (though, that is still a 
> good goal), but being within some percentage of that performance should be 
> set as success.  For example, 2x as long as doing bulk operations on HDFS 
> with similar node count/size/etc.



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

[jira] [Commented] (CASSANDRA-10961) Not enough bytes error when add nodes to cluster

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10961:
-

Attached patches for 2.1, 2.2, 3.0, 3.3 and trunk.  There were merge conflicts 
on 3.0 and 3.3 (trunk merges fine from 3.3). I didn't squash commits to 
simplify potential conflict resolutions. Although the problem does not happen 
in 2.1, I added a 2.1 branch to revert CASSANDRA-10012 and improve debug 
messages (commit at your own will).

Test results will appear shortly below:
||2.1||2.2||3.0||3.3||trunk||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...pauloricardomg:2.1-10961]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...pauloricardomg:2.2-10961]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:3.0-10961]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.3...pauloricardomg:3.3-10961]|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:trunk-10961]|
|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.1-10961-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-10961-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-10961-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.3-10961-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-10961-testall/lastCompletedBuild/testReport/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.1-10961-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-10961-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-10961-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.3-10961-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-10961-dtest/lastCompletedBuild/testReport/]|


> Not enough bytes error when add nodes to cluster
> 
>
> Key: CASSANDRA-10961
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10961
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: xiaost
>Assignee: Paulo Motta
> Attachments: apache-cassandra-2.2.4-SNAPSHOT.jar, debug.1.log, 
> debug.logs.zip, netstats.1.log
>
>
> we got the same problem all the time when we add nodes to cluster.
> netstats:
> on HostA
> {noformat}
> /la-38395-big-Data.db 14792091851/14792091851 bytes(100%) sent to idx:0/HostB
> {noformat}
> on HostB
> {noformat}
> tmp-la-4-big-Data.db 2667087450/14792091851 bytes(18%) received from 
> idx:0/HostA
> {noformat}
> After a while, Error on HostB
> {noformat}
> WARN  [STREAM-IN-/HostA] 2016-01-02 12:08:14,737 StreamSession.java:644 - 
> [Stream #b91a4e90-b105-11e5-bd57-dd0cc3b4634c] Retrying for following error
> java.lang.IllegalArgumentException: Not enough bytes
> at 
> org.apache.cassandra.db.composites.AbstractCType.checkRemaining(AbstractCType.java:362)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.db.composites.AbstractCompoundCellNameType.fromByteBuffer(AbstractCompoundCellNameType.java:98)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:381)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:365)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:75)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52) 
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46) 
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>  ~[guava-16.0.jar:na]
> at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) 
> ~[guava-16.0.jar:na]
> at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.appendFromStream(BigTableWriter.java:243)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> 

[jira] [Resolved] (CASSANDRA-10963) Bootstrap stream fails with java.lang.InterruptedException

[Paulo Motta (JIRA)]

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

Paulo Motta resolved CASSANDRA-10963.
-
   Resolution: Duplicate
Reproduced In:   (was: 2.2.4)

> Bootstrap stream fails with java.lang.InterruptedException 
> ---
>
> Key: CASSANDRA-10963
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10963
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: [cqlsh 5.0.1 | Cassandra 2.2.4 | CQL spec 3.3.1 | Native 
> protocol v4]
> java version "1.8.0_65"
>Reporter: Jack Money
>Assignee: Paulo Motta
>
> hello
> I got 2 nodes in 2 DC.
> Each node own 100% data of keyspace hugespace.
> Keyspace have 21 tables with 2TB data
> Biggest table have 1.6 TB of data.
> Biggest sstable 1,3 TB.
> Schemats:
> {noformat} 
> KEYSPACE hugespace WITH replication = {'class': 'NetworkTopologyStrategy', 
> 'DC1': '3', 'DC2': '1'};
> CREATE TABLE hugespace.content (
> y int,
> m int,
> d int,
> ts bigint,
> ha text,
> co text,
> he text,
> ids bigint,
> ifr text,
> js text,
> PRIMARY KEY ((y, m, d), ts, ha)
> ) WITH CLUSTERING ORDER BY (ts ASC, ha ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
> AND compression = {'sstable_compression': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';
> CREATE INDEX content_ids_idx ON hugespace.content (ids);
> {noformat}
> I tried to add one node (target 6 node in DC1) to DC1.
> Names:
> Existing node in DC1 = nodeDC1
> Existing node in DC2 = nodeDC2
> New node joining DC1 = joiningDC1
> joiningDC1
> {noformat} 
> INFO  [main] 2016-01-04 12:17:55,535 StorageService.java:1176 - JOINING: 
> Starting to bootstrap...
> INFO  [main] 2016-01-04 12:17:55,802 StreamResultFuture.java:86 - [Stream 
> #2f473320-b2dd-11e5-8353-b5506ad414a4] Executing streaming plan for Bootstrap
> INFO  [StreamConnectionEstablisher:1] 2016-01-04 12:17:55,803 
> StreamSession.java:232 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Starting streaming to /nodeDC1
> INFO  [StreamConnectionEstablisher:2] 2016-01-04 12:17:55,803 
> StreamSession.java:232 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Starting streaming to /nodeDC2
> DEBUG [StreamConnectionEstablisher:2] 2016-01-04 12:17:55,803 
> ConnectionHandler.java:82 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Sending stream init for incoming stream
> DEBUG [StreamConnectionEstablisher:1] 2016-01-04 12:17:55,803 
> ConnectionHandler.java:82 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Sending stream init for incoming stream
> DEBUG [StreamConnectionEstablisher:1] 2016-01-04 12:17:55,806 
> ConnectionHandler.java:87 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Sending stream init for outgoing stream
> DEBUG [StreamConnectionEstablisher:2] 2016-01-04 12:17:55,806 
> ConnectionHandler.java:87 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Sending stream init for outgoing stream
> DEBUG [STREAM-OUT-/nodeDC1] 2016-01-04 12:17:55,810 
> ConnectionHandler.java:334 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Sending Prepare (5 requests,  0 files}
> DEBUG [STREAM-OUT-/nodeDC2] 2016-01-04 12:17:55,810 
> ConnectionHandler.java:334 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Sending Prepare (2 requests,  0 files}
> INFO  [StreamConnectionEstablisher:2] 2016-01-04 12:17:55,810 
> StreamCoordinator.java:213 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4, 
> ID#0] Beginning stream session with /nodeDC2
> INFO  [StreamConnectionEstablisher:1] 2016-01-04 12:17:55,810 
> StreamCoordinator.java:213 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4, 
> ID#0] Beginning stream session with /nodeDC1
> DEBUG [STREAM-IN-/nodeDC2] 2016-01-04 12:17:55,821 ConnectionHandler.java:266 
> - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] Received Prepare (0 
> requests,  1 files}
> INFO  [STREAM-IN-/nodeDC2] 2016-01-04 12:17:55,822 
> StreamResultFuture.java:168 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4 
> ID#0] Prepare completed. Receiving 1 files(161 bytes), sending 0 files(0 
> bytes)
> DEBUG [STREAM-IN-/nodeDC2] 2016-01-04 12:17:55,828 
> CompressedStreamReader.java:67 - reading file from /nodeDC2, repairedAt = 
> 1451483586917
> DEBUG [STREAM-IN-/nodeDC2] 2016-01-04 12:17:55,831 

[jira] [Updated] (CASSANDRA-10320) Build off-heap key-cache compatible API

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-10320:
---
Reviewer:   (was: Ariel Weisberg)

> Build off-heap key-cache compatible API
> ---
>
> Key: CASSANDRA-10320
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10320
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> (Follow-up to CASSANDRA-10314 and prerequisite for the final goal 
> CASSANDRA-9738.)
> Ticket is about to extract the API code changes from CASSANDRA-9738 as a 
> sub-task - so everything from CASSANDRA-9738 without the actual off-heap 
> implementation.



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

[jira] [Updated] (CASSANDRA-9738) Migrate key-cache to be fully off-heap

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-9738:
--
Reviewer:   (was: Ariel Weisberg)

> Migrate key-cache to be fully off-heap
> --
>
> Key: CASSANDRA-9738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9738
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> Key cache still uses a concurrent map on-heap. This could go to off-heap and 
> feels doable now after CASSANDRA-8099.
> Evaluation should be done in advance based on a POC to prove that pure 
> off-heap counter cache buys a performance and/or gc-pressure improvement.
> In theory, elimination of on-heap management of the map should buy us some 
> benefit.



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

[jira] [Commented] (CASSANDRA-10963) Bootstrap stream fails with java.lang.InterruptedException

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10963:
-

Closing as duplicate of CASSANDRA-10961, please reopen if that's not the case.

> Bootstrap stream fails with java.lang.InterruptedException 
> ---
>
> Key: CASSANDRA-10963
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10963
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: [cqlsh 5.0.1 | Cassandra 2.2.4 | CQL spec 3.3.1 | Native 
> protocol v4]
> java version "1.8.0_65"
>Reporter: Jack Money
>Assignee: Paulo Motta
>
> hello
> I got 2 nodes in 2 DC.
> Each node own 100% data of keyspace hugespace.
> Keyspace have 21 tables with 2TB data
> Biggest table have 1.6 TB of data.
> Biggest sstable 1,3 TB.
> Schemats:
> {noformat} 
> KEYSPACE hugespace WITH replication = {'class': 'NetworkTopologyStrategy', 
> 'DC1': '3', 'DC2': '1'};
> CREATE TABLE hugespace.content (
> y int,
> m int,
> d int,
> ts bigint,
> ha text,
> co text,
> he text,
> ids bigint,
> ifr text,
> js text,
> PRIMARY KEY ((y, m, d), ts, ha)
> ) WITH CLUSTERING ORDER BY (ts ASC, ha ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
> AND compression = {'sstable_compression': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';
> CREATE INDEX content_ids_idx ON hugespace.content (ids);
> {noformat}
> I tried to add one node (target 6 node in DC1) to DC1.
> Names:
> Existing node in DC1 = nodeDC1
> Existing node in DC2 = nodeDC2
> New node joining DC1 = joiningDC1
> joiningDC1
> {noformat} 
> INFO  [main] 2016-01-04 12:17:55,535 StorageService.java:1176 - JOINING: 
> Starting to bootstrap...
> INFO  [main] 2016-01-04 12:17:55,802 StreamResultFuture.java:86 - [Stream 
> #2f473320-b2dd-11e5-8353-b5506ad414a4] Executing streaming plan for Bootstrap
> INFO  [StreamConnectionEstablisher:1] 2016-01-04 12:17:55,803 
> StreamSession.java:232 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Starting streaming to /nodeDC1
> INFO  [StreamConnectionEstablisher:2] 2016-01-04 12:17:55,803 
> StreamSession.java:232 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Starting streaming to /nodeDC2
> DEBUG [StreamConnectionEstablisher:2] 2016-01-04 12:17:55,803 
> ConnectionHandler.java:82 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Sending stream init for incoming stream
> DEBUG [StreamConnectionEstablisher:1] 2016-01-04 12:17:55,803 
> ConnectionHandler.java:82 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Sending stream init for incoming stream
> DEBUG [StreamConnectionEstablisher:1] 2016-01-04 12:17:55,806 
> ConnectionHandler.java:87 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Sending stream init for outgoing stream
> DEBUG [StreamConnectionEstablisher:2] 2016-01-04 12:17:55,806 
> ConnectionHandler.java:87 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Sending stream init for outgoing stream
> DEBUG [STREAM-OUT-/nodeDC1] 2016-01-04 12:17:55,810 
> ConnectionHandler.java:334 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Sending Prepare (5 requests,  0 files}
> DEBUG [STREAM-OUT-/nodeDC2] 2016-01-04 12:17:55,810 
> ConnectionHandler.java:334 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] 
> Sending Prepare (2 requests,  0 files}
> INFO  [StreamConnectionEstablisher:2] 2016-01-04 12:17:55,810 
> StreamCoordinator.java:213 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4, 
> ID#0] Beginning stream session with /nodeDC2
> INFO  [StreamConnectionEstablisher:1] 2016-01-04 12:17:55,810 
> StreamCoordinator.java:213 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4, 
> ID#0] Beginning stream session with /nodeDC1
> DEBUG [STREAM-IN-/nodeDC2] 2016-01-04 12:17:55,821 ConnectionHandler.java:266 
> - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4] Received Prepare (0 
> requests,  1 files}
> INFO  [STREAM-IN-/nodeDC2] 2016-01-04 12:17:55,822 
> StreamResultFuture.java:168 - [Stream #2f473320-b2dd-11e5-8353-b5506ad414a4 
> ID#0] Prepare completed. Receiving 1 files(161 bytes), sending 0 files(0 
> bytes)
> DEBUG [STREAM-IN-/nodeDC2] 2016-01-04 12:17:55,828 
> CompressedStreamReader.java:67 - reading file from /nodeDC2, repairedAt = 
> 1451483586917
> DEBUG 

[jira] [Commented] (CASSANDRA-10496) Make DTCS split partitions based on time during compaction

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-10496:


[~krummas] - why not make 3 resulting sstables - one earlier, one later, and 
one exactly on target? The marginal cost of the third sstable seems pretty 
minor. The benefit seems relatively significant? 


> Make DTCS split partitions based on time during compaction
> --
>
> Key: CASSANDRA-10496
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10496
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>  Labels: dtcs
> Fix For: 3.x
>
>
> To avoid getting old data in new time windows with DTCS (or related, like 
> [TWCS|CASSANDRA-9666]), we need to split out old data into its own sstable 
> during compaction.
> My initial idea is to just create two sstables, when we create the compaction 
> task we state the start and end times for the window, and any data older than 
> the window will be put in its own sstable.
> By creating a single sstable with old data, we will incrementally get the 
> windows correct - say we have an sstable with these timestamps:
> {{[100, 99, 98, 97, 75, 50, 10]}}
> and we are compacting in window {{[100, 80]}} - we would create two sstables:
> {{[100, 99, 98, 97]}}, {{[75, 50, 10]}}, and the first window is now 
> 'correct'. The next compaction would compact in window {{[80, 60]}} and 
> create sstables {{[75]}}, {{[50, 10]}} etc.
> We will probably also want to base the windows on the newest data in the 
> sstables so that we actually have older data than the window.



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

[jira] [Created] (CASSANDRA-11000) Mixing LWT and non-LWT operations can result in an LWT operation being acknowledged but not applied

[Sebastian Marsching (JIRA)]

Sebastian Marsching created CASSANDRA-11000:
---

 Summary: Mixing LWT and non-LWT operations can result in an LWT 
operation being acknowledged but not applied
 Key: CASSANDRA-11000
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11000
 Project: Cassandra
  Issue Type: Bug
  Components: Coordination
 Environment: Cassandra 2.1, 2.2, and 3.0 on Linux and OS X.
Reporter: Sebastian Marsching


When mixing light-weight transaction (LWT, a.k.a. compare-and-set, conditional 
update) operations with regular operations, it can happen that an LWT operation 
is acknowledged (applied = True), even though the update has not been applied 
and a SELECT operation still returns the old data.

For example, consider the following table:

CREATE TABLE test (
pk text,
ck text,
v text,
PRIMARY KEY (pk, ck)
);

We start with an empty table and insert data using a regular (non-LWT) 
operation:

INSERT INTO test (pk, ck, v) VALUES ('foo', 'bar', '123');

A following SELECT statement returns the data as expected. Now we do a 
conditional update (LWT):

UPDATE test SET v = '456' WHERE pk = 'foo' AND ck = 'bar' IF v = '123';

As expected, the update is applied and a following SELECT statement shows the 
updated value.

Now we do the same but use a time stamp that is slightly in the future (e.g. a 
few seconds) for the INSERT statement (obviously $time$ needs to be replaced by 
a time stamp that is slightly ahead of the system clock).

INSERT INTO test (pk, ck, v) VALUES ('foo', 'bar', '123') USING TIMESTAMP 
$time$;

Now, running the same UPDATE statement still report success (applied = True). 
However, a subsequent SELECT yields the old value ('123') instead of the 
updated value ('456'). Inspecting the time stamp of the value indicates that it 
has not been replaced (the value from the original INSERT is still in place).

This behavior is exhibited in an single-node cluster running Cassandra 2.1.11, 
2.2.4, and 3.0.1.

Testing this for a multi-node cluster is a bit more tricky, so I only tested it 
with Cassandra 2.2.4. Here, I made one of the nodes lack behind in time for a 
few seconds (using libfaketime). I used a replication factor of three for the 
test keyspace. In this case, the behavior can be demonstrated even without 
using an explicitly specified time stamp. Running

INSERT INTO test (pk, ck, v) VALUES ('foo', 'bar', '123');

on a node with the regular clock followed by

UPDATE test SET v = '456' WHERE pk = 'foo' AND ck = 'bar' IF v = '123';

on the node lagging behind results in the UPDATE to report success, but the old 
value still being used.

Interestingly, everything works as expected if using LWT operations 
consistently: When running

UPDATE test SET v = '456' WHERE pk = 'foo' AND ck = 'bar' IF v = '123';
UPDATE test SET v = '123' WHERE pk = 'foo' AND ck = 'bar' IF v = '456';

in an alternating fashion on two nodes (one with a "normal" clock, one with the 
clock lagging behind), the updates are applied as expected. When checking the 
time stamps ("SELECT WRITETIME(v) FROM test;"), one can see that the time stamp 
is increased by just a single tick when the statement is executed on the node 
lagging behind.

I think that this problem is strongly related to (or maybe even the same as) 
the one described in CASSANDRA-7801, even though CASSANDRA-7801 was mainly 
concerned about a single-node cluster. However, the fact that this problem 
still exists in current versions of Cassandra makes me suspect that either it 
is a different problem or the original problem was not fixed completely with 
the patch from CASSANDRA-7801.

I found CASSANDRA-9655 which suggest removing the changes introduced with 
CASSANDRA-7801 because they can be problematic under certain circumstances, but 
I am not sure whether this is the right place to discuss the issue I am 
experiencing. If you feel so, feel free to close this issue and update the 
description of CASSANDRA-9655.

In my opinion, the best way to fix this problem would be ensuring that a write 
that is part of a LWT always uses a time stamp that is at least one tick 
greater than the time stamp of the existing data. As the existing data has to 
be read for checking the condition anyway, I do not think that this would cause 
an additional overhead. If this is not possible, I suggest to look into whether 
we can somehow detect such a situation and at least report failure (applied = 
False) on the LWT instead of reporting success.

The latter solution would at least fix those cases where code checks the 
success of a LWT before performing any further actions (e.g. because the LWT is 
used to take some kind of lock). Currently, the code will assume that the 
operation was successful (and thus - staying in the example - it owns the 
lock), while other processes running in parallel will see a different state. It 
is my 

[jira] [Updated] (CASSANDRA-10660) Support user-defined compactions through nodetool

[Yuki Morishita (JIRA)]

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

Yuki Morishita updated CASSANDRA-10660:
---
Labels: docs-impacting lhf  (was: lhf)

> Support user-defined compactions through nodetool
> -
>
> Key: CASSANDRA-10660
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10660
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Jeff Jirsa
>Priority: Minor
>  Labels: docs-impacting, lhf
> Fix For: 3.x
>
>
> For a long time, we've supported running user-defined compactions through 
> JMX.  This comes in handy fairly often, mostly when dealing with low disk 
> space or tombstone purging, so it would be good to add something to nodetool 
> for this.  An extra option for {{nodetool compact}} would probably suffice.



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

[jira] [Commented] (CASSANDRA-10995) Consider disabling sstable compression by default in 3.x

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10995:
---

We don't want to measure just on-disk size. I want to see number for reads even 
more.

To make a decision as big as this, having representative compressible datasets 
(alongside non-compressible ones) is pretty important. But we could start with 
what we can generate easily and go from there.

> Consider disabling sstable compression by default in 3.x
> 
>
> Key: CASSANDRA-10995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10995
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Jim Witschey
>
> With the new sstable format introduced in CASSANDRA-8099, it's very likely 
> that enabled sstable compression is no longer the right default option.
> [~slebresne]'s [blog post|http://www.datastax.com/2015/12/storage-engine-30] 
> on the new storage engine has some comparison numbers for 2.2/3.0, with and 
> without compression that show that in many cases compression no longer has a 
> significant effect on sstable sizes - all while sill consuming extra 
> resources for both writes (compression) and reads (decompression).
> We should run a comprehensive set of benchmarks to determine whether or not 
> compression should be switched to 'off' now in 3.x.



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

[jira] [Assigned] (CASSANDRA-10528) Proposal: Integrate RxJava

[T Jake Luciani (JIRA)]

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

T Jake Luciani reassigned CASSANDRA-10528:
--

Assignee: T Jake Luciani

> Proposal: Integrate RxJava
> --
>
> Key: CASSANDRA-10528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10528
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
> Fix For: 3.x
>
> Attachments: rxjava-stress.png
>
>
> The purpose of this ticket is to discuss the merits of integrating the 
> [RxJava|https://github.com/ReactiveX/RxJava] framework into C*.  Enabling us 
> to incrementally make the internals of C* async and move away from SEDA to a 
> more modern thread per core architecture. 
> Related tickets:
>* CASSANDRA-8520
>* CASSANDRA-8457
>* CASSANDRA-5239
>* CASSANDRA-7040
>* CASSANDRA-5863
>* CASSANDRA-6696
>* CASSANDRA-7392
> My *primary* goals in raising this issue are to provide a way of:
> *  *Incrementally* making the backend async
> *  Avoiding code complexity/readability issues
> *  Avoiding NIH where possible
> *  Building on an extendable library
> My *non*-goals in raising this issue are:
> 
>* Rewrite the entire database in one big bang
>* Write our own async api/framework
> 
> -
> I've attempted to integrate RxJava a while back and found it not ready mainly 
> due to our lack of lambda support.  Now with Java 8 I've found it very 
> enjoyable and have not hit any performance issues. A gentle introduction to 
> RxJava is [here|http://blog.danlew.net/2014/09/15/grokking-rxjava-part-1/] as 
> well as their 
> [wiki|https://github.com/ReactiveX/RxJava/wiki/Additional-Reading].  The 
> primary concept of RX is the 
> [Obervable|http://reactivex.io/documentation/observable.html] which is 
> essentially a stream of stuff you can subscribe to and act on, chain, etc. 
> This is quite similar to [Java 8 streams 
> api|http://www.oracle.com/technetwork/articles/java/ma14-java-se-8-streams-2177646.html]
>  (or I should say streams api is similar to it).  The difference is java 8 
> streams can't be used for asynchronous events while RxJava can.
> Another improvement since I last tried integrating RxJava is the completion 
> of CASSANDRA-8099 which provides is a very iterable/incremental approach to 
> our storage engine.  *Iterators and Observables are well paired conceptually 
> so morphing our current Storage engine to be async is much simpler now.*
> In an effort to show how one can incrementally change our backend I've done a 
> quick POC with RxJava and replaced our non-paging read requests to become 
> non-blocking.
> https://github.com/apache/cassandra/compare/trunk...tjake:rxjava-3.0
> As you can probably see the code is straight-forward and sometimes quite nice!
> *Old*
> {code}
> private static PartitionIterator 
> fetchRows(List commands, ConsistencyLevel 
> consistencyLevel)
> throws UnavailableException, ReadFailureException, ReadTimeoutException
> {
> int cmdCount = commands.size();
> SinglePartitionReadLifecycle[] reads = new 
> SinglePartitionReadLifecycle[cmdCount];
> for (int i = 0; i < cmdCount; i++)
> reads[i] = new SinglePartitionReadLifecycle(commands.get(i), 
> consistencyLevel);
> for (int i = 0; i < cmdCount; i++)
> reads[i].doInitialQueries();
> for (int i = 0; i < cmdCount; i++)
> reads[i].maybeTryAdditionalReplicas();
> for (int i = 0; i < cmdCount; i++)
> reads[i].awaitRes
> ultsAndRetryOnDigestMismatch();
> for (int i = 0; i < cmdCount; i++)
> if (!reads[i].isDone())
> reads[i].maybeAwaitFullDataRead();
> List results = new ArrayList<>(cmdCount);
> for (int i = 0; i < cmdCount; i++)
> {
> assert reads[i].isDone();
> results.add(reads[i].getResult());
> }
> return PartitionIterators.concat(results);
> }
> {code}
>  *New*
> {code}
> private static Observable 
> fetchRows(List commands, ConsistencyLevel 
> consistencyLevel)
> throws UnavailableException, ReadFailureException, ReadTimeoutException
> {
> return Observable.from(commands)
>  .map(command -> new 
> SinglePartitionReadLifecycle(command, consistencyLevel))
>  .flatMap(read -> read.getPartitionIterator())
>  .toList()
>  .map(results -> PartitionIterators.concat(results));
> }
> {code}
> Since the read call is now non blocking (no more future.get()) we can remove 
> one thread 

[jira] [Resolved] (CASSANDRA-10448) "Unknown type 0" Stream failure on Repair

[Paulo Motta (JIRA)]

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

Paulo Motta resolved CASSANDRA-10448.
-
   Resolution: Duplicate
Fix Version/s: (was: 2.2.x)

> "Unknown type 0" Stream failure on Repair
> -
>
> Key: CASSANDRA-10448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10448
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: Cassandra 2.2.2
> 5 Nodes in Google Compute Engine
> Java 1.8.0_60
>Reporter: Omri Iluz
>Assignee: Paulo Motta
> Attachments: apache-cassandra-2.2.4-SNAPSHOT.jar, casslogs.txt, 
> receiversystem.log, sendersystem.log
>
>
> While running repair after upgrading to 2.2.2 I am getting many stream fail 
> errors:
> {noformat}
> [2015-10-05 23:52:30,353] Repair session 4c181051-6bbb-11e5-acdb-d9a8bbd39330 
> for range (59694553044959221,86389982480621619] failed with error [repair 
> #4c181051-6bbb-11e5-acdb-d9a8bbd39330 on px/acti
> vities, (59694553044959221,86389982480621619]] Sync failed between 
> /10.240.81.104 and /10.240.134.221 (progress: 4%)
> {noformat}
> Logs from both sides of the stream:
> Sides 1 -
> {noformat}
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:111 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Creating new streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52723] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 13 files(517391317 bytes), sending 10 
> files(469491729 bytes)
> ERROR [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,234 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> java.lang.IllegalArgumentException: Unknown type 0
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.81.104 is complete
> WARN  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:209 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Stream failed
> {noformat}
> Side 2 -
> {noformat}
> INFO  [AntiEntropyStage:1] 2015-10-05 23:52:30,060 StreamResultFuture.java:86 
> - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] Executing streaming plan for 
> Repair
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,061 
> StreamSession.java:232 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Starting streaming to /10.240.134.221
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,063 
> StreamCoordinator.java:213 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Beginning stream session with /10.240.134.221
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 10 files(469491729 bytes), sending 13 
> files(517391317 bytes)
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.134.221 is complete
> ERROR [STREAM-OUT-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe
>   at 
> org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:144) 
> ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:79)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:76)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> 

[jira] [Issue Comment Deleted] (CASSANDRA-10496) Make DTCS split partitions based on time during compaction

[Jeff Jirsa (JIRA)]

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

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

(was: [~krummas] - why not make 3 resulting sstables - one earlier, one later, 
and one exactly on target? The marginal cost of the third sstable seems pretty 
minor. The benefit seems relatively significant? 
)

> Make DTCS split partitions based on time during compaction
> --
>
> Key: CASSANDRA-10496
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10496
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>  Labels: dtcs
> Fix For: 3.x
>
>
> To avoid getting old data in new time windows with DTCS (or related, like 
> [TWCS|CASSANDRA-9666]), we need to split out old data into its own sstable 
> during compaction.
> My initial idea is to just create two sstables, when we create the compaction 
> task we state the start and end times for the window, and any data older than 
> the window will be put in its own sstable.
> By creating a single sstable with old data, we will incrementally get the 
> windows correct - say we have an sstable with these timestamps:
> {{[100, 99, 98, 97, 75, 50, 10]}}
> and we are compacting in window {{[100, 80]}} - we would create two sstables:
> {{[100, 99, 98, 97]}}, {{[75, 50, 10]}}, and the first window is now 
> 'correct'. The next compaction would compact in window {{[80, 60]}} and 
> create sstables {{[75]}}, {{[50, 10]}} etc.
> We will probably also want to base the windows on the newest data in the 
> sstables so that we actually have older data than the window.



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

[jira] [Commented] (CASSANDRA-10428) cqlsh: Include sub-second precision in timestamps by default

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10428:
-

Overall code and tests looks good. Some minor observations:
* Using your 
[example|https://issues.apache.org/jira/browse/CASSANDRA-10428?focusedCommentId=14939157=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14939157],
 the following works:
{noformat}
cqlsh:ks> SELECT * from test where id='1' and time = '2015-09-29 20:54:24.200';

 id | time| val
+-+-
  1 | 2015-09-29 23:54:24.20+ | abc
{noformat} but the following does not work:
{noformat}
cqlsh:ks> SELECT * from test where id='1' and time = '2015-09-29 20:54:24.20';

 id | time | val
+--+-

(0 rows)
{noformat} What would be the correct behavior in this case?
* Surprisingly this didn't break (m)any [cqlsh 
dtests|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10428-dtest/4/testReport/],
 is this expected?
* It seems the {{%f}} format does not work correctly on jython on Windows, 
according to this [stack overflow 
answer|http://stackoverflow.com/a/17270917/5477191]. I wonder if we should also 
support this on non-standard python implementations. I will test with standard 
python on Windows and see if it works.
* I tested with copy to/from, and it seems to work correctly, but microseconds 
are silently discarded on copy from since we don't support this natively in the 
timestamp format. Should we maybe print a warning if the timestamp is in sub-ms 
precision different from zero?

> cqlsh: Include sub-second precision in timestamps by default
> 
>
> Key: CASSANDRA-10428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10428
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: OSX 10.10.2
>Reporter: Chandran Anjur Narasimhan
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 3.x
>
>
> Query with >= timestamp works. But the exact timestamp value is not working.
> {noformat}
> NCHAN-M-D0LZ:bin nchan$ ./cqlsh
> Connected to CCC Multi-Region Cassandra Cluster at :.
> [cqlsh 5.0.1 | Cassandra 2.1.7 | CQL spec 3.2.0 | Native protocol v3]
> Use HELP for help.
> cqlsh>
> {noformat}
> {panel:title=Schema|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> cqlsh:ccc> desc COLUMNFAMILY ez_task_result ;
> CREATE TABLE ccc.ez_task_result (
> submissionid text,
> ezid text,
> name text,
> time timestamp,
> analyzed_index_root text,
> ...
> ...
> PRIMARY KEY (submissionid, ezid, name, time)
> {panel}
> {panel:title=Working|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> cqlsh:ccc> select submissionid, ezid, name, time, state, status, 
> translated_criteria_status from ez_task_result where 
> submissionid='760dd154670811e58c04005056bb6ff0' and 
> ezid='760dd6de670811e594fc005056bb6ff0' and name='run-sanities' and 
> time>='2015-09-29 20:54:23-0700';
>  submissionid | ezid | name   
>   | time | state | status  | 
> translated_criteria_status
> --+--+--+--+---+-+
>  760dd154670811e58c04005056bb6ff0 | 760dd6de670811e594fc005056bb6ff0 | 
> run-sanities | 2015-09-29 20:54:23-0700 | EXECUTING | IN_PROGRESS |   
> run-sanities started
> (1 rows)
> cqlsh:ccc>
> {panel}
> {panel:title=Not 
> working|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> cqlsh:ccc> select submissionid, ezid, name, time, state, status, 
> translated_criteria_status from ez_task_result where 
> submissionid='760dd154670811e58c04005056bb6ff0' and 
> ezid='760dd6de670811e594fc005056bb6ff0' and name='run-sanities' and 
> time='2015-09-29 20:54:23-0700';
>  submissionid | ezid | name | time | analyzed_index_root | analyzed_log_path 
> | clientid | end_time | jenkins_path | log_file_path | path_available | 
> path_to_task | required_for_overall_status | start_time | state | status | 
> translated_criteria_status | type
> --+--+--+--+-+---+--+--+--+---++--+-++---+++--
> (0 rows)
> cqlsh:ccc>
> {panel}



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

[jira] [Commented] (CASSANDRA-10995) Consider disabling sstable compression by default in 3.x

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-10995:
-

(You're going to love me for this): We need to make sure we benchmark this on 
Windows as well, since the mmap performance on the platform vs. buffered has 
historically had a larger disparity than on linux. That being said, 
uncompressed was always considerably faster when tested on Windows but we do 
want to make sure we cover that platform.

> Consider disabling sstable compression by default in 3.x
> 
>
> Key: CASSANDRA-10995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10995
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Jim Witschey
>
> With the new sstable format introduced in CASSANDRA-8099, it's very likely 
> that enabled sstable compression is no longer the right default option.
> [~slebresne]'s [blog post|http://www.datastax.com/2015/12/storage-engine-30] 
> on the new storage engine has some comparison numbers for 2.2/3.0, with and 
> without compression that show that in many cases compression no longer has a 
> significant effect on sstable sizes - all while sill consuming extra 
> resources for both writes (compression) and reads (decompression).
> We should run a comprehensive set of benchmarks to determine whether or not 
> compression should be switched to 'off' now in 3.x.



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

[jira] [Commented] (CASSANDRA-10928) SSTableExportTest.testExportColumnsWithMetadata randomly fails

[sankalp kohli (JIRA)]

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

sankalp kohli commented on CASSANDRA-10928:
---

This affects 2.1 only

> SSTableExportTest.testExportColumnsWithMetadata randomly fails
> --
>
> Key: CASSANDRA-10928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10928
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Kjellman
>Assignee: sankalp kohli
> Fix For: 2.1.12
>
> Attachments: CASSANDRA_10928_2.1.diff
>
>
> The SSTableExportTest.testExportColumnsWithMetadata test will randomly fail 
> (bogusly). Currently, the string check used won’t work if the JSON generated 
> happened to order the elements in the array differently.
> {code}
> assertEquals(
> "unexpected serialization format for topLevelDeletion",
> "{\"markedForDeleteAt\":0,\"localDeletionTime\":0}",
> serializedDeletionInfo.toJSONString());
> {code}
> {noformat}
> [junit] Testcase: 
> testExportColumnsWithMetadata(org.apache.cassandra.tools.SSTableExportTest):  
>   FAILED
> [junit] unexpected serialization format for topLevelDeletion 
> expected:<{"[markedForDeleteAt":0,"localDeletionTime]":0}> but 
> was:<{"[localDeletionTime":0,"markedForDeleteAt]":0}>
> [junit] junit.framework.AssertionFailedError: unexpected serialization 
> format for topLevelDeletion 
> expected:<{"[markedForDeleteAt":0,"localDeletionTime]":0}> but 
> was:<{"[localDeletionTime":0,"markedForDeleteAt]":0}>
> [junit]   at 
> org.apache.cassandra.tools.SSTableExportTest.testExportColumnsWithMetadata(SSTableExportTest.java:299)
> [junit]
> {noformat}



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

[jira] [Updated] (CASSANDRA-10928) SSTableExportTest.testExportColumnsWithMetadata randomly fails

[sankalp kohli (JIRA)]

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

sankalp kohli updated CASSANDRA-10928:
--
Attachment: CASSANDRA_10928_2.1.diff

> SSTableExportTest.testExportColumnsWithMetadata randomly fails
> --
>
> Key: CASSANDRA-10928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10928
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Kjellman
>Assignee: sankalp kohli
> Fix For: 2.1.12
>
> Attachments: CASSANDRA_10928_2.1.diff
>
>
> The SSTableExportTest.testExportColumnsWithMetadata test will randomly fail 
> (bogusly). Currently, the string check used won’t work if the JSON generated 
> happened to order the elements in the array differently.
> {code}
> assertEquals(
> "unexpected serialization format for topLevelDeletion",
> "{\"markedForDeleteAt\":0,\"localDeletionTime\":0}",
> serializedDeletionInfo.toJSONString());
> {code}
> {noformat}
> [junit] Testcase: 
> testExportColumnsWithMetadata(org.apache.cassandra.tools.SSTableExportTest):  
>   FAILED
> [junit] unexpected serialization format for topLevelDeletion 
> expected:<{"[markedForDeleteAt":0,"localDeletionTime]":0}> but 
> was:<{"[localDeletionTime":0,"markedForDeleteAt]":0}>
> [junit] junit.framework.AssertionFailedError: unexpected serialization 
> format for topLevelDeletion 
> expected:<{"[markedForDeleteAt":0,"localDeletionTime]":0}> but 
> was:<{"[localDeletionTime":0,"markedForDeleteAt]":0}>
> [junit]   at 
> org.apache.cassandra.tools.SSTableExportTest.testExportColumnsWithMetadata(SSTableExportTest.java:299)
> [junit]
> {noformat}



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

[jira] [Updated] (CASSANDRA-10928) SSTableExportTest.testExportColumnsWithMetadata randomly fails

[sankalp kohli (JIRA)]

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

sankalp kohli updated CASSANDRA-10928:
--
Fix Version/s: 2.1.12

> SSTableExportTest.testExportColumnsWithMetadata randomly fails
> --
>
> Key: CASSANDRA-10928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10928
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Kjellman
>Assignee: sankalp kohli
> Fix For: 2.1.12
>
> Attachments: CASSANDRA_10928_2.1.diff
>
>
> The SSTableExportTest.testExportColumnsWithMetadata test will randomly fail 
> (bogusly). Currently, the string check used won’t work if the JSON generated 
> happened to order the elements in the array differently.
> {code}
> assertEquals(
> "unexpected serialization format for topLevelDeletion",
> "{\"markedForDeleteAt\":0,\"localDeletionTime\":0}",
> serializedDeletionInfo.toJSONString());
> {code}
> {noformat}
> [junit] Testcase: 
> testExportColumnsWithMetadata(org.apache.cassandra.tools.SSTableExportTest):  
>   FAILED
> [junit] unexpected serialization format for topLevelDeletion 
> expected:<{"[markedForDeleteAt":0,"localDeletionTime]":0}> but 
> was:<{"[localDeletionTime":0,"markedForDeleteAt]":0}>
> [junit] junit.framework.AssertionFailedError: unexpected serialization 
> format for topLevelDeletion 
> expected:<{"[markedForDeleteAt":0,"localDeletionTime]":0}> but 
> was:<{"[localDeletionTime":0,"markedForDeleteAt]":0}>
> [junit]   at 
> org.apache.cassandra.tools.SSTableExportTest.testExportColumnsWithMetadata(SSTableExportTest.java:299)
> [junit]
> {noformat}



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

[jira] [Commented] (CASSANDRA-8361) Make DTCS split SSTables to perfectly fit time windows

[JIRA]

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

Björn Hegerfors commented on CASSANDRA-8361:


Yes, they are duplicates.

> Make DTCS split SSTables to perfectly fit time windows
> --
>
> Key: CASSANDRA-8361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8361
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Björn Hegerfors
>Priority: Minor
>
> The time windows that DTCS uses are what the strategy tries to align SSTables 
> to, in order to get the right structure, for best performance. I added the 
> ticket CASSANDRA-8360, taking SSTables one step closer to aligning with these 
> windows in a 1:1 manner.
> The idea in this ticket is to perfectly align SSTables with the DTCS time 
> windows, by splitting SSTables that cross window borders. This can lead to 
> certain benefits, perhaps mostly in consistency and predictability terms, 
> where it will be very well defined where every value is stored that is old 
> enough to have stabilized.
> Read queries can be aligned with windows in order to guarantee a single disk 
> seek (although then the client needs to know the right window placements). 
> Basically, SSTables can be made to align perfectly on day borders, for 
> example. Right now, there would be an SSTable that almost represents a day, 
> but not perfectly. So some data is still in another SSTable. 
> It could also be a useful property for tombstone expiration and repairs.
> Practically all splits would happen only in the latest time windows with the 
> newest and smallest SSTables. After those are split, DTCS would never compact 
> SSTables across window borders. I have a hard time seeing when this could 
> cause an expensive operation except for when switching from another 
> compaction strategy (or even from current DTCS), and after a major 
> compaction. In fact major compaction for DTCS should put data perfectly in 
> windows rather than everything in one SSTable.



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

[jira] [Comment Edited] (CASSANDRA-10995) Consider disabling sstable compression by default in 3.x

[Jim Witschey (JIRA)]

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

Jim Witschey edited comment on CASSANDRA-10995 at 1/11/16 10:17 PM:


One problem we currently have with benchmarking on-disk data size, in 
particular w.r.t. compression, is this: we don't have tools that will generate 
representative, compressible data. It's easy to generate random data ({{UUID}} 
s, random strings from {{cassandra-stress}}).

[~iamaleksey] How important is it that we use such a dataset? You'd know better 
than I, but I don't imagine compressibility would effect resource utilization 
other than disk much.


was (Author: mambocab):
One problem we currently have with benchmarking on-disk data size, in 
particular w.r.t. compression, is this: we don't have tools that will generate 
representative, compressible data. It's easy to generate random data 
({{UUID}}s, random strings from {{cassandra-stress}}).

[~iamaleksey] How important is it that we use such a dataset? You'd know better 
than I, but I don't imagine compressibility would effect resource utilization 
other than disk much.

> Consider disabling sstable compression by default in 3.x
> 
>
> Key: CASSANDRA-10995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10995
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Jim Witschey
>
> With the new sstable format introduced in CASSANDRA-8099, it's very likely 
> that enabled sstable compression is no longer the right default option.
> [~slebresne]'s [blog post|http://www.datastax.com/2015/12/storage-engine-30] 
> on the new storage engine has some comparison numbers for 2.2/3.0, with and 
> without compression that show that in many cases compression no longer has a 
> significant effect on sstable sizes - all while sill consuming extra 
> resources for both writes (compression) and reads (decompression).
> We should run a comprehensive set of benchmarks to determine whether or not 
> compression should be switched to 'off' now in 3.x.



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

[jira] [Commented] (CASSANDRA-10980) nodetool scrub NPEs when keyspace isn't specified

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-10980:


Since 2.2, {{ColumnFamilyStore#markAllCompacting}} can return {{null}}, so in 
compaction manager we need to handle that case.

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


> nodetool scrub NPEs when keyspace isn't specified
> -
>
> Key: CASSANDRA-10980
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10980
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Cassandra (and nodetool) version 3.1
>Reporter: Will Hayworth
>Assignee: Yuki Morishita
>Priority: Trivial
>  Labels: lhf
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: nodetool_scrub_npe.txt
>
>
> I've attached logs of what I saw. Running nodetool scrub without anything 
> else specified resulted in the NPE. Running with the keyspace specified saw 
> successful termination.



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

[jira] [Updated] (CASSANDRA-10980) nodetool scrub NPEs when keyspace isn't specified

[Yuki Morishita (JIRA)]

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

Yuki Morishita updated CASSANDRA-10980:
---
Fix Version/s: 3.x
   3.0.x
   2.2.x

> nodetool scrub NPEs when keyspace isn't specified
> -
>
> Key: CASSANDRA-10980
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10980
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Cassandra (and nodetool) version 3.1
>Reporter: Will Hayworth
>Assignee: Yuki Morishita
>Priority: Trivial
>  Labels: lhf
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: nodetool_scrub_npe.txt
>
>
> I've attached logs of what I saw. Running nodetool scrub without anything 
> else specified resulted in the NPE. Running with the keyspace specified saw 
> successful termination.



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

[jira] [Commented] (CASSANDRA-10448) "Unknown type 0" Stream failure on Repair

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10448:
-

Thanks! Closing as duplicate of CASSANDRA-10961, please reopen if that's not 
the case.

> "Unknown type 0" Stream failure on Repair
> -
>
> Key: CASSANDRA-10448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10448
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: Cassandra 2.2.2
> 5 Nodes in Google Compute Engine
> Java 1.8.0_60
>Reporter: Omri Iluz
>Assignee: Paulo Motta
> Fix For: 2.2.x
>
> Attachments: apache-cassandra-2.2.4-SNAPSHOT.jar, casslogs.txt, 
> receiversystem.log, sendersystem.log
>
>
> While running repair after upgrading to 2.2.2 I am getting many stream fail 
> errors:
> {noformat}
> [2015-10-05 23:52:30,353] Repair session 4c181051-6bbb-11e5-acdb-d9a8bbd39330 
> for range (59694553044959221,86389982480621619] failed with error [repair 
> #4c181051-6bbb-11e5-acdb-d9a8bbd39330 on px/acti
> vities, (59694553044959221,86389982480621619]] Sync failed between 
> /10.240.81.104 and /10.240.134.221 (progress: 4%)
> {noformat}
> Logs from both sides of the stream:
> Sides 1 -
> {noformat}
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:111 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Creating new streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52723] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 13 files(517391317 bytes), sending 10 
> files(469491729 bytes)
> ERROR [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,234 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> java.lang.IllegalArgumentException: Unknown type 0
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.81.104 is complete
> WARN  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:209 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Stream failed
> {noformat}
> Side 2 -
> {noformat}
> INFO  [AntiEntropyStage:1] 2015-10-05 23:52:30,060 StreamResultFuture.java:86 
> - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] Executing streaming plan for 
> Repair
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,061 
> StreamSession.java:232 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Starting streaming to /10.240.134.221
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,063 
> StreamCoordinator.java:213 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Beginning stream session with /10.240.134.221
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 10 files(469491729 bytes), sending 13 
> files(517391317 bytes)
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.134.221 is complete
> ERROR [STREAM-OUT-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe
>   at 
> org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:144) 
> ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:79)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:76)
>  

[jira] [Commented] (CASSANDRA-8361) Make DTCS split SSTables to perfectly fit time windows

[Wei Deng (JIRA)]

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

Wei Deng commented on CASSANDRA-8361:
-

Should this now be considered as a duplicate to CASSANDRA-10496?

> Make DTCS split SSTables to perfectly fit time windows
> --
>
> Key: CASSANDRA-8361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8361
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Björn Hegerfors
>Priority: Minor
>
> The time windows that DTCS uses are what the strategy tries to align SSTables 
> to, in order to get the right structure, for best performance. I added the 
> ticket CASSANDRA-8360, taking SSTables one step closer to aligning with these 
> windows in a 1:1 manner.
> The idea in this ticket is to perfectly align SSTables with the DTCS time 
> windows, by splitting SSTables that cross window borders. This can lead to 
> certain benefits, perhaps mostly in consistency and predictability terms, 
> where it will be very well defined where every value is stored that is old 
> enough to have stabilized.
> Read queries can be aligned with windows in order to guarantee a single disk 
> seek (although then the client needs to know the right window placements). 
> Basically, SSTables can be made to align perfectly on day borders, for 
> example. Right now, there would be an SSTable that almost represents a day, 
> but not perfectly. So some data is still in another SSTable. 
> It could also be a useful property for tombstone expiration and repairs.
> Practically all splits would happen only in the latest time windows with the 
> newest and smallest SSTables. After those are split, DTCS would never compact 
> SSTables across window borders. I have a hard time seeing when this could 
> cause an expensive operation except for when switching from another 
> compaction strategy (or even from current DTCS), and after a major 
> compaction. In fact major compaction for DTCS should put data perfectly in 
> windows rather than everything in one SSTable.



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

[jira] [Updated] (CASSANDRA-10587) sstablemetadata NPE on cassandra 2.2

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-10587:
---
Assignee: (was: Ariel Weisberg)

> sstablemetadata NPE on cassandra 2.2
> 
>
> Key: CASSANDRA-10587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10587
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Tiago Batista
> Fix For: 2.2.x, 3.x
>
>
> I have recently upgraded my cassandra cluster to 2.2, currently running 
> 2.2.3. After running the first repair, cassandra renames the sstables to the 
> new naming schema that does not contain the keyspace name.
>  This causes sstablemetadata to fail with the following stack trace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at 
> org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:275)
> at 
> org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:172)
> at 
> org.apache.cassandra.tools.SSTableMetadataViewer.main(SSTableMetadataViewer.java:52)
> {noformat}



--
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=15092751#comment-15092751
 ] 

Joshua McKenzie commented on CASSANDRA-8844:


bq. This would be the first setting at the cluster level
bq. We don't really have any cluster-global configuration at the moment
Two eloquent phrasings pointing to the 1 reason why keeping it in the .yaml is 
the Right Thing To Do.

> 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 

[jira] [Updated] (CASSANDRA-10331) Establish and implement canonical bulk reading workload(s)

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-10331:
---
Assignee: (was: Ariel Weisberg)

> Establish and implement canonical bulk reading workload(s)
> --
>
> Key: CASSANDRA-10331
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10331
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Ariel Weisberg
> Fix For: 3.x
>
>
> Implement a client, use stress, or extend stress to a bulk reading workload 
> that is indicative of the performance we are trying to improve.



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

[jira] [Updated] (CASSANDRA-9626) Make C* work in all locales

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-9626:
--
Reviewer:   (was: Ariel Weisberg)

> Make C* work in all locales
> ---
>
> Key: CASSANDRA-9626
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9626
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Attachments: 9626.txt
>
>
> Default locale and default charset has immediate effect on how strings are 
> encoded and handles - e.g. via {{String.toLowerCase()}} or {{new 
> String(byte[])}}.
> Problems with different default locales + charsets don't become obvious for 
> US and most European regional settings. But some regional OS settings will 
> cause severe errors. Example: {{"BILLY".toLowerCase()}} returns {{bılly}} 
> with Locale tr_TR (take a look at the second letter - it's an i without the 
> dot).
> (ref: 
> http://blog.thetaphi.de/2012/07/default-locales-default-charsets-and.html)
> It's not a problem I'm currently facing, but it could become a problem for 
> some users. A quick fix could be to set default locale and charset in the 
> start scripts - maybe that's all we need.



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

[jira] [Updated] (CASSANDRA-10189) Unify read/writeUTF code paths

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-10189:
---
Reviewer:   (was: Ariel Weisberg)

> Unify read/writeUTF code paths
> --
>
> Key: CASSANDRA-10189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10189
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>
> (Follow-up to CASSANDRA-9738 and CASSANDRA-8670)
> CASSANDRA-9738 requires {{writeUTF}} functionality that has been improved in 
> CASSANDRA-8670 plus {{readUTF}} functionality. But we need slightly different 
> signatures - one taking {{DataInput}}/{{DataOutput}} and one taking 
> {{ByteBuffer}}.
> We can combine both code paths and benefit from a shared, thread-local byte 
> buffer.
> Slightly different implementations are needed for array backed and direct BBs 
> (as we can directly access the backing array bypassing the direct BB's 
> boundary checks).
> (Part of this has already been done for CASSANDRA-9738 in 
> {{OHCKeyCache.SerializationUtil}})



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

[jira] [Updated] (CASSANDRA-9293) Unit tests should fail if any LEAK DETECTED errors are printed

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-9293:
--
Reviewer:   (was: Ariel Weisberg)

> Unit tests should fail if any LEAK DETECTED errors are printed
> --
>
> Key: CASSANDRA-9293
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9293
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benedict
>Assignee: Sylvestor George
>  Labels: test
> Attachments: 9293.txt
>
>
> We shouldn't depend on dtests to inform us of these problems (which have 
> error log monitoring) - they should be caught by unit tests, which may also 
> cover different failure conditions (besides being faster).
> There are a couple of ways we could do this, but probably the easiest is to 
> add a static flag that is set to true if we ever see a leak (in Ref), and to 
> just assert that this is false at the end of every test.
> [~enigmacurry] is this something TE can help with?



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

[jira] [Assigned] (CASSANDRA-10928) SSTableExportTest.testExportColumnsWithMetadata randomly fails

[sankalp kohli (JIRA)]

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

sankalp kohli reassigned CASSANDRA-10928:
-

Assignee: sankalp kohli

> SSTableExportTest.testExportColumnsWithMetadata randomly fails
> --
>
> Key: CASSANDRA-10928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10928
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Kjellman
>Assignee: sankalp kohli
>
> The SSTableExportTest.testExportColumnsWithMetadata test will randomly fail 
> (bogusly). Currently, the string check used won’t work if the JSON generated 
> happened to order the elements in the array differently.
> {code}
> assertEquals(
> "unexpected serialization format for topLevelDeletion",
> "{\"markedForDeleteAt\":0,\"localDeletionTime\":0}",
> serializedDeletionInfo.toJSONString());
> {code}
> {noformat}
> [junit] Testcase: 
> testExportColumnsWithMetadata(org.apache.cassandra.tools.SSTableExportTest):  
>   FAILED
> [junit] unexpected serialization format for topLevelDeletion 
> expected:<{"[markedForDeleteAt":0,"localDeletionTime]":0}> but 
> was:<{"[localDeletionTime":0,"markedForDeleteAt]":0}>
> [junit] junit.framework.AssertionFailedError: unexpected serialization 
> format for topLevelDeletion 
> expected:<{"[markedForDeleteAt":0,"localDeletionTime]":0}> but 
> was:<{"[localDeletionTime":0,"markedForDeleteAt]":0}>
> [junit]   at 
> org.apache.cassandra.tools.SSTableExportTest.testExportColumnsWithMetadata(SSTableExportTest.java:299)
> [junit]
> {noformat}



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

[jira] [Commented] (CASSANDRA-10448) "Unknown type 0" Stream failure on Repair

[Omri Iluz (JIRA)]

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

Omri Iluz commented on CASSANDRA-10448:
---

Thank you so much Paulo! I can confirm that this resolves the problem on my 
side as well.

If you get to the Palo Alto area, beer on me.

> "Unknown type 0" Stream failure on Repair
> -
>
> Key: CASSANDRA-10448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10448
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: Cassandra 2.2.2
> 5 Nodes in Google Compute Engine
> Java 1.8.0_60
>Reporter: Omri Iluz
>Assignee: Paulo Motta
> Attachments: apache-cassandra-2.2.4-SNAPSHOT.jar, casslogs.txt, 
> receiversystem.log, sendersystem.log
>
>
> While running repair after upgrading to 2.2.2 I am getting many stream fail 
> errors:
> {noformat}
> [2015-10-05 23:52:30,353] Repair session 4c181051-6bbb-11e5-acdb-d9a8bbd39330 
> for range (59694553044959221,86389982480621619] failed with error [repair 
> #4c181051-6bbb-11e5-acdb-d9a8bbd39330 on px/acti
> vities, (59694553044959221,86389982480621619]] Sync failed between 
> /10.240.81.104 and /10.240.134.221 (progress: 4%)
> {noformat}
> Logs from both sides of the stream:
> Sides 1 -
> {noformat}
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:111 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Creating new streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52723] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 13 files(517391317 bytes), sending 10 
> files(469491729 bytes)
> ERROR [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,234 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> java.lang.IllegalArgumentException: Unknown type 0
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.81.104 is complete
> WARN  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:209 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Stream failed
> {noformat}
> Side 2 -
> {noformat}
> INFO  [AntiEntropyStage:1] 2015-10-05 23:52:30,060 StreamResultFuture.java:86 
> - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] Executing streaming plan for 
> Repair
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,061 
> StreamSession.java:232 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Starting streaming to /10.240.134.221
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,063 
> StreamCoordinator.java:213 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Beginning stream session with /10.240.134.221
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 10 files(469491729 bytes), sending 13 
> files(517391317 bytes)
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.134.221 is complete
> ERROR [STREAM-OUT-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe
>   at 
> org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:144) 
> ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:79)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> 

[jira] [Updated] (CASSANDRA-10996) The system table system.schema_columnfamilies does not exist

[sangshenghong (JIRA)]

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

sangshenghong updated CASSANDRA-10996:
--
Description: 
In the 2.1.6 version,there is one system table named 
"system.schema_columnfamilies", but in the latest version 3.1.1, when I execute 
select * from system.schema_columnfamilies, it throw "unconfigured table 
schema_columnfamilies" in cqlsh.
But in the system.log file, it show 
ColumnFamilyStore.java:381 - Initializing system.schema_columnfamilies
I checked the doc and found some tables and schemas have been change, so I want 
to know if there any change for this?

  was:In the 2.1.6 version,there is one system table named 
"system.schema_columnfamilies", but in the latest version 3.1.1, when I execute 
select * from system.schema_columnfamilies, it throw "unconfigured table 
schema_columnfamilies" in cqlsh.


> The system table  system.schema_columnfamilies does not exist
> -
>
> Key: CASSANDRA-10996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10996
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: sangshenghong
>Priority: Critical
> Fix For: 3.1.1
>
> Attachments: error.png
>
>
> In the 2.1.6 version,there is one system table named 
> "system.schema_columnfamilies", but in the latest version 3.1.1, when I 
> execute select * from system.schema_columnfamilies, it throw "unconfigured 
> table schema_columnfamilies" in cqlsh.
> But in the system.log file, it show 
> ColumnFamilyStore.java:381 - Initializing system.schema_columnfamilies
> I checked the doc and found some tables and schemas have been change, so I 
> want to know if there any change for this?



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

[jira] [Commented] (CASSANDRA-10661) Integrate SASI to Cassandra

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-10661:
-

bq. maybe we should rename ORIGINAL into PREFIX at the same time, so we'll have 
- PREFIX, CONTAINS, SPARSE
+1

> Integrate SASI to Cassandra
> ---
>
> Key: CASSANDRA-10661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10661
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths
>Reporter: Pavel Yaskevich
>Assignee: Pavel Yaskevich
>  Labels: sasi
> Fix For: 3.x
>
>
> We have recently released new secondary index engine 
> (https://github.com/xedin/sasi) build using SecondaryIndex API, there are 
> still couple of things to work out regarding 3.x since it's currently 
> targeted on 2.0 released. I want to make this an umbrella issue to all of the 
> things related to integration of SASI, which are also tracked in 
> [sasi_issues|https://github.com/xedin/sasi/issues], into mainline Cassandra 
> 3.x release.



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

[jira] [Created] (CASSANDRA-10996) The system table system.schema_columnfamilies does not exist

[sangshenghong (JIRA)]

sangshenghong created CASSANDRA-10996:
-

 Summary: The system table  system.schema_columnfamilies does not 
exist
 Key: CASSANDRA-10996
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10996
 Project: Cassandra
  Issue Type: Bug
  Components: CQL
Reporter: sangshenghong
Priority: Critical
 Fix For: 3.1.1
 Attachments: error.png

In the 2.1.6 version,there is one system table named 
"system.schema_columnfamilies", but in the latest version 3.1.1, when I execute 
select * from system.schema_columnfamilies, it throw "unconfigured table 
schema_columnfamilies" in cqlsh.



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

[jira] [Commented] (CASSANDRA-8072) Exception during startup: Unable to gossip with any seeds

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-8072:
-

Thank you [~beobal] and [~rhatch].

> Exception during startup: Unable to gossip with any seeds
> -
>
> Key: CASSANDRA-8072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8072
> Project: Cassandra
>  Issue Type: Bug
>  Components: Lifecycle
>Reporter: Ryan Springer
>Assignee: Stefania
> Fix For: 2.1.13, 2.2.5, 3.0.3, 3.3
>
> Attachments: cas-dev-dt-01-uw1-cassandra-seed01_logs.tar.bz2, 
> cas-dev-dt-01-uw1-cassandra-seed02_logs.tar.bz2, 
> cas-dev-dt-01-uw1-cassandra02_logs.tar.bz2, 
> casandra-system-log-with-assert-patch.log, screenshot-1.png, 
> trace_logs.tar.bz2
>
>
> When Opscenter 4.1.4 or 5.0.1 tries to provision a 2-node DSC 2.0.10 cluster 
> in either ec2 or locally, an error occurs sometimes with one of the nodes 
> refusing to start C*.  The error in the /var/log/cassandra/system.log is:
> ERROR [main] 2014-10-06 15:54:52,292 CassandraDaemon.java (line 513) 
> Exception encountered during startup
> java.lang.RuntimeException: Unable to gossip with any seeds
> at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1200)
> at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:444)
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:655)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:609)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:502)
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378)
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
>  INFO [StorageServiceShutdownHook] 2014-10-06 15:54:52,326 Gossiper.java 
> (line 1279) Announcing shutdown
>  INFO [StorageServiceShutdownHook] 2014-10-06 15:54:54,326 
> MessagingService.java (line 701) Waiting for messaging service to quiesce
>  INFO [ACCEPT-localhost/127.0.0.1] 2014-10-06 15:54:54,327 
> MessagingService.java (line 941) MessagingService has terminated the accept() 
> thread
> This errors does not always occur when provisioning a 2-node cluster, but 
> probably around half of the time on only one of the nodes.  I haven't been 
> able to reproduce this error with DSC 2.0.9, and there have been no code or 
> definition file changes in Opscenter.
> I can reproduce locally with the above steps.  I'm happy to test any proposed 
> fixes since I'm the only person able to reproduce reliably so far.



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

[jira] [Updated] (CASSANDRA-10635) Add metrics for authentication failures

[Soumava Ghosh (JIRA)]

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

Soumava Ghosh updated CASSANDRA-10635:
--
Attachment: 10635-2.2.txt
10635-2.1.txt
10635-3.0.txt

> Add metrics for authentication failures
> ---
>
> Key: CASSANDRA-10635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10635
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Soumava Ghosh
>Assignee: Soumava Ghosh
>Priority: Minor
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
> Attachments: 10635-2.1.txt, 10635-2.2.txt, 10635-3.0.txt
>
>
> There should be no auth failures on a cluster in general. 
> Having metrics around the authentication code would help detect clients 
> that are connecting to the wrong cluster or have auth incorrectly configured.



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

[jira] [Resolved] (CASSANDRA-10996) The system table system.schema_columnfamilies does not exist

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne resolved CASSANDRA-10996.
--
Resolution: Not A Problem

To refer to the "upgrading" section of the {{NEWS}} file for 3.0 (which I 
strongly advise reading carefully for any upgrade but even more so for major 
upgrades):
{noformat}
   - Schema metadata is now stored in the new `system_schema` keyspace, and
 legacy `system.schema_*` tables are now gone; see CASSANDRA-6717 for 
details.
{noformat}
So you'd have to adapt your code to use the new tables. That said, I'd 
recommend relying on drivers metadata APIs (for instance 
[KeyspaceMetadata|http://docs.datastax.com/en/drivers/java/2.1/com/datastax/driver/core/KeyspaceMetadata.html]
 and related classes for the java driver) to access schema information (instead 
of directly querying the system tables) as this will isolate you from such 
changes.

> The system table  system.schema_columnfamilies does not exist
> -
>
> Key: CASSANDRA-10996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10996
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: sangshenghong
>Priority: Critical
> Fix For: 3.1.1
>
> Attachments: error.png
>
>
> In the 2.1.6 version,there is one system table named 
> "system.schema_columnfamilies", but in the latest version 3.1.1, when I 
> execute select * from system.schema_columnfamilies, it throw "unconfigured 
> table schema_columnfamilies" in cqlsh.
> But in the system.log file, it show 
> ColumnFamilyStore.java:381 - Initializing system.schema_columnfamilies
> I checked the doc and found some tables and schemas have been change, so I 
> want to know if there any change for this?



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

[jira] [Commented] (CASSANDRA-10938) test_bulk_round_trip_blogposts is failing occasionally

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-10938:
--

I've changed NBHM to CHM on all branches starting with 2.1 (since the test 
fails on 2.1 and it is a new feature). The patch applies from 2.2 onwards:

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

I will test 2.2 locally on Windows and I will repeat the dtests several times 
on Jenkins, probably 20 times total across all branches. 

> test_bulk_round_trip_blogposts is failing occasionally
> --
>
> Key: CASSANDRA-10938
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10938
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.x
>
> Attachments: 6452.nps, 6452.png, 7300.nps, 7300a.png, 7300b.png, 
> node1_debug.log, node2_debug.log, node3_debug.log, recording_127.0.0.1.jfr
>
>
> We get timeouts occasionally that cause the number of records to be incorrect:
> http://cassci.datastax.com/job/trunk_dtest/858/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_bulk_round_trip_blogposts/



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

[jira] [Commented] (CASSANDRA-10839) cqlsh failed to format value bytearray

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-10839:
--

Thanks for the clarification, this is a recent regression and should therefore 
be committed to 2.1. As stated above, for 2.2 onwards we don't need this 
workaround since we do not support python 2.6. So please commit [this 
patch|https://github.com/stef1927/cassandra/commits/10839-2.1] to 2.1 and merge 
upwards using the ours merge strategy.

> cqlsh failed to format value bytearray
> --
>
> Key: CASSANDRA-10839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10839
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Severin Leonhardt
>Assignee: Stefania
>Priority: Minor
> Fix For: 2.1.x
>
>
> Execute the following in cqlsh (5.0.1):
> {noformat}
> > create table test(column blob, primary key(column));
> > insert into test (column) VALUES(0x00);
> > select * from test;
>  column
> 
>  bytearray(b'\x00')
> (1 rows)
> Failed to format value bytearray(b'\x00') : b2a_hex() argument 1 must be 
> string or read-only buffer, not bytearray
> {noformat}



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

[jira] [Comment Edited] (CASSANDRA-10428) cqlsh: Include sub-second precision in timestamps by default

[Paulo Motta (JIRA)]

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

Paulo Motta edited comment on CASSANDRA-10428 at 1/12/16 2:02 AM:
--

Overall code and tests looks good. Some minor observations:
* Using your 
[example|https://issues.apache.org/jira/browse/CASSANDRA-10428?focusedCommentId=14939157=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14939157],
 the following works:
{noformat}
cqlsh:ks> SELECT * from test where id='1' and time = '2015-09-29 20:54:24.200';

 id | time| val
+-+-
  1 | 2015-09-29 23:54:24.20+ | abc
{noformat} but the following does not work:
{noformat}
cqlsh:ks> SELECT * from test where id='1' and time = '2015-09-29 20:54:24.20';

 id | time | val
+--+-

(0 rows)
{noformat} What would be the correct behavior in this case?
* Surprisingly this didn't break (m)any [cqlsh 
dtests|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10428-dtest/4/testReport/],
 is this expected?
* It seems the {{%f}} format does not work correctly on jython on Windows, 
according to this [stack overflow 
answer|http://stackoverflow.com/a/17270917/5477191]. I wonder if we should also 
support this on non-standard python implementations. -I will test with standard 
python on Windows and see if it works.- Tested on standard python on Windows 
and worked correctly.
* I tested with copy to/from, and it seems to work correctly, but microseconds 
are silently discarded on copy from since we don't support this natively in the 
timestamp format. Should we maybe print a warning if the timestamp is in sub-ms 
precision different from zero?


was (Author: pauloricardomg):
Overall code and tests looks good. Some minor observations:
* Using your 
[example|https://issues.apache.org/jira/browse/CASSANDRA-10428?focusedCommentId=14939157=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14939157],
 the following works:
{noformat}
cqlsh:ks> SELECT * from test where id='1' and time = '2015-09-29 20:54:24.200';

 id | time| val
+-+-
  1 | 2015-09-29 23:54:24.20+ | abc
{noformat} but the following does not work:
{noformat}
cqlsh:ks> SELECT * from test where id='1' and time = '2015-09-29 20:54:24.20';

 id | time | val
+--+-

(0 rows)
{noformat} What would be the correct behavior in this case?
* Surprisingly this didn't break (m)any [cqlsh 
dtests|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10428-dtest/4/testReport/],
 is this expected?
* It seems the {{%f}} format does not work correctly on jython on Windows, 
according to this [stack overflow 
answer|http://stackoverflow.com/a/17270917/5477191]. I wonder if we should also 
support this on non-standard python implementations. I will test with standard 
python on Windows and see if it works.
* I tested with copy to/from, and it seems to work correctly, but microseconds 
are silently discarded on copy from since we don't support this natively in the 
timestamp format. Should we maybe print a warning if the timestamp is in sub-ms 
precision different from zero?

> cqlsh: Include sub-second precision in timestamps by default
> 
>
> Key: CASSANDRA-10428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10428
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: OSX 10.10.2
>Reporter: Chandran Anjur Narasimhan
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 3.x
>
>
> Query with >= timestamp works. But the exact timestamp value is not working.
> {noformat}
> NCHAN-M-D0LZ:bin nchan$ ./cqlsh
> Connected to CCC Multi-Region Cassandra Cluster at :.
> [cqlsh 5.0.1 | Cassandra 2.1.7 | CQL spec 3.2.0 | Native protocol v3]
> Use HELP for help.
> cqlsh>
> {noformat}
> {panel:title=Schema|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> cqlsh:ccc> desc COLUMNFAMILY ez_task_result ;
> CREATE TABLE ccc.ez_task_result (
> submissionid text,
> ezid text,
> name text,
> time timestamp,
> analyzed_index_root text,
> ...
> ...
> PRIMARY KEY (submissionid, ezid, name, time)
> {panel}
> {panel:title=Working|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> cqlsh:ccc> select submissionid, ezid, name, time, state, status, 
> translated_criteria_status from ez_task_result where 
> submissionid='760dd154670811e58c04005056bb6ff0' and 
> ezid='760dd6de670811e594fc005056bb6ff0' and name='run-sanities' and 
> time>='2015-09-29 20:54:23-0700';
>  submissionid | ezid | name 

[jira] [Commented] (CASSANDRA-10965) Shadowable tombstones can continue to shadow view results when timestamps match

[Taiyuan Zhang (JIRA)]

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

Taiyuan Zhang commented on CASSANDRA-10965:
---

Got it. Are you currently working on this? If not, I'm interested in digging 
into this.

> Shadowable tombstones can continue to shadow view results when timestamps 
> match
> ---
>
> Key: CASSANDRA-10965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10965
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Carl Yeksigian
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
> Attachments: shadow-ts.cql
>
>
> I've attached a script which reproduces the issue. The first time we insert 
> with {{TIMESTAMP 2}}, we are inserting a new row which has the same timestamp 
> as the previous shadow tombstone, and it continues to be shadowed by that 
> tombstone because we shadow values with the same timestamp.



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

[jira] [Updated] (CASSANDRA-10958) Range query with filtering interacts badly with static columns

[Taiyuan Zhang (JIRA)]

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

Taiyuan Zhang updated CASSANDRA-10958:
--
Attachment: 10958.patch

> Range query with filtering interacts badly with static columns
> --
>
> Key: CASSANDRA-10958
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10958
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Taiyuan Zhang
>Priority: Minor
> Attachments: 10958.patch
>
>
>  I'm playing with Cassandra 3. I added a secondary index on a column of 
> integer, then I want to do a range query. First it threw an error:
> {code}
> InvalidRequest: code=2200 [Invalid query] message="No supported secondary 
> index found for the non primary key columns restrictions"
> {code}
> So I added 'Allow Filtering'
> {code}
> cqlsh:mykeyspace> SELECT * FROM test ;
> id | id2 | age | extra
> +-+-+---
>   1 |   1 |   1 | 1
>   2 |   2 |   2 | 2
> (2 rows)
> cqlsh:mykeyspace > CREATE INDEX test_age on test (extra) ;
> cqlsh:mykeyspace > select * FROM test WHERE extra < 2 ALLOW FILTERING ;
>  id | id2  | age | extra
> +--+-+---
>   1 |1 |   1 | 1
>   2 | null |   2 |  null
> (2 rows)
> {code}
> My schema is:
> {code}
> CREATE TABLE mykeyspace.test (
> id int,
> id2 int,
> age int static,
> extra int,
> PRIMARY KEY (id, id2)
> ) 
> {code}
> I don't know if this is by design or not, but it really does look like a BUG 
> to me.



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

[jira] [Resolved] (CASSANDRA-8361) Make DTCS split SSTables to perfectly fit time windows

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson resolved CASSANDRA-8361.

Resolution: Duplicate

> Make DTCS split SSTables to perfectly fit time windows
> --
>
> Key: CASSANDRA-8361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8361
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Björn Hegerfors
>Priority: Minor
>
> The time windows that DTCS uses are what the strategy tries to align SSTables 
> to, in order to get the right structure, for best performance. I added the 
> ticket CASSANDRA-8360, taking SSTables one step closer to aligning with these 
> windows in a 1:1 manner.
> The idea in this ticket is to perfectly align SSTables with the DTCS time 
> windows, by splitting SSTables that cross window borders. This can lead to 
> certain benefits, perhaps mostly in consistency and predictability terms, 
> where it will be very well defined where every value is stored that is old 
> enough to have stabilized.
> Read queries can be aligned with windows in order to guarantee a single disk 
> seek (although then the client needs to know the right window placements). 
> Basically, SSTables can be made to align perfectly on day borders, for 
> example. Right now, there would be an SSTable that almost represents a day, 
> but not perfectly. So some data is still in another SSTable. 
> It could also be a useful property for tombstone expiration and repairs.
> Practically all splits would happen only in the latest time windows with the 
> newest and smallest SSTables. After those are split, DTCS would never compact 
> SSTables across window borders. I have a hard time seeing when this could 
> cause an expensive operation except for when switching from another 
> compaction strategy (or even from current DTCS), and after a major 
> compaction. In fact major compaction for DTCS should put data perfectly in 
> windows rather than everything in one SSTable.



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

[cassandra] Git Push Summary

[jake]

Repository: cassandra
Updated Tags:  refs/tags/3.2-tentative [deleted] 3c6dfa4aa

[jira] [Commented] (CASSANDRA-10676) AssertionError in CompactionExecutor

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-10676:


All of the branches:

||2.2||3.0||3.3||trunk||
|[utest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10676-2.2-testall/]|[utest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10676-3.0-testall/]|[utest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10676-3.3-testall/]|[utest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10676-trunk-testall/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10676-2.2-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10676-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10676-3.3-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10676-trunk-dtest/]|

> AssertionError in CompactionExecutor
> 
>
> Key: CASSANDRA-10676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10676
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: C* 2.1.9 on Debian Wheezy
>Reporter: mlowicki
>Assignee: Carl Yeksigian
> Fix For: 2.1.x
>
>
> {code}
> ERROR [CompactionExecutor:33329] 2015-11-09 08:16:22,759 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[CompactionExecutor:33329,1,main]
> java.lang.AssertionError: 
> /var/lib/cassandra/data/system/compactions_in_progress-55080ab05d9c388690a4acb25fe1f77b/system-compactions_in_progress-ka-888705-Data.db
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.getApproximateKeyCount(SSTableReader.java:279)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:151)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:73)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:236)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> ~[na:1.7.0_80]
>   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]
> ^C
> root@db1:~# tail -f /var/log/cassandra/system.log
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:151)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:73)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:236)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> ~[na:1.7.0_80]
>   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}



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

[jira] [Updated] (CASSANDRA-10660) Support user-defined compactions through nodetool

[Yuki Morishita (JIRA)]

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

Yuki Morishita updated CASSANDRA-10660:
---
Fix Version/s: 3.x

> Support user-defined compactions through nodetool
> -
>
> Key: CASSANDRA-10660
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10660
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Jeff Jirsa
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
>
> For a long time, we've supported running user-defined compactions through 
> JMX.  This comes in handy fairly often, mostly when dealing with low disk 
> space or tombstone purging, so it would be good to add something to nodetool 
> for this.  An extra option for {{nodetool compact}} would probably suffice.



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

[jira] [Commented] (CASSANDRA-10660) Support user-defined compactions through nodetool

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-10660:


Jeff, sorry for delay.

Since this is the new feature at this time, I'd like to move target version to 
3.x.
Patch applies cleanly still, though I made small changes.

- Added description for user defined compaction
- We can use 
[String.join|https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#join-java.lang.CharSequence-java.lang.Iterable-]
 from Java 8 instead of our own.

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

(tests are just kicked off)

> Support user-defined compactions through nodetool
> -
>
> Key: CASSANDRA-10660
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10660
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Jeff Jirsa
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
>
> For a long time, we've supported running user-defined compactions through 
> JMX.  This comes in handy fairly often, mostly when dealing with low disk 
> space or tombstone purging, so it would be good to add something to nodetool 
> for this.  An extra option for {{nodetool compact}} would probably suffice.



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

[jira] [Commented] (CASSANDRA-10660) Support user-defined compactions through nodetool

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-10660:


Ack, thanks for the cleanup. 3.x looks fine.


> Support user-defined compactions through nodetool
> -
>
> Key: CASSANDRA-10660
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10660
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Jeff Jirsa
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
>
> For a long time, we've supported running user-defined compactions through 
> JMX.  This comes in handy fairly often, mostly when dealing with low disk 
> space or tombstone purging, so it would be good to add something to nodetool 
> for this.  An extra option for {{nodetool compact}} would probably suffice.



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

svn commit: r11879 - in /release/cassandra: 3.0.1/ 3.1/ 3.2/ debian/dists/32x/ debian/dists/32x/main/ debian/dists/32x/main/binary-amd64/ debian/dists/32x/main/binary-i386/ debian/dists/32x/main/sourc

[jake]

Author: jake
Date: Mon Jan 11 21:42:01 2016
New Revision: 11879

Log:
 add 3.2

Added:
release/cassandra/3.2/
release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz   (with props)
release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.asc
release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.asc.md5
release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.asc.sha1
release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.md5
release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.sha1
release/cassandra/3.2/apache-cassandra-3.2-src.tar.gz   (with props)
release/cassandra/3.2/apache-cassandra-3.2-src.tar.gz.asc
release/cassandra/3.2/apache-cassandra-3.2-src.tar.gz.asc.md5
release/cassandra/3.2/apache-cassandra-3.2-src.tar.gz.asc.sha1
release/cassandra/3.2/apache-cassandra-3.2-src.tar.gz.md5
release/cassandra/3.2/apache-cassandra-3.2-src.tar.gz.sha1
release/cassandra/debian/dists/32x/
release/cassandra/debian/dists/32x/InRelease
release/cassandra/debian/dists/32x/Release
release/cassandra/debian/dists/32x/Release.gpg
release/cassandra/debian/dists/32x/main/
release/cassandra/debian/dists/32x/main/binary-amd64/
release/cassandra/debian/dists/32x/main/binary-amd64/Packages
release/cassandra/debian/dists/32x/main/binary-amd64/Packages.gz   (with 
props)
release/cassandra/debian/dists/32x/main/binary-amd64/Release
release/cassandra/debian/dists/32x/main/binary-i386/
release/cassandra/debian/dists/32x/main/binary-i386/Packages
release/cassandra/debian/dists/32x/main/binary-i386/Packages.gz   (with 
props)
release/cassandra/debian/dists/32x/main/binary-i386/Release
release/cassandra/debian/dists/32x/main/source/
release/cassandra/debian/dists/32x/main/source/Release
release/cassandra/debian/dists/32x/main/source/Sources.gz   (with props)
release/cassandra/debian/pool/main/c/cassandra/cassandra-tools_3.2_all.deb  
 (with props)
release/cassandra/debian/pool/main/c/cassandra/cassandra_3.2.diff.gz   
(with props)
release/cassandra/debian/pool/main/c/cassandra/cassandra_3.2.dsc
release/cassandra/debian/pool/main/c/cassandra/cassandra_3.2.orig.tar.gz   
(with props)
release/cassandra/debian/pool/main/c/cassandra/cassandra_3.2.orig.tar.gz.asc
release/cassandra/debian/pool/main/c/cassandra/cassandra_3.2_all.deb   
(with props)
Removed:
release/cassandra/3.0.1/
release/cassandra/3.1/

Added: release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz
==
Binary file - no diff available.

Propchange: release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz
--
svn:mime-type = application/octet-stream

Added: release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.asc
==
--- release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.asc (added)
+++ release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.asc Mon Jan 11 
21:42:01 2016
@@ -0,0 +1,17 @@
+-BEGIN PGP SIGNATURE-
+Version: GnuPG v1
+
+iQIcBAABAgAGBQJWjtvzAAoJEHSdbuwDU7EsAj4QAJP2EqHodv+ke2IEZkYxdERY
++hMeyBtW+tBB3OdhG+pX83qkdXzVAyQcqyNLj9Z4kO366XqzBHKQam77fEcGnTkZ
+hdSmd4+Q+y3fQXP6pAnW2dVm8XV9jKVe5DtvkCOo7+UhFa5QsjMSwwWrCFRl0RHM
+fSxDVcHhvAMNWEs5/iDkiQjSdP8JH+SjyuWRF5kucIEZapxYhNWExOvuWLWrMg7f
+R9kEpA98pzSmvjX2GJ9NCiagJJUbUTyPHNpCpy076dkD/mwqvURX0KFMIChMgoPR
+mfpePXGQ7Y23NxIBUI1MXhNMpPC1+1I9t94fGT1giIHRgygUYfd8D+XgKc/RAtHT
+7/bQmo/JO476U1DmTSEWZICB6rqqtUlEh16HtgaL2uo8RXvQ+kX6T4yFegvzU+bk
+pMxZHNXemw8IapIdjIW8nAykmXOmMoqgWilxhEEPKvCXWivTUtlrTDufK2ZxtB2v
+DhFxqE7K/PMkMYH6DvJcnJegFclu5R54uAXjE+jQrTHHysqP/Z6BIqs/0l8mpLsn
+XiPwuQGpN1ZgH7tpM82IwCDHqaFfZQXD9yUFKYhCHu9Nz9VNzJPMBEgUrONmZSMn
+gSxyxZm/xpcQ/U18tz7s6nISj+cJ4VwctinK1xmfERh4rtN22lX/Vag1YowcPFG8
+w3hPnXsK5k6oen0qS2B1
+=j1Pv
+-END PGP SIGNATURE-

Added: release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.asc.md5
==
--- release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.asc.md5 (added)
+++ release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.asc.md5 Mon Jan 11 
21:42:01 2016
@@ -0,0 +1 @@
+4eaf4700b8d5e7a7994b00a44e024726
\ No newline at end of file

Added: release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.asc.sha1
==
--- release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.asc.sha1 (added)
+++ release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.asc.sha1 Mon Jan 11 
21:42:01 2016
@@ -0,0 +1 @@
+89ca6d8f329a1a724e9e54da4150ab7156be9043
\ No newline at end of file

Added: release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.md5
==
--- release/cassandra/3.2/apache-cassandra-3.2-bin.tar.gz.md5 (added)
+++ 

[jira] [Commented] (CASSANDRA-10448) "Unknown type 0" Stream failure on Repair

[Chris Buenger (JIRA)]

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

Chris Buenger commented on CASSANDRA-10448:
---

Had problems joining new nodes to a six node cluster running 2.2.4. Streaming 
failed with above symptoms. 
[CASSANDRA-10961|https://issues.apache.org/jira/browse/CASSANDRA-10961] patch 
resolved the problem. Thanks.

> "Unknown type 0" Stream failure on Repair
> -
>
> Key: CASSANDRA-10448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10448
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: Cassandra 2.2.2
> 5 Nodes in Google Compute Engine
> Java 1.8.0_60
>Reporter: Omri Iluz
>Assignee: Paulo Motta
> Fix For: 2.2.x
>
> Attachments: apache-cassandra-2.2.4-SNAPSHOT.jar, casslogs.txt, 
> receiversystem.log, sendersystem.log
>
>
> While running repair after upgrading to 2.2.2 I am getting many stream fail 
> errors:
> {noformat}
> [2015-10-05 23:52:30,353] Repair session 4c181051-6bbb-11e5-acdb-d9a8bbd39330 
> for range (59694553044959221,86389982480621619] failed with error [repair 
> #4c181051-6bbb-11e5-acdb-d9a8bbd39330 on px/acti
> vities, (59694553044959221,86389982480621619]] Sync failed between 
> /10.240.81.104 and /10.240.134.221 (progress: 4%)
> {noformat}
> Logs from both sides of the stream:
> Sides 1 -
> {noformat}
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:111 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Creating new streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52723] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 13 files(517391317 bytes), sending 10 
> files(469491729 bytes)
> ERROR [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,234 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> java.lang.IllegalArgumentException: Unknown type 0
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.81.104 is complete
> WARN  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:209 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Stream failed
> {noformat}
> Side 2 -
> {noformat}
> INFO  [AntiEntropyStage:1] 2015-10-05 23:52:30,060 StreamResultFuture.java:86 
> - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] Executing streaming plan for 
> Repair
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,061 
> StreamSession.java:232 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Starting streaming to /10.240.134.221
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,063 
> StreamCoordinator.java:213 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Beginning stream session with /10.240.134.221
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 10 files(469491729 bytes), sending 13 
> files(517391317 bytes)
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.134.221 is complete
> ERROR [STREAM-OUT-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe
>   at 
> org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:144) 
> ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:79)
>  

[jira] [Commented] (CASSANDRA-10910) Materialized view remained rows

[JIRA]

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

Gábor Auth commented on CASSANDRA-10910:


Thank you! What is the planned release date of the 3.0.3 version? :)

> Materialized view remained rows
> ---
>
> Key: CASSANDRA-10910
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10910
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.0.0
>Reporter: Gábor Auth
>Assignee: Carl Yeksigian
> Fix For: 3.0.3, 3.3
>
>
> I've created a table and a materialized view.
> {code}
> > CREATE TABLE test (id text PRIMARY KEY, key text, value int);
> > CREATE MATERIALIZED VIEW test_view AS SELECT * FROM test WHERE key IS NOT 
> > NULL PRIMARY KEY(key, id);
> {code}
> I've put a value into the table:
> {code}
> > update test set key='key', value=1 where id='id';
> > select * from test; select * from test_view ;
>  id | key | value
> +-+---
>  id | key | 1
> (1 rows)
>  key | id | value
> -++---
>  key | id | 1
> (1 rows)
> {code}
> I've updated the value without specified the key of the materialized view:
> {code}
> > update test set value=2 where id='id';
> > select * from test; select * from test_view ;
>  id | key | value
> +-+---
>  id | key | 2
> (1 rows)
>  key | id | value
> -++---
>  key | id | 2
> (1 rows)
> {code}
> It works as I think...
> ...but I've updated the key of the materialized view:
> {code}
> > update test set key='newKey' where id='id';
> > select * from test; select * from test_view ;
>  id | key| value
> ++---
>  id | newKey | 2
> (1 rows)
>  key| id | value
> ++---
> key | id | 2
>  newKey | id | 2
> (2 rows)
> {code}
> ...I've updated the value of the row:
> {code}
> > update test set key='newKey', value=3 where id='id';
> > select * from test; select * from test_view ;
>  id | key| value
> ++---
>  id | newKey | 3
> (1 rows)
>  key| id | value
> ++---
> key | id | 2
>  newKey | id | 3
> (2 rows)
> {code}
> ...I've deleted the row by the id key:
> {code}
> > delete from test where id='id';
> > select * from test; select * from test_view ;
>  id | key | value
> +-+---
> (0 rows)
>  key | id | value
> -++---
>  key | id | 2
> (1 rows)
> {code}
> Is it a bug?



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

[jira] [Commented] (CASSANDRA-10676) AssertionError in CompactionExecutor

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-10676:


I think you are right. Fix looks good.
Can you run tests on other branches also just to make sure?

> AssertionError in CompactionExecutor
> 
>
> Key: CASSANDRA-10676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10676
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: C* 2.1.9 on Debian Wheezy
>Reporter: mlowicki
>Assignee: Carl Yeksigian
> Fix For: 2.1.x
>
>
> {code}
> ERROR [CompactionExecutor:33329] 2015-11-09 08:16:22,759 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[CompactionExecutor:33329,1,main]
> java.lang.AssertionError: 
> /var/lib/cassandra/data/system/compactions_in_progress-55080ab05d9c388690a4acb25fe1f77b/system-compactions_in_progress-ka-888705-Data.db
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.getApproximateKeyCount(SSTableReader.java:279)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:151)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:73)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:236)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> ~[na:1.7.0_80]
>   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]
> ^C
> root@db1:~# tail -f /var/log/cassandra/system.log
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:151)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:73)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:236)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> ~[na:1.7.0_80]
>   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}



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

[jira] [Created] (CASSANDRA-10999) Implement mechanism in CQL to fetch a range of bytes from a blob object

[Jose Martinez Poblete (JIRA)]

Jose Martinez Poblete created CASSANDRA-10999:
-

 Summary: Implement mechanism in CQL to fetch a range of bytes from 
a blob object
 Key: CASSANDRA-10999
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10999
 Project: Cassandra
  Issue Type: Improvement
  Components: CQL
 Environment: Cassandra 2.1.11
Reporter: Jose Martinez Poblete


We are using Cassandra as a backing store for IMAP
IMAP has a byte range fetch feature which mail clients do use for previews, 
especially of large objects.

For the cases where we have large objects stored on the database, we would like 
to retrieve a byte subset rather than the whole object (could be a blob or 
binary encoded as text)

Could a feature like this be implemented?



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

[cassandra] Git Push Summary

[jake]

Repository: cassandra
Updated Tags:  refs/tags/cassandra-3.2 [created] 3d47b502c

[jira] [Commented] (CASSANDRA-10996) The system table system.schema_columnfamilies does not exist

[sangshenghong (JIRA)]

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

sangshenghong commented on CASSANDRA-10996:
---

I am working on Hive 1.1plus Hadoop 2.6 to support Cassandra 3.1, in previous, 
we want to get the following field value with this sql statament "

   String query = "select key_aliases,"
+ "column_aliases, "
+ "key_validator, "
+ "comparator "
+ "from system.schema_columnfamilies "
+ "where keyspace_name='%s' and columnfamily_name='%s'";

So now how to get the column value like key_aliases,column_aliases,comparator? 
Is there any example code ? or we can get these value from system_schema.* 
?thanks for caring this issue!

> The system table  system.schema_columnfamilies does not exist
> -
>
> Key: CASSANDRA-10996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10996
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: sangshenghong
>Priority: Critical
> Fix For: 3.1.1
>
> Attachments: error.png
>
>
> In the 2.1.6 version,there is one system table named 
> "system.schema_columnfamilies", but in the latest version 3.1.1, when I 
> execute select * from system.schema_columnfamilies, it throw "unconfigured 
> table schema_columnfamilies" in cqlsh.
> But in the system.log file, it show 
> ColumnFamilyStore.java:381 - Initializing system.schema_columnfamilies
> I checked the doc and found some tables and schemas have been change, so I 
> want to know if there any change for this?



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

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

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis edited comment on CASSANDRA-9318 at 1/11/16 2:26 PM:


Since most of that discussion is implementation details, I'll quote the 
relevant part:

bq. With consistency level less then ALL mutation processing can move to 
background (meaning client was answered, but there is still work to do on 
behalf of the request). If background request rate completion is lower than 
incoming request rate background request will accumulate and eventually will 
exhaust all memory resources. This patch's aim is to prevent this situation by 
monitoring how much memory all current background request take and when some 
threshold is passed stop moving request to background (by not replying to a 
client until either memory consumptions moves below the threshold or request is 
fully completed).

bq. There are two main point where each background mutation consumes memory: 
holding frozen mutation until operation is complete in order to hint 
if it does not) and on rpc queue to each replica where it sits until it's sent 
out on the wire. The patch accounts for both of those separately and limits the 
former to be 10% of total memory and the later to be 6M. Why 6M? The best 
answer I can give is why not :) But on a more serious note the number should be 
small enough so that all the data can be sent out in a reasonable amount of 
time and one shard is not capable to achieve even close to a full bandwidth, so 
empirical evidence shows 6M to be a good number. 


was (Author: jbellis):
Since most of that discussion is implementation details, I'll quote the 
relevant part:

bq. With consistency level less then ALL mutation processing can move to
background (meaning client was answered, but there is still work to
do on behalf of the request). If background request rate completion
is lower than incoming request rate background request will accumulate
and eventually will exhaust all memory resources. This patch's aim is
to prevent this situation by monitoring how much memory all current
background request take and when some threshold is passed stop moving
request to background (by not replying to a client until either memory
consumptions moves below the threshold or request is fully completed).

bq. There are two main point where each background mutation consumes memory:
holding frozen mutation until operation is complete in order to hint it
if it does not) and on rpc queue to each replica where it sits until it's
sent out on the wire. The patch accounts for both of those separately
and limits the former to be 10% of total memory and the later to be 6M.
Why 6M? The best answer I can give is why not :) But on a more serious
note the number should be small enough so that all the data can be
sent out in a reasonable amount of time and one shard is not capable to
achieve even close to a full bandwidth, so empirical evidence shows 6M
to be a good number. 

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



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

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

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis commented on CASSANDRA-9318:
---

Since most of that discussion is implementation details, I'll quote the 
relevant part:

bq. With consistency level less then ALL mutation processing can move to
background (meaning client was answered, but there is still work to
do on behalf of the request). If background request rate completion
is lower than incoming request rate background request will accumulate
and eventually will exhaust all memory resources. This patch's aim is
to prevent this situation by monitoring how much memory all current
background request take and when some threshold is passed stop moving
request to background (by not replying to a client until either memory
consumptions moves below the threshold or request is fully completed).

bq. There are two main point where each background mutation consumes memory:
holding frozen mutation until operation is complete in order to hint it
if it does not) and on rpc queue to each replica where it sits until it's
sent out on the wire. The patch accounts for both of those separately
and limits the former to be 10% of total memory and the later to be 6M.
Why 6M? The best answer I can give is why not :) But on a more serious
note the number should be small enough so that all the data can be
sent out in a reasonable amount of time and one shard is not capable to
achieve even close to a full bandwidth, so empirical evidence shows 6M
to be a good number. 

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



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

[jira] [Commented] (CASSANDRA-10743) Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10743:
--

I've been able to reproduce this with the dtest 
[here|https://github.com/pcmanus/cassandra-dtest/commit/060aa6d0e6383373f7515ed726769a801d21e5f8].
 Basically, this happens when a sstable index block finish in the middle of a 
collection tombstone. Unfortunately, that dtest is part of my local branch that 
was supposed to be merged to the dtests in CASSANDRA-10563 but that hasn't 
happen yet to the best of my knowledge. I have verified however that 1) this 
reproduce the problem when upgrading from 2.1 everytime on the current 3.0 
branch and 2) this work properly with the attached patches:
|| patch || utests || dtests ||
| [3.0|https://github.com/pcmanus/cassandra/commits/10743-3.0] | 
[utests|http://cassci.datastax.com/view/Dev/view/pcmanus/job/pcmanus-10743-3.0-testall/1/]
 | 
[dtests|http://cassci.datastax.com/view/Dev/view/pcmanus/job/pcmanus-10743-3.0-dtest/1/]
 |
| [3.3|https://github.com/pcmanus/cassandra/commits/10743-3.3] | 
[utests|http://cassci.datastax.com/view/Dev/view/pcmanus/job/pcmanus-10743-3.3-testall/1/]
 | 
[dtests|http://cassci.datastax.com/view/Dev/view/pcmanus/job/pcmanus-10743-3.3-dtest/1/]
 |
| [trunk|https://github.com/pcmanus/cassandra/commits/10743-trunk] | 
[utests|http://cassci.datastax.com/view/Dev/view/pcmanus/job/pcmanus-10743-trunk-testall/1/]
 | 
[dtests|http://cassci.datastax.com/view/Dev/view/pcmanus/job/pcmanus-10743-trunk-dtest/1/]
 |

I've just re-started the tests on all branches (in part because I just rebased) 
but had a successful run for the 3.0 branch of the patch so I think we're good 
here.


> Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)
> 
>
> Key: CASSANDRA-10743
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10743
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: CentOS Linux release 7.1.1503, OpenJDK Runtime 
> Environment (build 1.8.0_65-b17), DSC Cassandra 3.0.0 (tar.gz)
>Reporter: Gábor Auth
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.x
>
> Attachments: faulty-tables.tar.gz, schema.ddl
>
>
> {code}
> [cassandra@dc01-rack01-cass01 ~]$ 
> /home/cassandra/dsc-cassandra-3.0.0/bin/nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.UnsupportedOperationException
> at 
> org.apache.cassandra.db.rows.CellPath$EmptyCellPath.get(CellPath.java:143)
> at 
> org.apache.cassandra.db.marshal.CollectionType$CollectionPathSerializer.serializedSize(CollectionType.java:226)
> at 
> org.apache.cassandra.db.rows.BufferCell$Serializer.serializedSize(BufferCell.java:325)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.sizeOfComplexColumn(UnfilteredSerializer.java:297)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedRowBodySize(UnfilteredSerializer.java:282)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:163)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
> at 
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:144)
> at 
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:112)
> at 
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:52)
> at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> at 
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:121)
> at 
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:57)
> at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:110)
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:78)
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
> at 
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:397)
> at 
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:292)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> 

[jira] [Comment Edited] (CASSANDRA-10996) The system table system.schema_columnfamilies does not exist

[sangshenghong (JIRA)]

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

sangshenghong edited comment on CASSANDRA-10996 at 1/11/16 1:27 PM:


I am working on Hive 1.2 plus Hadoop 2.6 to support Cassandra 3.1, in previous, 
we want to get the following field value with this sql statament "

   String query = "select key_aliases,"
+ "column_aliases, "
+ "key_validator, "
+ "comparator "
+ "from system.schema_columnfamilies "
+ "where keyspace_name='%s' and columnfamily_name='%s'";

So now how to get the column value like key_aliases,column_aliases,comparator? 
Is there any example code ? or we can get these value from system_schema.* 
?thanks for caring this issue!


was (Author: sangshenghong):
I am working on Hive 1.1plus Hadoop 2.6 to support Cassandra 3.1, in previous, 
we want to get the following field value with this sql statament "

   String query = "select key_aliases,"
+ "column_aliases, "
+ "key_validator, "
+ "comparator "
+ "from system.schema_columnfamilies "
+ "where keyspace_name='%s' and columnfamily_name='%s'";

So now how to get the column value like key_aliases,column_aliases,comparator? 
Is there any example code ? or we can get these value from system_schema.* 
?thanks for caring this issue!

> The system table  system.schema_columnfamilies does not exist
> -
>
> Key: CASSANDRA-10996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10996
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: sangshenghong
>Priority: Critical
> Fix For: 3.1.1
>
> Attachments: error.png
>
>
> In the 2.1.6 version,there is one system table named 
> "system.schema_columnfamilies", but in the latest version 3.1.1, when I 
> execute select * from system.schema_columnfamilies, it throw "unconfigured 
> table schema_columnfamilies" in cqlsh.
> But in the system.log file, it show 
> ColumnFamilyStore.java:381 - Initializing system.schema_columnfamilies
> I checked the doc and found some tables and schemas have been change, so I 
> want to know if there any change for this?



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

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

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis edited comment on CASSANDRA-9318 at 1/11/16 2:27 PM:


Since most of that discussion is implementation details, I'll quote the 
relevant part:

bq. With consistency level less then ALL mutation processing can move to 
background (meaning client was answered, but there is still work to do on 
behalf of the request). If background request rate completion is lower than 
incoming request rate background request will accumulate and eventually will 
exhaust all memory resources. This patch's aim is to prevent this situation by 
monitoring how much memory all current background request take and when some 
threshold is passed stop moving request to background (by not replying to a 
client until either memory consumptions moves below the threshold or request is 
fully completed).

bq. There are two main point where each background mutation consumes memory: 
holding frozen mutation until operation is complete in order to hint if it does 
not) and on rpc queue to each replica where it sits until it's sent out on the 
wire. The patch accounts for both of those separately and limits the former to 
be 10% of total memory and the later to be 6M. Why 6M? The best answer I can 
give is why not :) But on a more serious note the number should be small enough 
so that all the data can be sent out in a reasonable amount of time and one 
shard is not capable to achieve even close to a full bandwidth, so empirical 
evidence shows 6M to be a good number. 


was (Author: jbellis):
Since most of that discussion is implementation details, I'll quote the 
relevant part:

bq. With consistency level less then ALL mutation processing can move to 
background (meaning client was answered, but there is still work to do on 
behalf of the request). If background request rate completion is lower than 
incoming request rate background request will accumulate and eventually will 
exhaust all memory resources. This patch's aim is to prevent this situation by 
monitoring how much memory all current background request take and when some 
threshold is passed stop moving request to background (by not replying to a 
client until either memory consumptions moves below the threshold or request is 
fully completed).

bq. There are two main point where each background mutation consumes memory: 
holding frozen mutation until operation is complete in order to hint 
if it does not) and on rpc queue to each replica where it sits until it's sent 
out on the wire. The patch accounts for both of those separately and limits the 
former to be 10% of total memory and the later to be 6M. Why 6M? The best 
answer I can give is why not :) But on a more serious note the number should be 
small enough so that all the data can be sent out in a reasonable amount of 
time and one shard is not capable to achieve even close to a full bandwidth, so 
empirical evidence shows 6M to be a good number. 

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



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

[jira] [Commented] (CASSANDRA-10563) Integrate new upgrade test into dtest upgrade suite

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10563:
--

[~mambocab] Any news on the progress of this. We still have no (or almost no) 
tests run by cassci that validate that 3.0 nodes are able to read 2.1/2.2 
sstables properly, and that's kind of critical. Especially since we're adding 
new such tests like in CASSANDRA-10743.

As reminder, the branch to merge (with adaptation so it runs on cassci 
properly) is: 
https://github.com/pcmanus/cassandra-dtest/commits/8099_upgrade_tests.

> Integrate new upgrade test into dtest upgrade suite
> ---
>
> Key: CASSANDRA-10563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10563
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Jim Witschey
>Assignee: Jim Witschey
> Fix For: 3.0.x
>
>
> This is a follow-up ticket for CASSANDRA-10360, specifically [~slebresne]'s 
> comment here:
> https://issues.apache.org/jira/browse/CASSANDRA-10360?focusedCommentId=14966539=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14966539
> These tests should be incorporated into the [{{upgrade_tests}} in 
> dtest|https://github.com/riptano/cassandra-dtest/tree/master/upgrade_tests]. 
> I'll take this on; [~nutbunnies] is also a good person for it, but I'll 
> likely get to it first.



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

[jira] [Commented] (CASSANDRA-10477) java.lang.AssertionError in StorageProxy.submitHint

[Jacques-Henri Berthemet (JIRA)]

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

Jacques-Henri Berthemet commented on CASSANDRA-10477:
-

I'm having the same problem on 2.2.3:
{code}
10:55:54.203 [ERROR] CassandraDaemon- Exception in thread 
Thread[EXPIRING-MAP-REAPER:1,5,UCS-Threads] java.lang.AssertionError: 
/
at 
org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:978)
at 
org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:399)
at 
org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:379)
at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98)
at 
org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
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}

What is the status on this issue? Can I expect this to be fixed in 2.2.x branch?

> java.lang.AssertionError in StorageProxy.submitHint
> ---
>
> Key: CASSANDRA-10477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10477
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: CentOS 6, Oracle JVM 1.8.45
>Reporter: Severin Leonhardt
>Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> A few days after updating from 2.0.15 to 2.1.9 we have the following log 
> entry on 2 of 5 machines:
> {noformat}
> ERROR [EXPIRING-MAP-REAPER:1] 2015-10-07 17:01:08,041 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[EXPIRING-MAP-REAPER:1,5,main]
> java.lang.AssertionError: /192.168.11.88
> at 
> org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:949) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:383) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:363) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> 192.168.11.88 is the broadcast address of the local machine.
> When this is logged the read request latency of the whole cluster becomes 
> very bad, from 6 ms/op to more than 100 ms/op according to OpsCenter. Clients 
> get a lot of timeouts. We need to restart the affected Cassandra node to get 
> back normal read latencies. It seems write latency is not affected.
> Disabling hinted handoff using {{nodetool disablehandoff}} only prevents the 
> assert from being logged. At some point the read latency becomes bad again. 
> Restarting the node where hinted handoff was disabled results in the read 
> latency being better again.



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

[jira] [Commented] (CASSANDRA-10477) java.lang.AssertionError in StorageProxy.submitHint

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10477:
--

[~aweisberg] the ball is in your court I believe.

> java.lang.AssertionError in StorageProxy.submitHint
> ---
>
> Key: CASSANDRA-10477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10477
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: CentOS 6, Oracle JVM 1.8.45
>Reporter: Severin Leonhardt
>Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> A few days after updating from 2.0.15 to 2.1.9 we have the following log 
> entry on 2 of 5 machines:
> {noformat}
> ERROR [EXPIRING-MAP-REAPER:1] 2015-10-07 17:01:08,041 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[EXPIRING-MAP-REAPER:1,5,main]
> java.lang.AssertionError: /192.168.11.88
> at 
> org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:949) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:383) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:363) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> 192.168.11.88 is the broadcast address of the local machine.
> When this is logged the read request latency of the whole cluster becomes 
> very bad, from 6 ms/op to more than 100 ms/op according to OpsCenter. Clients 
> get a lot of timeouts. We need to restart the affected Cassandra node to get 
> back normal read latencies. It seems write latency is not affected.
> Disabling hinted handoff using {{nodetool disablehandoff}} only prevents the 
> assert from being logged. At some point the read latency becomes bad again. 
> Restarting the node where hinted handoff was disabled results in the read 
> latency being better again.



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

[jira] [Commented] (CASSANDRA-7306) Support "edge dcs" with more flexible gossip

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis commented on CASSANDRA-7306:
---

What happens if data is supposed to be sent to a replica that is on the gossip 
blacklist?

> Support "edge dcs" with more flexible gossip
> 
>
> Key: CASSANDRA-7306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7306
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Distributed Metadata
>Reporter: Tupshin Harper
>Assignee: Jeff Jirsa
>  Labels: ponies
>
> As Cassandra clusters get bigger and bigger, and their topology becomes more 
> complex, there is more and more need for a notion of "hub" and "spoke" 
> datacenters.
> One of the big obstacles to supporting hundreds (or thousands) of remote dcs, 
> is the assumption that all dcs need to talk to each other (and be connected 
> all the time).
> This ticket is a vague placeholder with the goals of achieving:
> 1) better behavioral support for occasionally disconnected datacenters
> 2) explicit support for custom dc to dc routing. A simple approach would be 
> an optional per-dc annotation of which other DCs that DC could gossip with.



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

[jira] [Commented] (CASSANDRA-10961) Not enough bytes error when add nodes to cluster

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-10961:


Thanks Paulo.
Patch and tests look good. Can you go ahead and create branches for 3.0+?

> Not enough bytes error when add nodes to cluster
> 
>
> Key: CASSANDRA-10961
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10961
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: xiaost
>Assignee: Paulo Motta
> Attachments: apache-cassandra-2.2.4-SNAPSHOT.jar, debug.1.log, 
> debug.logs.zip, netstats.1.log
>
>
> we got the same problem all the time when we add nodes to cluster.
> netstats:
> on HostA
> {noformat}
> /la-38395-big-Data.db 14792091851/14792091851 bytes(100%) sent to idx:0/HostB
> {noformat}
> on HostB
> {noformat}
> tmp-la-4-big-Data.db 2667087450/14792091851 bytes(18%) received from 
> idx:0/HostA
> {noformat}
> After a while, Error on HostB
> {noformat}
> WARN  [STREAM-IN-/HostA] 2016-01-02 12:08:14,737 StreamSession.java:644 - 
> [Stream #b91a4e90-b105-11e5-bd57-dd0cc3b4634c] Retrying for following error
> java.lang.IllegalArgumentException: Not enough bytes
> at 
> org.apache.cassandra.db.composites.AbstractCType.checkRemaining(AbstractCType.java:362)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.db.composites.AbstractCompoundCellNameType.fromByteBuffer(AbstractCompoundCellNameType.java:98)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:381)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:365)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:75)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52) 
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46) 
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>  ~[guava-16.0.jar:na]
> at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) 
> ~[guava-16.0.jar:na]
> at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.appendFromStream(BigTableWriter.java:243)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.streaming.StreamReader.writeRow(StreamReader.java:173) 
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.streaming.compress.CompressedStreamReader.read(CompressedStreamReader.java:95)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:49)
>  [apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:38)
>  [apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:58)
>  [apache-cassandra-2.2.4.jar:2.2.4]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
>  [apache-cassandra-2.2.4.jar:2.2.4]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66-internal]
> ERROR [Thread-28] 2016-01-02 12:08:14,737 CassandraDaemon.java:185 - 
> Exception in thread Thread[Thread-28,5,main]
> java.lang.RuntimeException: java.lang.InterruptedException
> 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.2.4.jar:2.2.4]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_66-internal]
> Caused by: java.lang.InterruptedException: null
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220)
>  ~[na:1.8.0_66-internal]
> at 
> java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:335)
>  ~[na:1.8.0_66-internal]
> at 
> java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:350) 
> ~[na:1.8.0_66-internal]
> at 
> org.apache.cassandra.streaming.compress.CompressedInputStream$Reader.runMayThrow(CompressedInputStream.java:176)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
> at 
> 

[jira] [Commented] (CASSANDRA-10743) Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)

[Tomas Ramanauskas (JIRA)]

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

Tomas Ramanauskas commented on CASSANDRA-10743:
---

Thanks, [~slebresne]. Will the patch be available in 3.1.2? We currently run 
3.1.0, but without "nodetool upgradesstables". I'd like to upgrade 3.1.0 to the 
latest 3.1.x and then run  "nodetool upgradesstables".

> Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)
> 
>
> Key: CASSANDRA-10743
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10743
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: CentOS Linux release 7.1.1503, OpenJDK Runtime 
> Environment (build 1.8.0_65-b17), DSC Cassandra 3.0.0 (tar.gz)
>Reporter: Gábor Auth
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.x
>
> Attachments: faulty-tables.tar.gz, schema.ddl
>
>
> {code}
> [cassandra@dc01-rack01-cass01 ~]$ 
> /home/cassandra/dsc-cassandra-3.0.0/bin/nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.UnsupportedOperationException
> at 
> org.apache.cassandra.db.rows.CellPath$EmptyCellPath.get(CellPath.java:143)
> at 
> org.apache.cassandra.db.marshal.CollectionType$CollectionPathSerializer.serializedSize(CollectionType.java:226)
> at 
> org.apache.cassandra.db.rows.BufferCell$Serializer.serializedSize(BufferCell.java:325)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.sizeOfComplexColumn(UnfilteredSerializer.java:297)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedRowBodySize(UnfilteredSerializer.java:282)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:163)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
> at 
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:144)
> at 
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:112)
> at 
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:52)
> at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> at 
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:121)
> at 
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:57)
> at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:110)
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:78)
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
> at 
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:397)
> at 
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:292)
> 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}



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

[jira] [Commented] (CASSANDRA-10909) NPE in ActiveRepairService

[Eduard Tudenhoefner (JIRA)]

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

Eduard Tudenhoefner commented on CASSANDRA-10909:
-

This happened in a multi-node/multi-DC cluster, where *nodetool repair* was 
triggered on multiple nodes at the same time (I know that this isn't something 
that should be done)

> NPE in ActiveRepairService 
> ---
>
> Key: CASSANDRA-10909
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10909
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra-3.0.1.777
>Reporter: Eduard Tudenhoefner
>Assignee: Marcus Eriksson
>
> NPE after one started multiple incremental repairs
> {code}
> INFO  [Thread-62] 2015-12-21 11:40:53,742  RepairRunnable.java:125 - Starting 
> repair command #1, repairing keyspace keyspace1 with repair options 
> (parallelism: parallel, primary range: false, incremental: true, job threads: 
> 1, ColumnFamilies: [], dataCenters: [], hosts: [], # of ranges: 2)
> INFO  [Thread-62] 2015-12-21 11:40:53,813  RepairSession.java:237 - [repair 
> #b13e3740-a7d7-11e5-b568-f565b837eb0d] new session: will sync /10.200.177.32, 
> /10.200.177.33 on range [(10,-9223372036854775808]] for keyspace1.[counter1, 
> standard1]
> INFO  [Repair#1:1] 2015-12-21 11:40:53,853  RepairJob.java:100 - [repair 
> #b13e3740-a7d7-11e5-b568-f565b837eb0d] requesting merkle trees for counter1 
> (to [/10.200.177.33, /10.200.177.32])
> INFO  [Repair#1:1] 2015-12-21 11:40:53,853  RepairJob.java:174 - [repair 
> #b13e3740-a7d7-11e5-b568-f565b837eb0d] Requesting merkle trees for counter1 
> (to [/10.200.177.33, /10.200.177.32])
> INFO  [Thread-62] 2015-12-21 11:40:53,854  RepairSession.java:237 - [repair 
> #b1449fe0-a7d7-11e5-b568-f565b837eb0d] new session: will sync /10.200.177.32, 
> /10.200.177.31 on range [(0,10]] for keyspace1.[counter1, standard1]
> INFO  [AntiEntropyStage:1] 2015-12-21 11:40:53,896  RepairSession.java:181 - 
> [repair #b13e3740-a7d7-11e5-b568-f565b837eb0d] Received merkle tree for 
> counter1 from /10.200.177.32
> INFO  [AntiEntropyStage:1] 2015-12-21 11:40:53,906  RepairSession.java:181 - 
> [repair #b13e3740-a7d7-11e5-b568-f565b837eb0d] Received merkle tree for 
> counter1 from /10.200.177.33
> INFO  [Repair#1:1] 2015-12-21 11:40:53,906  RepairJob.java:100 - [repair 
> #b13e3740-a7d7-11e5-b568-f565b837eb0d] requesting merkle trees for standard1 
> (to [/10.200.177.33, /10.200.177.32])
> INFO  [Repair#1:1] 2015-12-21 11:40:53,906  RepairJob.java:174 - [repair 
> #b13e3740-a7d7-11e5-b568-f565b837eb0d] Requesting merkle trees for standard1 
> (to [/10.200.177.33, /10.200.177.32])
> INFO  [RepairJobTask:2] 2015-12-21 11:40:53,910  SyncTask.java:66 - [repair 
> #b13e3740-a7d7-11e5-b568-f565b837eb0d] Endpoints /10.200.177.33 and 
> /10.200.177.32 are consistent for counter1
> INFO  [RepairJobTask:1] 2015-12-21 11:40:53,910  RepairJob.java:145 - [repair 
> #b13e3740-a7d7-11e5-b568-f565b837eb0d] counter1 is fully synced
> INFO  [AntiEntropyStage:1] 2015-12-21 11:40:54,823  Validator.java:272 - 
> [repair #b17a2ed0-a7d7-11e5-ada8-8304f5629908] Sending completed merkle tree 
> to /10.200.177.33 for keyspace1.counter1
> ERROR [ValidationExecutor:3] 2015-12-21 11:40:55,104  
> CompactionManager.java:1065 - Cannot start multiple repair sessions over the 
> same sstables
> ERROR [ValidationExecutor:3] 2015-12-21 11:40:55,105  Validator.java:259 - 
> Failed creating a merkle tree for [repair 
> #b17a2ed0-a7d7-11e5-ada8-8304f5629908 on keyspace1/standard1, 
> [(10,-9223372036854775808]]], /10.200.177.33 (see log for details)
> ERROR [ValidationExecutor:3] 2015-12-21 11:40:55,110  
> CassandraDaemon.java:195 - Exception in thread 
> Thread[ValidationExecutor:3,1,main]
> java.lang.RuntimeException: Cannot start multiple repair sessions over the 
> same sstables
>   at 
> org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:1066)
>  ~[cassandra-all-3.0.1.777.jar:3.0.1.777]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager.access$700(CompactionManager.java:80)
>  ~[cassandra-all-3.0.1.777.jar:3.0.1.777]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$10.call(CompactionManager.java:679)
>  ~[cassandra-all-3.0.1.777.jar:3.0.1.777]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_40]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_40]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_40]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40]
> ERROR [AntiEntropyStage:1] 2015-12-21 11:40:55,174  
> RepairMessageVerbHandler.java:161 - Got error, removing parent repair session
> INFO  [CompactionExecutor:3] 

[jira] [Commented] (CASSANDRA-9830) Option to disable bloom filter in highest level of LCS sstables

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-9830:
---

A new run just finished, and the results look much more like what we would have 
expected.

Once you have finished adding support for the major LCS compaction skipping 
bloom filters, we should add the {{compact}} step back in and check the results 
again, otherwise it looks like this patch is having the desired effects of 
reducing memory usage while not reducing performance.

* blade-11-2a
** trunk
{noformat}
SSTable count: 26
SSTables in each level: [0, 10, 16, 0, 0, 0, 0, 0, 0]
Space used (live): 4666235284
Space used (total): 4666235284
Bloom filter false positives: 69
Bloom filter false ratio: 0.0
Bloom filter space used: 99436392
Bloom filter off heap memory used: 99436184
{noformat}
** skip_top_level_bloom_filter
{noformat}
SSTable count: 26
SSTables in each level: [0, 10, 16, 0, 0, 0, 0, 0, 0]
Space used (live): 4388657699
Space used (total): 4388657699
Bloom filter false positives: 586
Bloom filter false ratio: 0.2
Bloom filter space used: 51519600
Bloom filter off heap memory used: 51519520
{noformat}
* blade-11-3a
** trunk
{noformat}
SSTable count: 26
SSTables in each level: [0, 10, 16, 0, 0, 0, 0, 0, 0]
Space used (live): 4666224073
Space used (total): 4666224073
Bloom filter false positives: 51
Bloom filter false ratio: 0.0
Bloom filter space used: 99436568
Bloom filter off heap memory used: 99436360
{noformat}
** skip_top_level_bloom_filter
{noformat}
SSTable count: 26
SSTables in each level: [0, 10, 16, 0, 0, 0, 0, 0, 0]
Space used (live): 4394200299
Space used (total): 4394200299
Bloom filter false positives: 636
Bloom filter false ratio: 0.2
Bloom filter space used: 51392880
Bloom filter off heap memory used: 51392800
{noformat}
* blade-11-4a
** trunk
{noformat}
SSTable count: 26
SSTables in each level: [0, 10, 16, 0, 0, 0, 0, 0, 0]
Space used (live): 4590486878
Space used (total): 4590486878
Bloom filter false positives: 55
Bloom filter false ratio: 0.0
Bloom filter space used: 58160752
Bloom filter off heap memory used: 58160544
{noformat}
** skip_top_level_bloom_filter
{noformat}
SSTable count: 26
SSTables in each level: [0, 10, 16, 0, 0, 0, 0, 0, 0]
Space used (live): 4388596350
Space used (total): 4388596350
Bloom filter false positives: 560
Bloom filter false ratio: 0.2
Bloom filter space used: 51519600
Bloom filter off heap memory used: 51519520
{noformat}


> Option to disable bloom filter in highest level of LCS sstables
> ---
>
> Key: CASSANDRA-9830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9830
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Compaction
>Reporter: Jonathan Ellis
>Assignee: Paulo Motta
>Priority: Minor
>  Labels: performance
> Fix For: 3.x
>
>
> We expect about 90% of data to be in the highest level of LCS in a fully 
> populated series.  (See also CASSANDRA-9829.)
> Thus if the user is primarily asking for data (partitions) that has actually 
> been inserted, the bloom filter on the highest level only helps reject 
> sstables about 10% of the time.
> We should add an option that suppresses bloom filter creation on top-level 
> sstables.  This will dramatically reduce memory usage for LCS and may even 
> improve performance as we no longer check a low-value filter.
> (This is also an idea from RocksDB.)



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

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

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-8844:
---

{quote}
I'm in favor of the cluster-wide policy vs. per-keyspace
{quote}
You mean node-wide, not cluster-wide, correct? That is, this setting will end 
up in the yaml, not the schema, right?

> 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 easy and efficient to do with low 
> 

[jira] [Commented] (CASSANDRA-10477) java.lang.AssertionError in StorageProxy.submitHint

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10477:


Rebased, updated commit message, updated test matrix, started tests.
|[2.1 
code|https://github.com/apache/cassandra/compare/cassandra-2.1...aweisberg:CASSANDRA-10477-test]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10477-test-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10477-test-dtest/]|
|[3.0 
code|https://github.com/apache/cassandra/compare/cassandra-3.0...aweisberg:CASSANDRA-10477-3.0]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10477-3.0-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10477-3.0-dtest/]|
|[3.3 
code|https://github.com/apache/cassandra/compare/cassandra-3.3...aweisberg:CASSANDRA-10477-3.3]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10477-3.3-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10477-3.3-dtest/]|
|[Trunk 
code|https://github.com/apache/cassandra/compare/trunk...aweisberg:CASSANDRA-10477-trunk]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10477-trunk-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10477-trunk-dtest/]|

> java.lang.AssertionError in StorageProxy.submitHint
> ---
>
> Key: CASSANDRA-10477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10477
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: CentOS 6, Oracle JVM 1.8.45
>Reporter: Severin Leonhardt
>Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> A few days after updating from 2.0.15 to 2.1.9 we have the following log 
> entry on 2 of 5 machines:
> {noformat}
> ERROR [EXPIRING-MAP-REAPER:1] 2015-10-07 17:01:08,041 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[EXPIRING-MAP-REAPER:1,5,main]
> java.lang.AssertionError: /192.168.11.88
> at 
> org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:949) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:383) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:363) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> 192.168.11.88 is the broadcast address of the local machine.
> When this is logged the read request latency of the whole cluster becomes 
> very bad, from 6 ms/op to more than 100 ms/op according to OpsCenter. Clients 
> get a lot of timeouts. We need to restart the affected Cassandra node to get 
> back normal read latencies. It seems write latency is not affected.
> Disabling hinted handoff using {{nodetool disablehandoff}} only prevents the 
> assert from being logged. At some point the read latency becomes bad again. 
> Restarting the node where hinted handoff was disabled results in the read 
> latency being better again.



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

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

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-9318:
---

I am not sure how they have structured things and why they need to do that. 
With a hard limit on ingest rate and a 2 second timeout there is a soft bound 
on how much memory can be committed. It's not a hard bound because there is no 
guarantee that the timeout thread will keep up.

I do think that switching requests from async to sync based on load is a better 
approach than enabling/disabling read on client connections. There can be a lot 
of client connections so that is something that can be time consuming.

I am not sold that we should do anything at all? We could add more code to 
address this, but I hate to do that when I can't demonstrate that I am solving 
a problem. I split off what I consider the good bits into CASSANDRA-10971 and 
CASSANDRA-10972. The delay has been other work, me considering this to be 
lowish priority since I can't demonstrate it, and difficulty getting hardware 
going that is capable of demonstrating the problem. I'm slowly iterating on it 
in the background right now.

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



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

[jira] [Commented] (CASSANDRA-10477) java.lang.AssertionError in StorageProxy.submitHint

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10477:


I agree the assertion should just be on the address. Already made the change 
back in December just need to get the tests done.

> java.lang.AssertionError in StorageProxy.submitHint
> ---
>
> Key: CASSANDRA-10477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10477
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: CentOS 6, Oracle JVM 1.8.45
>Reporter: Severin Leonhardt
>Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> A few days after updating from 2.0.15 to 2.1.9 we have the following log 
> entry on 2 of 5 machines:
> {noformat}
> ERROR [EXPIRING-MAP-REAPER:1] 2015-10-07 17:01:08,041 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[EXPIRING-MAP-REAPER:1,5,main]
> java.lang.AssertionError: /192.168.11.88
> at 
> org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:949) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:383) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:363) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> 192.168.11.88 is the broadcast address of the local machine.
> When this is logged the read request latency of the whole cluster becomes 
> very bad, from 6 ms/op to more than 100 ms/op according to OpsCenter. Clients 
> get a lot of timeouts. We need to restart the affected Cassandra node to get 
> back normal read latencies. It seems write latency is not affected.
> Disabling hinted handoff using {{nodetool disablehandoff}} only prevents the 
> assert from being logged. At some point the read latency becomes bad again. 
> Restarting the node where hinted handoff was disabled results in the read 
> latency being better again.



--
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=15092280#comment-15092280
 ] 

Joshua McKenzie commented on CASSANDRA-8844:


I'm in favor of the cluster-wide policy vs. per-keyspace after chewing on it 
over the weekend. We're already adding a significant amount of complexity to 
working with the CommitLog by having 2 paths for files to be written (CDC vs. 
non), adding a 3rd and then working with the resultant 2 overflow directories, 
tracking, etc - I don't think the benefits of the flexibility justify the 
complexity on implementation.

> 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
> 

[jira] [Commented] (CASSANDRA-10477) java.lang.AssertionError in StorageProxy.submitHint

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10477:
--

Can you also answer my comments on the assertion?

> java.lang.AssertionError in StorageProxy.submitHint
> ---
>
> Key: CASSANDRA-10477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10477
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: CentOS 6, Oracle JVM 1.8.45
>Reporter: Severin Leonhardt
>Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> A few days after updating from 2.0.15 to 2.1.9 we have the following log 
> entry on 2 of 5 machines:
> {noformat}
> ERROR [EXPIRING-MAP-REAPER:1] 2015-10-07 17:01:08,041 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[EXPIRING-MAP-REAPER:1,5,main]
> java.lang.AssertionError: /192.168.11.88
> at 
> org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:949) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:383) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:363) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> 192.168.11.88 is the broadcast address of the local machine.
> When this is logged the read request latency of the whole cluster becomes 
> very bad, from 6 ms/op to more than 100 ms/op according to OpsCenter. Clients 
> get a lot of timeouts. We need to restart the affected Cassandra node to get 
> back normal read latencies. It seems write latency is not affected.
> Disabling hinted handoff using {{nodetool disablehandoff}} only prevents the 
> assert from being logged. At some point the read latency becomes bad again. 
> Restarting the node where hinted handoff was disabled results in the read 
> latency being better again.



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

[jira] [Commented] (CASSANDRA-7272) Add "Major" Compaction to LCS

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-7272:
---

The L1 sstables won't overlap with the data in the L2, so none of the L2 
sstables should be selected due to overlap for the compaction with L1 sstables. 
Since we don't know exactly how many sstables we are going to compact to when 
we start the major compaction, we don't know which level would be optimal at 
the beginning, which is why we do layering instead.

If you are seeing a performance impact after performing a major LCS compaction, 
can you open a new ticket so that we can investigate?

> Add "Major" Compaction to LCS 
> --
>
> Key: CASSANDRA-7272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7272
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: T Jake Luciani
>Assignee: Marcus Eriksson
>Priority: Minor
>  Labels: compaction, docs-impacting
> Fix For: 2.2.0 beta 1
>
>
> LCS has a number of minor issues (maybe major depending on your perspective).
> LCS is primarily used for wide rows so for instance when you repair data in 
> LCS you end up with a copy of an entire repaired row in L0.  Over time if you 
> repair you end up with multiple copies of a row in L0 - L5.  This can make 
> predicting disk usage confusing.  
> Another issue is cleaning up tombstoned data.  If a tombstone lives in level 
> 1 and data for the cell lives in level 5 the data will not be reclaimed from 
> disk until the tombstone reaches level 5.
> I propose we add a "major" compaction for LCS that forces consolidation of 
> data to level 5 to address these.



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

[jira] [Commented] (CASSANDRA-10993) Make read and write requests paths fully non-blocking, eliminate related stages

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10993:
---

There will be a more detailed technical proposal (API, scheduler, interactions 
with Netty) to come later, after some necessary POC work is done.

> Make read and write requests paths fully non-blocking, eliminate related 
> stages
> ---
>
> Key: CASSANDRA-10993
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10993
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Coordination, Local Write-Read Paths
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
> Fix For: 3.x
>
>
> Building on work done by [~tjake] (CASSANDRA-10528), [~slebresne] 
> (CASSANDRA-5239), and others, convert read and write request paths to be 
> fully non-blocking, to enable the eventual transition from SEDA to TPC 
> (CASSANDRA-10989)
> Eliminate {{MUTATION}}, {{COUNTER_MUTATION}}, {{VIEW_MUTATION}}, {{READ}}, 
> and {{READ_REPAIR}} stages, move read and write execution directly to Netty 
> context.
> For lack of decent async I/O options on Linux, we’ll still have to retain an 
> extra thread pool for serving read requests for data not residing in our page 
> cache (CASSANDRA-5863), however.
> Implementation-wise, we only have two options available to us: explicit FSMs 
> and chained futures. Fibers would be the third, and easiest option, but 
> aren’t feasible in Java without resorting to direct bytecode manipulation 
> (ourselves or using [quasar|https://github.com/puniverse/quasar]).
> I have seen 4 implementations bases on chained futures/promises now - three 
> in Java and one in C++ - and I’m not convinced that it’s the optimal (or 
> sane) choice for representing our complex logic - think 2i quorum read 
> requests with timeouts at all levels, read repair (blocking and 
> non-blocking), and speculative retries in the mix, {{SERIAL}} reads and 
> writes.
> I’m currently leaning towards an implementation based on explicit FSMs, and 
> intend to provide a prototype - soonish - for comparison with 
> {{CompletableFuture}}-like variants.
> Either way the transition is a relatively boring straightforward refactoring.
> There are, however, some extension points on both write and read paths that 
> we do not control:
> - authorisation implementations will have to be non-blocking. We have control 
> over built-in ones, but for any custom implementation we will have to execute 
> them in a separate thread pool
> - 2i hooks on the write path will need to be non-blocking
> - any trigger implementations will not be allowed to block
> - UDFs and UDAs
> We are further limited by API compatibility restrictions in the 3.x line, 
> forbidding us to alter, or add any non-{{default}} interface methods to those 
> extension points, so these pose a problem.
> Depending on logistics, expecting to get this done in time for 3.4 or 3.6 
> feature release.



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

[jira] [Updated] (CASSANDRA-10743) Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-10743:
-
Reviewer: Benedict

> Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)
> 
>
> Key: CASSANDRA-10743
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10743
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: CentOS Linux release 7.1.1503, OpenJDK Runtime 
> Environment (build 1.8.0_65-b17), DSC Cassandra 3.0.0 (tar.gz)
>Reporter: Gábor Auth
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.x
>
> Attachments: faulty-tables.tar.gz, schema.ddl
>
>
> {code}
> [cassandra@dc01-rack01-cass01 ~]$ 
> /home/cassandra/dsc-cassandra-3.0.0/bin/nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.UnsupportedOperationException
> at 
> org.apache.cassandra.db.rows.CellPath$EmptyCellPath.get(CellPath.java:143)
> at 
> org.apache.cassandra.db.marshal.CollectionType$CollectionPathSerializer.serializedSize(CollectionType.java:226)
> at 
> org.apache.cassandra.db.rows.BufferCell$Serializer.serializedSize(BufferCell.java:325)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.sizeOfComplexColumn(UnfilteredSerializer.java:297)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedRowBodySize(UnfilteredSerializer.java:282)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:163)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
> at 
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:144)
> at 
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:112)
> at 
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:52)
> at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> at 
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:121)
> at 
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:57)
> at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:110)
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:78)
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
> at 
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:397)
> at 
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:292)
> 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}



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

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

[Brandon Williams (JIRA)]

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

Brandon Williams commented on CASSANDRA-10726:
--

I understand your sentiment, but maybe a -D flag for the 'power user' isn't too 
awful?

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



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

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

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10726:
---

bq. I understand your sentiment, but maybe a -D flag for the 'power user' isn't 
too awful?

I agree. We lose nothing here by providing a -D flag.

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



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

[jira] [Commented] (CASSANDRA-10688) Stack overflow from SSTableReader$InstanceTidier.runOnClose in Leak Detector

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10688:


Rebased and started tests. Also created merge forward branches and tests.
|[3.0 
code|https://github.com/apache/cassandra/compare/cassandra-3.0...aweisberg:CASSANDRA-10688-3.0?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10688-3.0-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10688-3.0-dtest/]|
|[3.3 
code|https://github.com/apache/cassandra/compare/cassandra-3.3...aweisberg:CASSANDRA-10688-3.3?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10688-3.3-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10688-3.3-dtest/]|
|[trunk 
code|https://github.com/apache/cassandra/compare/trunk...aweisberg:CASSANDRA-10688-trunk?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10688-trunk-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10688-trunk-dtest/]|

> Stack overflow from SSTableReader$InstanceTidier.runOnClose in Leak Detector
> 
>
> Key: CASSANDRA-10688
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10688
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Testing
>Reporter: Jeremiah Jordan
>Assignee: Ariel Weisberg
> Fix For: 3.0.x
>
>
> Running some tests against cassandra-3.0 
> 9fc957cf3097e54ccd72e51b2d0650dc3e83eae0
> The tests are just running cassandra-stress write and read while adding and 
> removing nodes from the cluster.  After the test runs when I go back through 
> logs I find the following Stackoverflow fairly often:
> ERROR [Strong-Reference-Leak-Detector:1] 2015-11-11 00:04:10,638  
> Ref.java:413 - Stackoverflow [private java.lang.Runnable 
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier.runOnClose,
>  final java.lang.Runnable 
> org.apache.cassandra.io.sstable.format.SSTableReader$DropPageCache.andThen, 
> final org.apache.cassandra.cache.InstrumentingCache 
> org.apache.cassandra.io.sstable.SSTableRewriter$InvalidateKeys.cache, private 
> final org.apache.cassandra.cache.ICache 
> org.apache.cassandra.cache.InstrumentingCache.map, private final 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap 
> org.apache.cassandra.cache.ConcurrentLinkedHashCache.map, final 
> com.googlecode.concurrentlinkedhashmap.LinkedDeque 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap.evictionDeque, 
> com.googlecode.concurrentlinkedhashmap.Linked 
> com.googlecode.concurrentlinkedhashmap.LinkedDeque.first, 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next, 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next, 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next, 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next, 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next, 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next, 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next, 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next, 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next, 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node 
> ... (repeated a whole bunch more)  
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next, 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next, 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next, 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node 
> 

[jira] [Assigned] (CASSANDRA-10995) Consider disabling sstable compression by default in 3.x

[Jim Witschey (JIRA)]

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

Jim Witschey reassigned CASSANDRA-10995:


Assignee: Jim Witschey

> Consider disabling sstable compression by default in 3.x
> 
>
> Key: CASSANDRA-10995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10995
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Jim Witschey
>
> With the new sstable format introduced in CASSANDRA-8099, it's very likely 
> that enabled sstable compression is no longer the right default option.
> [~slebresne]'s [blog post|http://www.datastax.com/2015/12/storage-engine-30] 
> on the new storage engine has some comparison numbers for 2.2/3.0, with and 
> without compression that show that in many cases compression no longer has a 
> significant effect on sstable sizes - all while sill consuming extra 
> resources for both writes (compression) and reads (decompression).
> We should run a comprehensive set of benchmarks to determine whether or not 
> compression should be switched to 'off' now in 3.x.



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

[jira] [Commented] (CASSANDRA-10993) Make read and write requests paths fully non-blocking, eliminate related stages

[T Jake Luciani (JIRA)]

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

T Jake Luciani commented on CASSANDRA-10993:


I'm disappointed there has been no discussion of CASSANDRA-10528

While it's clear there is no desire to adopt rxjava there is no acknowledgement 
of concerns or drawbacks by anyone (publicly).
I think it's great to have an alternative approach discussed, but there is also 
no design or plan laid out as well.  So to that end I'm going to take the 
RxJava branch further to at least offer a counterpoint to whatever comes out of 
this effort. 

> Make read and write requests paths fully non-blocking, eliminate related 
> stages
> ---
>
> Key: CASSANDRA-10993
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10993
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Coordination, Local Write-Read Paths
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
> Fix For: 3.x
>
>
> Building on work done by [~tjake] (CASSANDRA-10528), [~slebresne] 
> (CASSANDRA-5239), and others, convert read and write request paths to be 
> fully non-blocking, to enable the eventual transition from SEDA to TPC 
> (CASSANDRA-10989)
> Eliminate {{MUTATION}}, {{COUNTER_MUTATION}}, {{VIEW_MUTATION}}, {{READ}}, 
> and {{READ_REPAIR}} stages, move read and write execution directly to Netty 
> context.
> For lack of decent async I/O options on Linux, we’ll still have to retain an 
> extra thread pool for serving read requests for data not residing in our page 
> cache (CASSANDRA-5863), however.
> Implementation-wise, we only have two options available to us: explicit FSMs 
> and chained futures. Fibers would be the third, and easiest option, but 
> aren’t feasible in Java without resorting to direct bytecode manipulation 
> (ourselves or using [quasar|https://github.com/puniverse/quasar]).
> I have seen 4 implementations bases on chained futures/promises now - three 
> in Java and one in C++ - and I’m not convinced that it’s the optimal (or 
> sane) choice for representing our complex logic - think 2i quorum read 
> requests with timeouts at all levels, read repair (blocking and 
> non-blocking), and speculative retries in the mix, {{SERIAL}} reads and 
> writes.
> I’m currently leaning towards an implementation based on explicit FSMs, and 
> intend to provide a prototype - soonish - for comparison with 
> {{CompletableFuture}}-like variants.
> Either way the transition is a relatively boring straightforward refactoring.
> There are, however, some extension points on both write and read paths that 
> we do not control:
> - authorisation implementations will have to be non-blocking. We have control 
> over built-in ones, but for any custom implementation we will have to execute 
> them in a separate thread pool
> - 2i hooks on the write path will need to be non-blocking
> - any trigger implementations will not be allowed to block
> - UDFs and UDAs
> We are further limited by API compatibility restrictions in the 3.x line, 
> forbidding us to alter, or add any non-{{default}} interface methods to those 
> extension points, so these pose a problem.
> Depending on logistics, expecting to get this done in time for 3.4 or 3.6 
> feature release.



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

[jira] [Commented] (CASSANDRA-10743) Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)

[Benedict (JIRA)]

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

Benedict commented on CASSANDRA-10743:
--

LGTM

> Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)
> 
>
> Key: CASSANDRA-10743
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10743
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: CentOS Linux release 7.1.1503, OpenJDK Runtime 
> Environment (build 1.8.0_65-b17), DSC Cassandra 3.0.0 (tar.gz)
>Reporter: Gábor Auth
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.x
>
> Attachments: faulty-tables.tar.gz, schema.ddl
>
>
> {code}
> [cassandra@dc01-rack01-cass01 ~]$ 
> /home/cassandra/dsc-cassandra-3.0.0/bin/nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.UnsupportedOperationException
> at 
> org.apache.cassandra.db.rows.CellPath$EmptyCellPath.get(CellPath.java:143)
> at 
> org.apache.cassandra.db.marshal.CollectionType$CollectionPathSerializer.serializedSize(CollectionType.java:226)
> at 
> org.apache.cassandra.db.rows.BufferCell$Serializer.serializedSize(BufferCell.java:325)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.sizeOfComplexColumn(UnfilteredSerializer.java:297)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedRowBodySize(UnfilteredSerializer.java:282)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:163)
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
> at 
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:144)
> at 
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:112)
> at 
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:52)
> at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> at 
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:121)
> at 
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:57)
> at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:110)
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:78)
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
> at 
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:397)
> at 
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:292)
> 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}



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

[jira] [Commented] (CASSANDRA-9949) maxPurgeableTimestamp needs to check memtables too

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-9949:
-

Thanks for clarifying the fix version. 

Re. performance are you concerned by the loop on all cells in a column family? 
We could approximate the min timestamp with the memtable creation time but I 
don't think this is a good approximation and it's probably wrong if we receive 
a partition from a remote host with an older timestamp. Storing the minimum 
timestamp in a column family and keeping it up-to-date requires a bit of work 
but we can go down this route if it is the correct choice. However I feel there 
may be a different approximation that I am missing.

I also could use some hints on how to test this. Do you think a dtest is 
achievable? I'm not so sure how easy it is to simulate a 'very-out-of-order' 
write.

> maxPurgeableTimestamp needs to check memtables too
> --
>
> Key: CASSANDRA-9949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9949
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Jonathan Ellis
>Assignee: Stefania
> Fix For: 2.1.x, 2.2.x
>
>
> overlapIterator/maxPurgeableTimestamp don't include the memtables, so a 
> very-out-of-order write could be ignored



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

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

[Richard Low (JIRA)]

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

Richard Low commented on CASSANDRA-10726:
-

It would lose a guarantee (which admittedly I didn't know existed), but most 
people who care about what happens when there's a write timeout will use CAS 
read and write.

Would a reasonable half way house be to keep the write as blocking but return 
success in the case of a write timeout? Then almost always the behaviour will 
be the same, but it would avoid the timeouts caused by a single broken replica.

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



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

[jira] [Commented] (CASSANDRA-10477) java.lang.AssertionError in StorageProxy.submitHint

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10477:


The tests are passing, but enough time has passed that I should rebase and test 
again. Will do that today.

> java.lang.AssertionError in StorageProxy.submitHint
> ---
>
> Key: CASSANDRA-10477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10477
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: CentOS 6, Oracle JVM 1.8.45
>Reporter: Severin Leonhardt
>Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> A few days after updating from 2.0.15 to 2.1.9 we have the following log 
> entry on 2 of 5 machines:
> {noformat}
> ERROR [EXPIRING-MAP-REAPER:1] 2015-10-07 17:01:08,041 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[EXPIRING-MAP-REAPER:1,5,main]
> java.lang.AssertionError: /192.168.11.88
> at 
> org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:949) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:383) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:363) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> 192.168.11.88 is the broadcast address of the local machine.
> When this is logged the read request latency of the whole cluster becomes 
> very bad, from 6 ms/op to more than 100 ms/op according to OpsCenter. Clients 
> get a lot of timeouts. We need to restart the affected Cassandra node to get 
> back normal read latencies. It seems write latency is not affected.
> Disabling hinted handoff using {{nodetool disablehandoff}} only prevents the 
> assert from being logged. At some point the read latency becomes bad again. 
> Restarting the node where hinted handoff was disabled results in the read 
> latency being better again.



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

[jira] [Commented] (CASSANDRA-10563) Integrate new upgrade test into dtest upgrade suite

[Jim Witschey (JIRA)]

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

Jim Witschey commented on CASSANDRA-10563:
--

I let this fall on the floor; my apologies. I spent a few minutes on it this 
morning and filed a PR here:

https://github.com/riptano/cassandra-dtest/pull/740

It's not ready for merge, it requires some style changes and possibly some 
refactoring to use existing upgrade test code, pending review by [~rhatch].

> Integrate new upgrade test into dtest upgrade suite
> ---
>
> Key: CASSANDRA-10563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10563
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Jim Witschey
>Assignee: Jim Witschey
>Priority: Critical
> Fix For: 3.0.x
>
>
> This is a follow-up ticket for CASSANDRA-10360, specifically [~slebresne]'s 
> comment here:
> https://issues.apache.org/jira/browse/CASSANDRA-10360?focusedCommentId=14966539=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14966539
> These tests should be incorporated into the [{{upgrade_tests}} in 
> dtest|https://github.com/riptano/cassandra-dtest/tree/master/upgrade_tests]. 
> I'll take this on; [~nutbunnies] is also a good person for it, but I'll 
> likely get to it first.



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

cassandra git commit: Remove misplaced lines in the changelog (they already are in for 3.0.3, which is the correct place)

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 eca74ad24 -> 6fdcaef20


Remove misplaced lines in the changelog (they already are in for 3.0.3, which 
is the correct place)


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

Branch: refs/heads/cassandra-3.0
Commit: 6fdcaef20b93b1116352d7094ecd7447dbdf5eb3
Parents: eca74ad
Author: Sylvain Lebresne 
Authored: Mon Jan 11 17:00:04 2016 +0100
Committer: Sylvain Lebresne 
Committed: Mon Jan 11 17:00:04 2016 +0100

--
 CHANGES.txt | 2 --
 1 file changed, 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6fdcaef2/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 25c93e9..36a6e43 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -73,8 +73,6 @@ Merged from 2.1:
  * Keep the file open in trySkipCache (CASSANDRA-10669)
  * Updated trigger example (CASSANDRA-10257)
 Merged from 2.2:
- * Fix regression on split size in CqlInputFormat (CASSANDRA-10835)
- * Better handling of SSL connection errors inter-node (CASSANDRA-10816)
  * Verify tables in pseudo-system keyspaces at startup (CASSANDRA-10761)
  * Fix IllegalArgumentException in DataOutputBuffer.reallocate for large 
buffers (CASSANDRA-10592)
  * Show CQL help in cqlsh in web browser (CASSANDRA-7225)

[jira] [Commented] (CASSANDRA-10816) Explicitly handle SSL handshake errors during connect()

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10816:
--

3.0.2 was a hotfix release that only included CASSANDRA-10822 on top of 3.0.1, 
so that patch is definitively not part of it as indicated by the fix-version on 
this ticket (it will be part of 3.0.3 however). But I'm not sure what happened 
to the changelog, some bad merge added the lines where they shouldn't be 
(CASSANDRA-10835 is in the exact same boat). I'll fix the changelog on the 3.0 
branch, but 3.0.2 has been release so no point in changing it now so sorry for 
the mistake.

> Explicitly handle SSL handshake errors during connect()
> ---
>
> Key: CASSANDRA-10816
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10816
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Fix For: 2.2.5, 3.0.3, 3.2
>
>
> Diagnosing internode SSL issues can be a problem as any messaging 
> {{IOException}} before this patch is just logged to debug, which is likely 
> not enabled in most cases. Logs will just show nothing in case of any 
> problems with SSL certs. 
> Also the implemented retry semantics in {{OutboundTcpConnection}} will not 
> make much sense for SSL handshake errors and will cause unnecessary load for 
> both peers.
> The proposed patch will explicitly catch {{SSLHandshakeException}}, log them 
> to error and abort connect().



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

[1/5] cassandra git commit: Remove misplaced lines in the changelog (they already are in for 3.0.3, which is the correct place)

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.3 b2af80b4a -> 4d9a0a1e6
  refs/heads/trunk 20e6750df -> 0bb63d285


Remove misplaced lines in the changelog (they already are in for 3.0.3, which 
is the correct place)


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

Branch: refs/heads/cassandra-3.3
Commit: 6fdcaef20b93b1116352d7094ecd7447dbdf5eb3
Parents: eca74ad
Author: Sylvain Lebresne 
Authored: Mon Jan 11 17:00:04 2016 +0100
Committer: Sylvain Lebresne 
Committed: Mon Jan 11 17:00:04 2016 +0100

--
 CHANGES.txt | 2 --
 1 file changed, 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6fdcaef2/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 25c93e9..36a6e43 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -73,8 +73,6 @@ Merged from 2.1:
  * Keep the file open in trySkipCache (CASSANDRA-10669)
  * Updated trigger example (CASSANDRA-10257)
 Merged from 2.2:
- * Fix regression on split size in CqlInputFormat (CASSANDRA-10835)
- * Better handling of SSL connection errors inter-node (CASSANDRA-10816)
  * Verify tables in pseudo-system keyspaces at startup (CASSANDRA-10761)
  * Fix IllegalArgumentException in DataOutputBuffer.reallocate for large 
buffers (CASSANDRA-10592)
  * Show CQL help in cqlsh in web browser (CASSANDRA-7225)

[5/5] cassandra git commit: Merge branch 'cassandra-3.3' into trunk

[slebresne]

Merge branch 'cassandra-3.3' into trunk


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

Branch: refs/heads/trunk
Commit: 0bb63d2852abc32261528abc192eabe76ef4480b
Parents: 20e6750 4d9a0a1
Author: Sylvain Lebresne 
Authored: Mon Jan 11 17:04:15 2016 +0100
Committer: Sylvain Lebresne 
Committed: Mon Jan 11 17:04:15 2016 +0100

--
 CHANGES.txt | 2 --
 1 file changed, 2 deletions(-)
--


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

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

[slebresne]

Merge branch 'cassandra-3.0' into cassandra-3.3


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

Branch: refs/heads/trunk
Commit: 4d9a0a1e67a1488c5628ff39df0a4a4cae21e67c
Parents: b2af80b 6fdcaef
Author: Sylvain Lebresne 
Authored: Mon Jan 11 17:04:05 2016 +0100
Committer: Sylvain Lebresne 
Committed: Mon Jan 11 17:04:05 2016 +0100

--
 CHANGES.txt | 2 --
 1 file changed, 2 deletions(-)
--


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

[4/5] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.3

[slebresne]

Merge branch 'cassandra-3.0' into cassandra-3.3


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

Branch: refs/heads/cassandra-3.3
Commit: 4d9a0a1e67a1488c5628ff39df0a4a4cae21e67c
Parents: b2af80b 6fdcaef
Author: Sylvain Lebresne 
Authored: Mon Jan 11 17:04:05 2016 +0100
Committer: Sylvain Lebresne 
Committed: Mon Jan 11 17:04:05 2016 +0100

--
 CHANGES.txt | 2 --
 1 file changed, 2 deletions(-)
--


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

[2/5] cassandra git commit: Remove misplaced lines in the changelog (they already are in for 3.0.3, which is the correct place)

[slebresne]

Remove misplaced lines in the changelog (they already are in for 3.0.3, which 
is the correct place)


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

Branch: refs/heads/trunk
Commit: 6fdcaef20b93b1116352d7094ecd7447dbdf5eb3
Parents: eca74ad
Author: Sylvain Lebresne 
Authored: Mon Jan 11 17:00:04 2016 +0100
Committer: Sylvain Lebresne 
Committed: Mon Jan 11 17:00:04 2016 +0100

--
 CHANGES.txt | 2 --
 1 file changed, 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6fdcaef2/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 25c93e9..36a6e43 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -73,8 +73,6 @@ Merged from 2.1:
  * Keep the file open in trySkipCache (CASSANDRA-10669)
  * Updated trigger example (CASSANDRA-10257)
 Merged from 2.2:
- * Fix regression on split size in CqlInputFormat (CASSANDRA-10835)
- * Better handling of SSL connection errors inter-node (CASSANDRA-10816)
  * Verify tables in pseudo-system keyspaces at startup (CASSANDRA-10761)
  * Fix IllegalArgumentException in DataOutputBuffer.reallocate for large 
buffers (CASSANDRA-10592)
  * Show CQL help in cqlsh in web browser (CASSANDRA-7225)