[jira] [Commented] (CASSANDRA-13741) Replace Cassandra's lz4-1.3.0.jar with lz4-java-1.4.0.jar

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-13741:


Github user ghatwala closed the pull request at:

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


> Replace Cassandra's lz4-1.3.0.jar with lz4-java-1.4.0.jar
> -
>
> Key: CASSANDRA-13741
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13741
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Amitkumar Ghatwal
>Assignee: Michael Kjellman
> Fix For: 4.0
>
>
> Hi All,
> The latest lz4-java library has been released 
> (https://github.com/lz4/lz4-java/releases) and uploaded to maven central . 
> Please replace in mainline the current version ( 1.3.0) with the latest one ( 
> 1.4.0) from here - http://repo1.maven.org/maven2/org/lz4/lz4-java/1.4.0/
> Adding : [~ReiOdaira].
> Regards,
> Amit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Resolved] (CASSANDRA-13800) dtest failure: native_transport_ssl_test.NativeTransportSSL.connect_to_ssl_test

[Jason Brown (JIRA)]

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

Jason Brown resolved CASSANDRA-13800.
-
Resolution: Cannot Reproduce

I've poked around the cassci and apache jenkins runs for the last month or so, 
and I'm not seeing any failures related to {{native_transport_ssl_test}}. Also 
running this dtest heavily in a loop on my laptop doesn't yield any problems 
either.

Closing for now, but if errors start happening again, I'm happy to jump in and 
investigate.

> dtest failure: 
> native_transport_ssl_test.NativeTransportSSL.connect_to_ssl_test 
> 
>
> Key: CASSANDRA-13800
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13800
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Jason Brown
>  Labels: dtest
>
> http://cassci.datastax.com/job/trunk_dtest/1623/testReport/native_transport_ssl_test/NativeTransportSSL/connect_to_ssl_test
> http://cassci.datastax.com/job/trunk_dtest/1619/testReport/native_transport_ssl_test/NativeTransportSSL/connect_to_ssl_test
> http://cassci.datastax.com/job/trunk_dtest/1612/testReport/native_transport_ssl_test/NativeTransportSSL/connect_to_ssl_test



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Resolved] (CASSANDRA-10792) Make warning level for count of partitions in unlogged BatchStatement configurable.

[Kurt Greaves (JIRA)]

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

Kurt Greaves resolved CASSANDRA-10792.
--
Resolution: Duplicate

> Make warning level for count of partitions in unlogged BatchStatement 
> configurable.
> ---
>
> Key: CASSANDRA-10792
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10792
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration, CQL
> Environment: CentOS,  JDK 1.7, cluster of servers with 32 CPU each.
>Reporter: Pawel Matras
>Priority: Minor
> Fix For: 4.x
>
>
> Currently mutations for only one partition are allowed in BatchStatement. 
> This amount is hard coded and not configurable as e.g. batch size.
> General suggestion looks to be to consider multi partition unlogged batch 
> statements as distributed anti pattern. As cure async inserts are proposed. 
> Proposal might be OK if one consider only cassandra side of the system.
> If a complete system have to share the same hardware things does not look so 
> obvious any more. When cassandra shares the same hardware with other also 
> clustered components lots of small async inserts become another well known 
> distributed anti pattern. 
> In our case changing from unlogged batches to async inserts destabilize the 
> system as async inserts require amounts of interrupts per second and context 
> switches per second beyond what hardware can handle. With replica aware 
> unlogged batches these parameters are at 40% of hardware limits and the 
> system as a whole runs stable without visible hotspots (cassandra metrics 
> looks almost the same on all nodes).
> Unfortunately latest versions (we switched from 2.0.6 to 2.2.1) of cassandra 
> log lots of warnings of type "Unlogged batch covering NN partitions detected 
> against table XXX...". I found two workarounds to avoid this warning. The one 
> is to use logged batches. But they generate 20% more interrupts and context 
> switches and 400% more network load. The other way is more a hack and uses 
> filtering features of logging framework and suppresses the warning just 
> before it get logged.
> So my suggestion is to allow users of cassandra to decide by configuration if 
> they consider unlogged batches antipattern or not. This is partially done 
> with the size of the batch, where size is configurable and not hardcoded to 5 
> kB.
> It would be fine to stay consistent on this and let the user configure 
> mutations for how many partitions to allow.
> Of course there are several other solutions possible here, probably more 
> costly. E.g warning could be produced only if batch is not token/replica 
> aware.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-10792) Make warning level for count of partitions in unlogged BatchStatement configurable.

[Kurt Greaves (JIRA)]

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

Kurt Greaves commented on CASSANDRA-10792:
--

This was solved in CASSANDRA-11529. Marking as duplicate but speak up if I'm 
missing something.

> Make warning level for count of partitions in unlogged BatchStatement 
> configurable.
> ---
>
> Key: CASSANDRA-10792
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10792
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration, CQL
> Environment: CentOS,  JDK 1.7, cluster of servers with 32 CPU each.
>Reporter: Pawel Matras
>Priority: Minor
> Fix For: 4.x
>
>
> Currently mutations for only one partition are allowed in BatchStatement. 
> This amount is hard coded and not configurable as e.g. batch size.
> General suggestion looks to be to consider multi partition unlogged batch 
> statements as distributed anti pattern. As cure async inserts are proposed. 
> Proposal might be OK if one consider only cassandra side of the system.
> If a complete system have to share the same hardware things does not look so 
> obvious any more. When cassandra shares the same hardware with other also 
> clustered components lots of small async inserts become another well known 
> distributed anti pattern. 
> In our case changing from unlogged batches to async inserts destabilize the 
> system as async inserts require amounts of interrupts per second and context 
> switches per second beyond what hardware can handle. With replica aware 
> unlogged batches these parameters are at 40% of hardware limits and the 
> system as a whole runs stable without visible hotspots (cassandra metrics 
> looks almost the same on all nodes).
> Unfortunately latest versions (we switched from 2.0.6 to 2.2.1) of cassandra 
> log lots of warnings of type "Unlogged batch covering NN partitions detected 
> against table XXX...". I found two workarounds to avoid this warning. The one 
> is to use logged batches. But they generate 20% more interrupts and context 
> switches and 400% more network load. The other way is more a hack and uses 
> filtering features of logging framework and suppresses the warning just 
> before it get logged.
> So my suggestion is to allow users of cassandra to decide by configuration if 
> they consider unlogged batches antipattern or not. This is partially done 
> with the size of the batch, where size is configurable and not hardcoded to 5 
> kB.
> It would be fine to stay consistent on this and let the user configure 
> mutations for how many partitions to allow.
> Of course there are several other solutions possible here, probably more 
> costly. E.g warning could be produced only if batch is not token/replica 
> aware.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13000) slow query log analysis tool

[Murukesh Mohanan (JIRA)]

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

Murukesh Mohanan updated CASSANDRA-13000:
-
Attachment: 0001-Adds-a-cqldumpslow-tool-which-analyses-the-debug-log.patch

Updated the patch to remove some JSON parsing code  - I'd originally included 
that to work in tandem with my initial misguided patch for CASSANDRA-13001. It 
doesn't make any sense to keep it there. (Also fixed from some code indentation 
complaints from flake8.)

> slow query log analysis tool
> 
>
> Key: CASSANDRA-13000
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13000
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Observability
>Reporter: Jon Haddad
>Assignee: Murukesh Mohanan
> Fix For: 4.0
>
> Attachments: 
> 0001-Adds-a-cqldumpslow-tool-which-analyses-the-debug-log.patch, 
> 0001-Adds-a-cqldumpslow-tool-which-analyses-the-debug-log.patch, 
> csqldumpslow.py
>
>
> As a follow up to CASSANDRA-12403, it would be very helpful to have a tool to 
> process the slow queries that are logged.  In the MySQL world, there's a tool 
> called mysqldumpslow, which processes a slow query log, abstracts the 
> parameters to prepared statements, and shows the queries which are causing 
> problems based on frequency.  The {{mysqldumpslow}} utillity shows an 
> aggregated count & time statistics spent on slow queries.  For instance:
> {code}shell> mysqldumpslow
> Reading mysql slow query log from 
> /usr/local/mysql/data/mysqld51-apple-slow.log
> Count: 1  Time=4.32s (4s)  Lock=0.00s (0s)  Rows=0.0 (0), root[root]@localhost
>  insert into t2 select * from t1
> Count: 3  Time=2.53s (7s)  Lock=0.00s (0s)  Rows=0.0 (0), root[root]@localhost
>  insert into t2 select * from t1 limit N
> Count: 3  Time=2.13s (6s)  Lock=0.00s (0s)  Rows=0.0 (0), root[root]@localhost
>  insert into t1 select * from t1{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-8387) Schema inconsistency (cached vs schema_columnfamilies)

[Alexis Wilke (JIRA)]

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

Alexis Wilke commented on CASSANDRA-8387:
-

Jay,

One thing I don't do is create dynamic tables. It looks like that's what you're 
trying to do. Instead, create one table at installation time and then reuse it 
over and over. You can add the name you have, like tt81, in the key and that 
will represent your "sub-table".

That being said, if you are trying to use temporary tables, let just tell me 
that I tried that and it just doesn't work at all. All my journaling is now 
100% outside of Cassandra. I use MySQL instead. It's not too important in my 
case to have a down time because I save the journal info in a file on my front 
ends and whenever I can I send that info to the MySQL cluster. So if MySQL is 
down my files grow but I don't lose any data. Once MySQL is back, the data 
flows again and the backend can handle the journal.

> Schema inconsistency (cached vs schema_columnfamilies)
> --
>
> Key: CASSANDRA-8387
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8387
> Project: Cassandra
>  Issue Type: Bug
> Environment: C* 2.1.1 3-node cluster
>Reporter: Marcus Olsson
>
> While running some tests on a 3-node cluster running C* 2.1.1 we encountered 
> a problem creating the same table schema twice(on different nodes). One thing 
> to note is that one of the nodes clock was ~4 seconds behind the others, but 
> I don't think that's the problem since the exception was reproduced here 
> aswell: http://www.mail-archive.com/user@cassandra.apache.org/msg39560.html.
> While running the same create table statement more than once(on different 
> clients) the logs outputted this on one of the nodes:
> {noformat}
> (node x.x.x.1):
> 2014-11-25T16:11:44.651+0100  INFO [SharedPool-Worker-2] 
> MigrationManager.java:248 Create new ColumnFamily: 
> org.apache.cassandra.config.CFMetaData@45c290de[cfId=5e334b40-74b5-11e4-b1b6-017ad0689f5d,ksName=test,cfName=test,cfType=Standard,comparator=org.apache.cassandra.db.marshal.UTF8Type,comment=,readRepairChance=0.0,dcLocalReadRepairChance=0.1,gcGraceSeconds=864000,defaultValidator=org.apache.cassandra.db.marshal.BytesType,keyValidator=org.apache.cassandra.db.marshal.UTF8Type,minCompactionThreshold=4,maxCompactionThreshold=32,columnMetadata=[ColumnDefinition{name=id,
>  type=org.apache.cassandra.db.marshal.UTF8Type, kind=CLUSTERING_COLUMN, 
> componentIndex=null, indexName=null, indexType=null}, 
> ColumnDefinition{name=key, type=org.apache.cassandra.db.marshal.UTF8Type, 
> kind=PARTITION_KEY, componentIndex=null, indexName=null, indexType=null}, 
> ColumnDefinition{name=value, type=org.apache.cassandra.db.marshal.BytesType, 
> kind=COMPACT_VALUE, componentIndex=null, indexName=null, 
> indexType=null}],compactionStrategyClass=class 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy,compactionStrategyOptions={},compressionParameters={sstable_compression=org.apache.cassandra.io.compress.LZ4Compressor},bloomFilterFpChance=0.01,memtableFlushPeriod=0,caching={"keys":"ALL",
>  
> "rows_per_partition":"NONE"},defaultTimeToLive=0,minIndexInterval=128,maxIndexInterval=2048,speculativeRetry=99.0PERCENTILE,droppedColumns={},triggers=[],isDense=true]
> ...
> 2014-11-25T16:11:44.667+0100  INFO [MigrationStage:1] DefsTables.java:373 
> Loading 
> org.apache.cassandra.config.CFMetaData@40a1ee90[cfId=5bc7c980-74b5-11e4-9131-d9b94a3d8927,ksName=test,cfName=test,cfType=Standard,comparator=org.apache.cassandra.db.marshal.UTF8Type,comment=,readRepairChance=0.0,dcLocalReadRepairChance=0.1,gcGraceSeconds=864000,defaultValidator=org.apache.cassandra.db.marshal.BytesType,keyValidator=org.apache.cassandra.db.marshal.UTF8Type,minCompactionThreshold=4,maxCompactionThreshold=32,columnMetadata=[ColumnDefinition{name=id,
>  type=org.apache.cassandra.db.marshal.UTF8Type, kind=CLUSTERING_COLUMN, 
> componentIndex=null, indexName=null, indexType=null}, 
> ColumnDefinition{name=key, type=org.apache.cassandra.db.marshal.UTF8Type, 
> kind=PARTITION_KEY, componentIndex=null, indexName=null, indexType=null}, 
> ColumnDefinition{name=value, type=org.apache.cassandra.db.marshal.BytesType, 
> kind=COMPACT_VALUE, componentIndex=null, indexName=null, 
> indexType=null}],compactionStrategyClass=class 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy,compactionStrategyOptions={},compressionParameters={sstable_compression=org.apache.cassandra.io.compress.LZ4Compressor},bloomFilterFpChance=0.01,memtableFlushPeriod=0,caching={"keys":"ALL",
>  
> "rows_per_partition":"NONE"},defaultTimeToLive=0,minIndexInterval=128,maxIndexInterval=2048,speculativeRetry=99.0PERCENTILE,droppedColumns={},triggers=[],isDense=true]
> ...
> java.lang.RuntimeException: 
> 

[jira] [Commented] (CASSANDRA-13002) per table slow query times

[Murukesh Mohanan (JIRA)]

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

Murukesh Mohanan commented on CASSANDRA-13002:
--

Just checking to avoid confusion: do the updated patches still cause Cassandra 
to crash when starting with data from a 3.0 instance?

> per table slow query times
> --
>
> Key: CASSANDRA-13002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13002
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Observability
>Reporter: Jon Haddad
>Assignee: Murukesh Mohanan
> Fix For: 4.x
>
> Attachments: 
> 0001-Add-per-table-slow_query_log_timeout_in_ms-property.patch, 
> 0001-Add-per-table-slow_query_log_timeout_in_ms-property.patch, 
> 0001-Add-per-table-slow_query_log_timeout_in_ms-property.patch
>
>
> CASSANDRA-12403 made it possible to log slow queries, but the time specified 
> is a global one.  This isn't useful if we know different tables have 
> different access patterns, as we'll end up with a lot of noise.  We should be 
> able to override the slow query time at a per table level.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-8387) Schema inconsistency (cached vs schema_columnfamilies)

[Jay Zhuang (JIRA)]

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

Jay Zhuang edited comment on CASSANDRA-8387 at 10/5/17 12:06 AM:
-

Is there any mitigation other than rolling restart the cluster? We saw the 
problem in multiple clusters (version 3.0.14), it's causing other table 
creation returns failure, for example, when create table {{tt81}}, it returns 
{{tt4}} has problem:
{noformat}
./bin/cqlsh 127.0.0.1 -e "create table zjay_test.tt81(tt int PRIMARY KEY, name 
text, id text)"
:1:ServerError: java.lang.RuntimeException: 
java.util.concurrent.ExecutionException: 
org.apache.cassandra.exceptions.ConfigurationException: Column family ID 
mismatch for keyspace zjay_test table tt4 (found 
8f64bab0-a89b-11e7-bca7-8d4000ea9db6; expected 
8f5ccb70-a89b-11e7-b03f-237cabe3739e)
{noformat}
The table {{tt81}} is successfully created but the schema id is never changed, 
I guess it's because the migration task failed:
{noformat}
DEBUG [MigrationStage:1] 2017-10-04 11:44:43,185 Schema.java:465 - Adding 
org.apache.cassandra.config.CFMetaData@540ff3c8[cfId=1605ec90-a934-11e7-b03f-237cabe3739e,ksName=zjay_test,cfName=tt81,flags=[COMPOUND],params=TableParams{comment=,
 read_repair_chance=0.0, dclocal_read_repair_
chance=0.1, bloom_filter_fp_chance=0.01, crc_check_chance=1.0, 
gc_grace_seconds=864000, default_time_to_live=0, memtable_flush_period_in_ms=0, 
min_index_interval=128, max_index_interval=2048, 
speculative_retry=99PERCENTILE, caching={'keys' : 'ALL', 'rows_per_partition' : 
'NONE'}, co
mpaction=CompactionParams{class=org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy,
 options={max_threshold=32, min_threshold=4}}, 
compression=org.apache.cassandra.schema.CompressionParams@78dfc45f, 
extensions={}, cdc=false},comparator=comparator(),partitionColumns=[[] |
 [id name]],partitionKeyColumns=[ColumnDefinition{name=tt, 
type=org.apache.cassandra.db.marshal.Int32Type, kind=PARTITION_KEY, 
position=0}],clusteringColumns=[],keyValidator=org.apache.cassandra.db.marshal.Int32Type,columnMetadata=[ColumnDefinition{name=tt,
 type=org.apache.cassandra
.db.marshal.Int32Type, kind=PARTITION_KEY, position=0}, 
ColumnDefinition{name=id, type=org.apache.cassandra.db.marshal.UTF8Type, 
kind=REGULAR, position=-1}, ColumnDefinition{name=name, 
type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR, 
position=-1}],droppedColumns={},trigg
ers=[],indexes=[]] to cfIdMap
DEBUG [MigrationStage:1] 2017-10-04 11:44:43,186 CFMetaData.java:745 - applying 
org.apache.cassandra.config.CFMetaData@6e7e6efb[cfId=8f64bab0-a89b-11e7-bca7-8d4000ea9db6,ksName=zjay_test,cfName=tt4,flags=[COMPOUND],params=TableParams{comment=,
 read_repair_chance=0.0, dclocal_read_re
pair_chance=0.1, bloom_filter_fp_chance=0.01, crc_check_chance=1.0, 
gc_grace_seconds=864000, default_time_to_live=0, memtable_flush_period_in_ms=0, 
min_index_interval=128, max_index_interval=2048, 
speculative_retry=99PERCENTILE, caching={'keys' : 'ALL', 'rows_per_partition' : 
'NONE'
}, 
compaction=CompactionParams{class=org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy,
 options={max_threshold=32, min_threshold=4}}, 
compression=org.apache.cassandra.schema.CompressionParams@78dfc45f, 
extensions={}, cdc=false},comparator=comparator(),partitionColumns=
[[] | [id name]],partitionKeyColumns=[ColumnDefinition{name=tt, 
type=org.apache.cassandra.db.marshal.Int32Type, kind=PARTITION_KEY, 
position=0}],clusteringColumns=[],keyValidator=org.apache.cassandra.db.marshal.Int32Type,columnMetadata=[ColumnDefinition{name=tt,
 type=org.apache.cass
andra.db.marshal.Int32Type, kind=PARTITION_KEY, position=0}, 
ColumnDefinition{name=id, type=org.apache.cassandra.db.marshal.UTF8Type, 
kind=REGULAR, position=-1}, ColumnDefinition{name=name, 
type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR, 
position=-1}],droppedColumns={},
triggers=[],indexes=[]] to 
org.apache.cassandra.config.CFMetaData@69e66630[cfId=8f5ccb70-a89b-11e7-b03f-237cabe3739e,ksName=zjay_test,cfName=tt4,flags=[COMPOUND],params=TableParams{comment=,
 read_repair_chance=0.0, dclocal_read_repair_chance=0.1, 
bloom_filter_fp_chance=0.01, crc_che
ck_chance=1.0, gc_grace_seconds=864000, default_time_to_live=0, 
memtable_flush_period_in_ms=0, min_index_interval=128, max_index_interval=2048, 
speculative_retry=99PERCENTILE, caching={'keys' : 'ALL', 'rows_per_partition' : 
'NONE'}, compaction=CompactionParams{class=org.apache.cassa
ndra.db.compaction.SizeTieredCompactionStrategy, options={max_threshold=32, 
min_threshold=4}}, 
compression=org.apache.cassandra.schema.CompressionParams@78dfc45f, 
extensions={}, cdc=false},comparator=comparator(),partitionColumns=[[] | [id 
name]],partitionKeyColumns=[ColumnDefinitio
n{name=tt, type=org.apache.cassandra.db.marshal.Int32Type, kind=PARTITION_KEY, 

[jira] [Comment Edited] (CASSANDRA-8387) Schema inconsistency (cached vs schema_columnfamilies)

[Jay Zhuang (JIRA)]

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

Jay Zhuang edited comment on CASSANDRA-8387 at 10/4/17 11:59 PM:
-

Is there any mitigation other than rolling restart the cluster? We saw the 
problem in multiple clusters (version 3.0.14), it's causing other table 
creation returns failure, for example, when create table {{tt81}}, it returns 
{{tt4}} has problem:
{noformat}
./bin/cqlsh 127.0.0.1 -e "create table zjay_test.tt81(tt int PRIMARY KEY, name 
text, id text)"
:1:ServerError: java.lang.RuntimeException: 
java.util.concurrent.ExecutionException: 
org.apache.cassandra.exceptions.ConfigurationException: Column family ID 
mismatch for keyspace zjay_test table tt4 (found 
8f64bab0-a89b-11e7-bca7-8d4000ea9db6; expected 
8f5ccb70-a89b-11e7-b03f-237cabe3739e)
{noformat}
The table {{tt81}} is successfully created but the schema id is never changed, 
I guess it's because the migration task failed:
{noformat}
DEBUG [MigrationStage:1] 2017-10-04 11:44:43,185 Schema.java:465 - Adding 
org.apache.cassandra.config.CFMetaData@540ff3c8[cfId=1605ec90-a934-11e7-b03f-237cabe3739e,ksName=zjay_test,cfName=tt81,flags=[COMPOUND],params=TableParams{comment=,
 read_repair_chance=0.0, dclocal_read_repair_
chance=0.1, bloom_filter_fp_chance=0.01, crc_check_chance=1.0, 
gc_grace_seconds=864000, default_time_to_live=0, memtable_flush_period_in_ms=0, 
min_index_interval=128, max_index_interval=2048, 
speculative_retry=99PERCENTILE, caching={'keys' : 'ALL', 'rows_per_partition' : 
'NONE'}, co
mpaction=CompactionParams{class=org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy,
 options={max_threshold=32, min_threshold=4}}, 
compression=org.apache.cassandra.schema.CompressionParams@78dfc45f, 
extensions={}, cdc=false},comparator=comparator(),partitionColumns=[[] |
 [id name]],partitionKeyColumns=[ColumnDefinition{name=tt, 
type=org.apache.cassandra.db.marshal.Int32Type, kind=PARTITION_KEY, 
position=0}],clusteringColumns=[],keyValidator=org.apache.cassandra.db.marshal.Int32Type,columnMetadata=[ColumnDefinition{name=tt,
 type=org.apache.cassandra
.db.marshal.Int32Type, kind=PARTITION_KEY, position=0}, 
ColumnDefinition{name=id, type=org.apache.cassandra.db.marshal.UTF8Type, 
kind=REGULAR, position=-1}, ColumnDefinition{name=name, 
type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR, 
position=-1}],droppedColumns={},trigg
ers=[],indexes=[]] to cfIdMap
DEBUG [MigrationStage:1] 2017-10-04 11:44:43,186 CFMetaData.java:745 - applying 
org.apache.cassandra.config.CFMetaData@6e7e6efb[cfId=8f64bab0-a89b-11e7-bca7-8d4000ea9db6,ksName=zjay_test,cfName=tt4,flags=[COMPOUND],params=TableParams{comment=,
 read_repair_chance=0.0, dclocal_read_re
pair_chance=0.1, bloom_filter_fp_chance=0.01, crc_check_chance=1.0, 
gc_grace_seconds=864000, default_time_to_live=0, memtable_flush_period_in_ms=0, 
min_index_interval=128, max_index_interval=2048, 
speculative_retry=99PERCENTILE, caching={'keys' : 'ALL', 'rows_per_partition' : 
'NONE'
}, 
compaction=CompactionParams{class=org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy,
 options={max_threshold=32, min_threshold=4}}, 
compression=org.apache.cassandra.schema.CompressionParams@78dfc45f, 
extensions={}, cdc=false},comparator=comparator(),partitionColumns=
[[] | [id name]],partitionKeyColumns=[ColumnDefinition{name=tt, 
type=org.apache.cassandra.db.marshal.Int32Type, kind=PARTITION_KEY, 
position=0}],clusteringColumns=[],keyValidator=org.apache.cassandra.db.marshal.Int32Type,columnMetadata=[ColumnDefinition{name=tt,
 type=org.apache.cass
andra.db.marshal.Int32Type, kind=PARTITION_KEY, position=0}, 
ColumnDefinition{name=id, type=org.apache.cassandra.db.marshal.UTF8Type, 
kind=REGULAR, position=-1}, ColumnDefinition{name=name, 
type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR, 
position=-1}],droppedColumns={},
triggers=[],indexes=[]] to 
org.apache.cassandra.config.CFMetaData@69e66630[cfId=8f5ccb70-a89b-11e7-b03f-237cabe3739e,ksName=zjay_test,cfName=tt4,flags=[COMPOUND],params=TableParams{comment=,
 read_repair_chance=0.0, dclocal_read_repair_chance=0.1, 
bloom_filter_fp_chance=0.01, crc_che
ck_chance=1.0, gc_grace_seconds=864000, default_time_to_live=0, 
memtable_flush_period_in_ms=0, min_index_interval=128, max_index_interval=2048, 
speculative_retry=99PERCENTILE, caching={'keys' : 'ALL', 'rows_per_partition' : 
'NONE'}, compaction=CompactionParams{class=org.apache.cassa
ndra.db.compaction.SizeTieredCompactionStrategy, options={max_threshold=32, 
min_threshold=4}}, 
compression=org.apache.cassandra.schema.CompressionParams@78dfc45f, 
extensions={}, cdc=false},comparator=comparator(),partitionColumns=[[] | [id 
name]],partitionKeyColumns=[ColumnDefinitio
n{name=tt, type=org.apache.cassandra.db.marshal.Int32Type, kind=PARTITION_KEY, 

[jira] [Commented] (CASSANDRA-8387) Schema inconsistency (cached vs schema_columnfamilies)

[Jay Zhuang (JIRA)]

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

Jay Zhuang commented on CASSANDRA-8387:
---

Is there any mitigation other than rolling restart the cluster? We saw the 
problem in multiple clusters (version 3.0.14), it's causing other table 
creation returns:
{noformat}
./bin/cqlsh 127.0.0.1 -e "create table zjay_test.tt81(tt int PRIMARY KEY, name 
text, id text)"
:1:ServerError: java.lang.RuntimeException: 
java.util.concurrent.ExecutionException: 
org.apache.cassandra.exceptions.ConfigurationException: Column family ID 
mismatch for keyspace zjay_test table tt4 (found 
8f64bab0-a89b-11e7-bca7-8d4000ea9db6; expected 
8f5ccb70-a89b-11e7-b03f-237cabe3739e)
{noformat}
The table is successfully created but the schema id is never changed, I guess 
it's because the migration task failed:
{noformat}
DEBUG [MigrationStage:1] 2017-10-04 11:44:43,185 Schema.java:465 - Adding 
org.apache.cassandra.config.CFMetaData@540ff3c8[cfId=1605ec90-a934-11e7-b03f-237cabe3739e,ksName=zjay_test,cfName=tt81,flags=[COMPOUND],params=TableParams{comment=,
 read_repair_chance=0.0, dclocal_read_repair_
chance=0.1, bloom_filter_fp_chance=0.01, crc_check_chance=1.0, 
gc_grace_seconds=864000, default_time_to_live=0, memtable_flush_period_in_ms=0, 
min_index_interval=128, max_index_interval=2048, 
speculative_retry=99PERCENTILE, caching={'keys' : 'ALL', 'rows_per_partition' : 
'NONE'}, co
mpaction=CompactionParams{class=org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy,
 options={max_threshold=32, min_threshold=4}}, 
compression=org.apache.cassandra.schema.CompressionParams@78dfc45f, 
extensions={}, cdc=false},comparator=comparator(),partitionColumns=[[] |
 [id name]],partitionKeyColumns=[ColumnDefinition{name=tt, 
type=org.apache.cassandra.db.marshal.Int32Type, kind=PARTITION_KEY, 
position=0}],clusteringColumns=[],keyValidator=org.apache.cassandra.db.marshal.Int32Type,columnMetadata=[ColumnDefinition{name=tt,
 type=org.apache.cassandra
.db.marshal.Int32Type, kind=PARTITION_KEY, position=0}, 
ColumnDefinition{name=id, type=org.apache.cassandra.db.marshal.UTF8Type, 
kind=REGULAR, position=-1}, ColumnDefinition{name=name, 
type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR, 
position=-1}],droppedColumns={},trigg
ers=[],indexes=[]] to cfIdMap
DEBUG [MigrationStage:1] 2017-10-04 11:44:43,186 CFMetaData.java:745 - applying 
org.apache.cassandra.config.CFMetaData@6e7e6efb[cfId=8f64bab0-a89b-11e7-bca7-8d4000ea9db6,ksName=zjay_test,cfName=tt4,flags=[COMPOUND],params=TableParams{comment=,
 read_repair_chance=0.0, dclocal_read_re
pair_chance=0.1, bloom_filter_fp_chance=0.01, crc_check_chance=1.0, 
gc_grace_seconds=864000, default_time_to_live=0, memtable_flush_period_in_ms=0, 
min_index_interval=128, max_index_interval=2048, 
speculative_retry=99PERCENTILE, caching={'keys' : 'ALL', 'rows_per_partition' : 
'NONE'
}, 
compaction=CompactionParams{class=org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy,
 options={max_threshold=32, min_threshold=4}}, 
compression=org.apache.cassandra.schema.CompressionParams@78dfc45f, 
extensions={}, cdc=false},comparator=comparator(),partitionColumns=
[[] | [id name]],partitionKeyColumns=[ColumnDefinition{name=tt, 
type=org.apache.cassandra.db.marshal.Int32Type, kind=PARTITION_KEY, 
position=0}],clusteringColumns=[],keyValidator=org.apache.cassandra.db.marshal.Int32Type,columnMetadata=[ColumnDefinition{name=tt,
 type=org.apache.cass
andra.db.marshal.Int32Type, kind=PARTITION_KEY, position=0}, 
ColumnDefinition{name=id, type=org.apache.cassandra.db.marshal.UTF8Type, 
kind=REGULAR, position=-1}, ColumnDefinition{name=name, 
type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR, 
position=-1}],droppedColumns={},
triggers=[],indexes=[]] to 
org.apache.cassandra.config.CFMetaData@69e66630[cfId=8f5ccb70-a89b-11e7-b03f-237cabe3739e,ksName=zjay_test,cfName=tt4,flags=[COMPOUND],params=TableParams{comment=,
 read_repair_chance=0.0, dclocal_read_repair_chance=0.1, 
bloom_filter_fp_chance=0.01, crc_che
ck_chance=1.0, gc_grace_seconds=864000, default_time_to_live=0, 
memtable_flush_period_in_ms=0, min_index_interval=128, max_index_interval=2048, 
speculative_retry=99PERCENTILE, caching={'keys' : 'ALL', 'rows_per_partition' : 
'NONE'}, compaction=CompactionParams{class=org.apache.cassa
ndra.db.compaction.SizeTieredCompactionStrategy, options={max_threshold=32, 
min_threshold=4}}, 
compression=org.apache.cassandra.schema.CompressionParams@78dfc45f, 
extensions={}, cdc=false},comparator=comparator(),partitionColumns=[[] | [id 
name]],partitionKeyColumns=[ColumnDefinitio
n{name=tt, type=org.apache.cassandra.db.marshal.Int32Type, kind=PARTITION_KEY, 
position=0}],clusteringColumns=[],keyValidator=org.apache.cassandra.db.marshal.Int32Type,columnMetadata=[ColumnDefinition{name=tt,
 type=org.apache.cassandra.db.marshal.Int32Type, 

[jira] [Commented] (CASSANDRA-13934) xxHash as a new partitioner

[Salih Gedik (JIRA)]

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

Salih Gedik commented on CASSANDRA-13934:
-

[~jjirsa] I am aware that this is not a game changer nor the solution Cassandra 
has been waiting for. I actually want to work on this myself to learn about 
codebase and become committing later on.

> xxHash as a new partitioner
> ---
>
> Key: CASSANDRA-13934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13934
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Salih Gedik
>Priority: Minor
>
> Hi,
> According to [benchmarks|https://cyan4973.github.io/xxHash/] xxHash seems to 
> be more performant when used as a consistent hasher. I would like to 
> implement xxHash as a partitioner for Cassandra. It should not be strictly 
> the default partitioner but as an optional. I am happy to have your ideas 
> related to this.
> Thanks



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13934) xxHash as a new partitioner

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13934:


I suspect you'll need to demonstrate a clear win in terms of real performance 
in order to convince a committer to add this. Part of this is that third party 
drivers also need to implement the hash for load balancing policies, so adding 
a new partitioner in 4.0 would necessitate a lot of external changes over code 
that we don't control. That's not to say it can't be done, but you'll want to 
look at some of the testing in CASSANDRA-3772 (for example) to see what was 
done previously.



> xxHash as a new partitioner
> ---
>
> Key: CASSANDRA-13934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13934
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Salih Gedik
>Priority: Minor
>
> Hi,
> According to [benchmarks|https://cyan4973.github.io/xxHash/] xxHash seems to 
> be more performant when used as a consistent hasher. I would like to 
> implement xxHash as a partitioner for Cassandra. It should not be strictly 
> the default partitioner but as an optional. I am happy to have your ideas 
> related to this.
> Thanks



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Issue Comment Deleted] (CASSANDRA-13937) Cassandra node's startup time increased after increase count of big tables

[Andrey Lataev (JIRA)]

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

Andrey Lataev updated CASSANDRA-13937:
--
Comment: was deleted

(was:  LZ4 compression used:
{code:java}
sys@cqlsh> DESC TABLE p00smevauditbody.messagelogbody20171004;

CREATE TABLE p00smevauditbody.messagelogbody20171004 (
d timestamp,
mid text,
mt text,
rec_msg text,
rec_sid text,
sd_msg text,
PRIMARY KEY (d, mid, mt)
) WITH CLUSTERING ORDER BY (mid ASC, mt ASC)
AND bloom_filter_fp_chance = 0.1
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy', 
'sstable_size_in_mb': '160'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
{code}

)

>  Cassandra node's startup time increased after increase count of big tables
> ---
>
> Key: CASSANDRA-13937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13937
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: RHEL 7.3
> JDK HotSpot 1.8.0_121-b13
> cassandra-3.11 cluster with 43 nodes in 9 datacenters
> 8vCPU, 100 GB RAM
>Reporter: Andrey Lataev
> Attachments: cassandra.zip, debug.zip
>
>
> In startup time Cassandra spends a long time on read some big Columnfamilies.
> For example, in debug.log:
> {code:java}
> grep SSTableReader.java:506 /var/log/cassandra/debug.log
> <...> 
> DEBUG [SSTableBatchOpen:3] 2017-10-04 22:40:05,297 SSTableReader.java:506 - 
> Opening 
> /egov/data/cassandra/datafiles1/p00smevauditbody/messagelogbody20171003-b341cc709c7511e7b1cfed1e90eb03dc/mc-45242-big
>  (19.280MiB)
> DEBUG [SSTableBatchOpen:5] 2017-10-04 22:42:14,188 SSTableReader.java:506 - 
> Opening 
> /egov/data/cassandra/datafiles1/p00smevauditbody/messagelogbody20171004-f82225509d3e11e7b1cfed1e90eb03dc/mc-49002-big
>  (10.607MiB)
> <...>
> DEBUG [SSTableBatchOpen:4] 2017-10-04 22:42:19,792 SSTableReader.java:506 - 
> Opening 
> /egov/data/cassandra/datafiles1/p00smevauditbody/messagelogbody20171004-f82225509d3e11e7b1cfed1e90eb03dc/mc-47907-big
>  (128.172MiB)
> DEBUG [SSTableBatchOpen:1] 2017-10-04 22:44:23,560 SSTableReader.java:506 - 
> Opening 
> /egov/data/cassandra/datafiles1/pk4smevauditbody/messagelogbody20170324-f918bfa0107b11e7adfc2d0b45a372ac/mc-4-big
>  (96.310MiB)
> <..>
> {code}
> SSTableReader.java:506 spent ~ 2 min per every big table in p00smevauditbody 
> keyspace.
> I was planned too keep similar tables for the full month...
> So it seems like Cassandra will need more then 1h on startup...
> Does it available to speed up SSTableBatchOpen ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13937) Cassandra node's startup time increased after increase count of big tables

[Andrey Lataev (JIRA)]

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

Andrey Lataev commented on CASSANDRA-13937:
---

 LZ4 compression used:
{code:java}
sys@cqlsh> DESC TABLE p00smevauditbody.messagelogbody20171004;

CREATE TABLE p00smevauditbody.messagelogbody20171004 (
d timestamp,
mid text,
mt text,
rec_msg text,
rec_sid text,
sd_msg text,
PRIMARY KEY (d, mid, mt)
) WITH CLUSTERING ORDER BY (mid ASC, mt ASC)
AND bloom_filter_fp_chance = 0.1
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy', 
'sstable_size_in_mb': '160'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
{code}



>  Cassandra node's startup time increased after increase count of big tables
> ---
>
> Key: CASSANDRA-13937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13937
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: RHEL 7.3
> JDK HotSpot 1.8.0_121-b13
> cassandra-3.11 cluster with 43 nodes in 9 datacenters
> 8vCPU, 100 GB RAM
>Reporter: Andrey Lataev
> Attachments: cassandra.zip, debug.zip
>
>
> In startup time Cassandra spends a long time on read some big Columnfamilies.
> For example, in debug.log:
> {code:java}
> grep SSTableReader.java:506 /var/log/cassandra/debug.log
> <...> 
> DEBUG [SSTableBatchOpen:3] 2017-10-04 22:40:05,297 SSTableReader.java:506 - 
> Opening 
> /egov/data/cassandra/datafiles1/p00smevauditbody/messagelogbody20171003-b341cc709c7511e7b1cfed1e90eb03dc/mc-45242-big
>  (19.280MiB)
> DEBUG [SSTableBatchOpen:5] 2017-10-04 22:42:14,188 SSTableReader.java:506 - 
> Opening 
> /egov/data/cassandra/datafiles1/p00smevauditbody/messagelogbody20171004-f82225509d3e11e7b1cfed1e90eb03dc/mc-49002-big
>  (10.607MiB)
> <...>
> DEBUG [SSTableBatchOpen:4] 2017-10-04 22:42:19,792 SSTableReader.java:506 - 
> Opening 
> /egov/data/cassandra/datafiles1/p00smevauditbody/messagelogbody20171004-f82225509d3e11e7b1cfed1e90eb03dc/mc-47907-big
>  (128.172MiB)
> DEBUG [SSTableBatchOpen:1] 2017-10-04 22:44:23,560 SSTableReader.java:506 - 
> Opening 
> /egov/data/cassandra/datafiles1/pk4smevauditbody/messagelogbody20170324-f918bfa0107b11e7adfc2d0b45a372ac/mc-4-big
>  (96.310MiB)
> <..>
> {code}
> SSTableReader.java:506 spent ~ 2 min per every big table in p00smevauditbody 
> keyspace.
> I was planned too keep similar tables for the full month...
> So it seems like Cassandra will need more then 1h on startup...
> Does it available to speed up SSTableBatchOpen ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13937) Cassandra node's startup time increased after increase count of big tables

[Andrey Lataev (JIRA)]

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

Andrey Lataev commented on CASSANDRA-13937:
---

 LZ4 compression used:
{code:java}
sys@cqlsh> DESC TABLE p00smevauditbody.messagelogbody20171004;

CREATE TABLE p00smevauditbody.messagelogbody20171004 (
d timestamp,
mid text,
mt text,
rec_msg text,
rec_sid text,
sd_msg text,
PRIMARY KEY (d, mid, mt)
) WITH CLUSTERING ORDER BY (mid ASC, mt ASC)
AND bloom_filter_fp_chance = 0.1
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy', 
'sstable_size_in_mb': '160'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
{code}



>  Cassandra node's startup time increased after increase count of big tables
> ---
>
> Key: CASSANDRA-13937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13937
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: RHEL 7.3
> JDK HotSpot 1.8.0_121-b13
> cassandra-3.11 cluster with 43 nodes in 9 datacenters
> 8vCPU, 100 GB RAM
>Reporter: Andrey Lataev
> Attachments: cassandra.zip, debug.zip
>
>
> In startup time Cassandra spends a long time on read some big Columnfamilies.
> For example, in debug.log:
> {code:java}
> grep SSTableReader.java:506 /var/log/cassandra/debug.log
> <...> 
> DEBUG [SSTableBatchOpen:3] 2017-10-04 22:40:05,297 SSTableReader.java:506 - 
> Opening 
> /egov/data/cassandra/datafiles1/p00smevauditbody/messagelogbody20171003-b341cc709c7511e7b1cfed1e90eb03dc/mc-45242-big
>  (19.280MiB)
> DEBUG [SSTableBatchOpen:5] 2017-10-04 22:42:14,188 SSTableReader.java:506 - 
> Opening 
> /egov/data/cassandra/datafiles1/p00smevauditbody/messagelogbody20171004-f82225509d3e11e7b1cfed1e90eb03dc/mc-49002-big
>  (10.607MiB)
> <...>
> DEBUG [SSTableBatchOpen:4] 2017-10-04 22:42:19,792 SSTableReader.java:506 - 
> Opening 
> /egov/data/cassandra/datafiles1/p00smevauditbody/messagelogbody20171004-f82225509d3e11e7b1cfed1e90eb03dc/mc-47907-big
>  (128.172MiB)
> DEBUG [SSTableBatchOpen:1] 2017-10-04 22:44:23,560 SSTableReader.java:506 - 
> Opening 
> /egov/data/cassandra/datafiles1/pk4smevauditbody/messagelogbody20170324-f918bfa0107b11e7adfc2d0b45a372ac/mc-4-big
>  (96.310MiB)
> <..>
> {code}
> SSTableReader.java:506 spent ~ 2 min per every big table in p00smevauditbody 
> keyspace.
> I was planned too keep similar tables for the full month...
> So it seems like Cassandra will need more then 1h on startup...
> Does it available to speed up SSTableBatchOpen ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-13937) Cassandra node's startup time increased after increase count of big tables

[Andrey Lataev (JIRA)]

Andrey Lataev created CASSANDRA-13937:
-

 Summary:  Cassandra node's startup time increased after increase 
count of big tables
 Key: CASSANDRA-13937
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13937
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: RHEL 7.3
JDK HotSpot 1.8.0_121-b13
cassandra-3.11 cluster with 43 nodes in 9 datacenters
8vCPU, 100 GB RAM
Reporter: Andrey Lataev
 Attachments: cassandra.zip, debug.zip

In startup time Cassandra spends a long time on read some big Columnfamilies.
For example, in debug.log:
{code:java}
grep SSTableReader.java:506 /var/log/cassandra/debug.log
<...> 
DEBUG [SSTableBatchOpen:3] 2017-10-04 22:40:05,297 SSTableReader.java:506 - 
Opening 
/egov/data/cassandra/datafiles1/p00smevauditbody/messagelogbody20171003-b341cc709c7511e7b1cfed1e90eb03dc/mc-45242-big
 (19.280MiB)
DEBUG [SSTableBatchOpen:5] 2017-10-04 22:42:14,188 SSTableReader.java:506 - 
Opening 
/egov/data/cassandra/datafiles1/p00smevauditbody/messagelogbody20171004-f82225509d3e11e7b1cfed1e90eb03dc/mc-49002-big
 (10.607MiB)
<...>
DEBUG [SSTableBatchOpen:4] 2017-10-04 22:42:19,792 SSTableReader.java:506 - 
Opening 
/egov/data/cassandra/datafiles1/p00smevauditbody/messagelogbody20171004-f82225509d3e11e7b1cfed1e90eb03dc/mc-47907-big
 (128.172MiB)
DEBUG [SSTableBatchOpen:1] 2017-10-04 22:44:23,560 SSTableReader.java:506 - 
Opening 
/egov/data/cassandra/datafiles1/pk4smevauditbody/messagelogbody20170324-f918bfa0107b11e7adfc2d0b45a372ac/mc-4-big
 (96.310MiB)
<..>

{code}
SSTableReader.java:506 spent ~ 2 min per every big table in p00smevauditbody 
keyspace.
I was planned too keep similar tables for the full month...
So it seems like Cassandra will need more then 1h on startup...
Does it available to speed up SSTableBatchOpen ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13935) Indexes creation should have IF EXISTS on its String representation

[Javier Canillas (JIRA)]

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

Javier Canillas updated CASSANDRA-13935:

Reproduced In: 3.11.0, 3.0.14  (was: 3.11.0)

> Indexes creation should have IF EXISTS on its String representation
> ---
>
> Key: CASSANDRA-13935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13935
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Secondary Indexes
> Environment: Ubuntu 16.04.2 LTS
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Javier Canillas
>Priority: Trivial
>
> I came across something that bothers me a lot. I'm using snapshots to backup 
> data from my Cassandra cluster in case something really bad happens (like 
> dropping a table or a keyspace).
> Exercising the recovery actions from those backups, I discover that the 
> schema put on the file "schema.cql" as a result of the snapshot has the 
> "CREATE IF NOT EXISTS" for the table, but not for the indexes.
> When restoring from snapshots, and relying on the execution of these schemas 
> to build up the table structure, everything seems fine for tables without 
> secondary indexes, but for the ones that make use of them, the execution of 
> these statements fail miserably.
> Here I paste a generated schema.cql content for a table with indexes:
> CREATE TABLE IF NOT EXISTS keyspace1.table1 (
>   id text PRIMARY KEY,
>   content text,
>   last_update_date date,
>   last_update_date_time timestamp)
>   WITH ID = f1045fc0-2f59-11e7-95ec-295c3c064920
>   AND bloom_filter_fp_chance = 0.01
>   AND dclocal_read_repair_chance = 0.1
>   AND crc_check_chance = 1.0
>   AND default_time_to_live = 864
>   AND gc_grace_seconds = 864000
>   AND min_index_interval = 128
>   AND max_index_interval = 2048
>   AND memtable_flush_period_in_ms = 0
>   AND read_repair_chance = 0.0
>   AND speculative_retry = '99PERCENTILE'
>   AND caching = { 'keys': 'NONE', 'rows_per_partition': 'NONE' }
>   AND compaction = { 'max_threshold': '32', 'min_threshold': '4', 
> 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' }
>   AND compression = { 'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor' }
>   AND cdc = false
>   AND extensions = {  };
> CREATE INDEX table1_last_update_date_idx ON keyspace1.table1 
> (last_update_date);
> I think the last part should be:
> CREATE INDEX IF NOT EXISTS table1_last_update_date_idx ON keyspace1.table1 
> (last_update_date);



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13936) RangeTombstoneTest (compressed) failure - assertTimes expected:<1000> but was:<999>

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13936:
---
Summary: RangeTombstoneTest (compressed) failure - assertTimes 
expected:<1000> but was:<999>  (was: RnageTombstoneTest (compressed) failure - 
assertTimes expected:<1000> but was:<999>)

> RangeTombstoneTest (compressed) failure - assertTimes expected:<1000> but 
> was:<999>
> ---
>
> Key: CASSANDRA-13936
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13936
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeff Jirsa
>  Labels: Testing
> Fix For: 4.x
>
>
> In circleci run 
> [here|https://circleci.com/gh/jeffjirsa/cassandra/367#tests/containers/2] :
> {code}
> [junit] Testsuite: org.apache.cassandra.db.RangeTombstoneTest-compression
> [junit] Testsuite: org.apache.cassandra.db.RangeTombstoneTest-compression 
> Tests run: 14, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.945 sec
> [junit] 
> [junit] Testcase: 
> testTrackTimesRangeTombstoneWithData(org.apache.cassandra.db.RangeTombstoneTest)-compression:
>FAILED
> [junit] expected:<1000> but was:<999>
> [junit] junit.framework.AssertionFailedError: expected:<1000> but 
> was:<999>
> [junit]   at 
> org.apache.cassandra.db.RangeTombstoneTest.assertTimes(RangeTombstoneTest.java:314)
> [junit]   at 
> org.apache.cassandra.db.RangeTombstoneTest.testTrackTimesRangeTombstoneWithData(RangeTombstoneTest.java:308)
> [junit] 
> [junit] 
> [junit] Test org.apache.cassandra.db.RangeTombstoneTest FAILED
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-13936) RnageTombstoneTest (compressed) failure - assertTimes expected:<1000> but was:<999>

[Jeff Jirsa (JIRA)]

Jeff Jirsa created CASSANDRA-13936:
--

 Summary: RnageTombstoneTest (compressed) failure - assertTimes 
expected:<1000> but was:<999>
 Key: CASSANDRA-13936
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13936
 Project: Cassandra
  Issue Type: Bug
Reporter: Jeff Jirsa
 Fix For: 4.x


In circleci run 
[here|https://circleci.com/gh/jeffjirsa/cassandra/367#tests/containers/2] :

{code}
[junit] Testsuite: org.apache.cassandra.db.RangeTombstoneTest-compression
[junit] Testsuite: org.apache.cassandra.db.RangeTombstoneTest-compression 
Tests run: 14, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.945 sec
[junit] 
[junit] Testcase: 
testTrackTimesRangeTombstoneWithData(org.apache.cassandra.db.RangeTombstoneTest)-compression:
 FAILED
[junit] expected:<1000> but was:<999>
[junit] junit.framework.AssertionFailedError: expected:<1000> but was:<999>
[junit] at 
org.apache.cassandra.db.RangeTombstoneTest.assertTimes(RangeTombstoneTest.java:314)
[junit] at 
org.apache.cassandra.db.RangeTombstoneTest.testTrackTimesRangeTombstoneWithData(RangeTombstoneTest.java:308)
[junit] 
[junit] 
[junit] Test org.apache.cassandra.db.RangeTombstoneTest FAILED
{code}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13935) Indexes creation should have IF EXISTS on its String representation

[Javier Canillas (JIRA)]

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

Javier Canillas edited comment on CASSANDRA-13935 at 10/4/17 7:43 PM:
--

This seems to happen with CUSTOM INDEXES too


was (Author: kani):
This seems to happens too with CUSTOM INDEXES

> Indexes creation should have IF EXISTS on its String representation
> ---
>
> Key: CASSANDRA-13935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13935
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Secondary Indexes
> Environment: Ubuntu 16.04.2 LTS
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Javier Canillas
>Priority: Trivial
>
> I came across something that bothers me a lot. I'm using snapshots to backup 
> data from my Cassandra cluster in case something really bad happens (like 
> dropping a table or a keyspace).
> Exercising the recovery actions from those backups, I discover that the 
> schema put on the file "schema.cql" as a result of the snapshot has the 
> "CREATE IF NOT EXISTS" for the table, but not for the indexes.
> When restoring from snapshots, and relying on the execution of these schemas 
> to build up the table structure, everything seems fine for tables without 
> secondary indexes, but for the ones that make use of them, the execution of 
> these statements fail miserably.
> Here I paste a generated schema.cql content for a table with indexes:
> CREATE TABLE IF NOT EXISTS keyspace1.table1 (
>   id text PRIMARY KEY,
>   content text,
>   last_update_date date,
>   last_update_date_time timestamp)
>   WITH ID = f1045fc0-2f59-11e7-95ec-295c3c064920
>   AND bloom_filter_fp_chance = 0.01
>   AND dclocal_read_repair_chance = 0.1
>   AND crc_check_chance = 1.0
>   AND default_time_to_live = 864
>   AND gc_grace_seconds = 864000
>   AND min_index_interval = 128
>   AND max_index_interval = 2048
>   AND memtable_flush_period_in_ms = 0
>   AND read_repair_chance = 0.0
>   AND speculative_retry = '99PERCENTILE'
>   AND caching = { 'keys': 'NONE', 'rows_per_partition': 'NONE' }
>   AND compaction = { 'max_threshold': '32', 'min_threshold': '4', 
> 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' }
>   AND compression = { 'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor' }
>   AND cdc = false
>   AND extensions = {  };
> CREATE INDEX table1_last_update_date_idx ON keyspace1.table1 
> (last_update_date);
> I think the last part should be:
> CREATE INDEX IF NOT EXISTS table1_last_update_date_idx ON keyspace1.table1 
> (last_update_date);



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13935) Indexes creation should have IF EXISTS on its String representation

[Javier Canillas (JIRA)]

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

Javier Canillas commented on CASSANDRA-13935:
-

This seems to happens too with CUSTOM INDEXES

> Indexes creation should have IF EXISTS on its String representation
> ---
>
> Key: CASSANDRA-13935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13935
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Secondary Indexes
> Environment: Ubuntu 16.04.2 LTS
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Javier Canillas
>Priority: Trivial
>
> I came across something that bothers me a lot. I'm using snapshots to backup 
> data from my Cassandra cluster in case something really bad happens (like 
> dropping a table or a keyspace).
> Exercising the recovery actions from those backups, I discover that the 
> schema put on the file "schema.cql" as a result of the snapshot has the 
> "CREATE IF NOT EXISTS" for the table, but not for the indexes.
> When restoring from snapshots, and relying on the execution of these schemas 
> to build up the table structure, everything seems fine for tables without 
> secondary indexes, but for the ones that make use of them, the execution of 
> these statements fail miserably.
> Here I paste a generated schema.cql content for a table with indexes:
> CREATE TABLE IF NOT EXISTS keyspace1.table1 (
>   id text PRIMARY KEY,
>   content text,
>   last_update_date date,
>   last_update_date_time timestamp)
>   WITH ID = f1045fc0-2f59-11e7-95ec-295c3c064920
>   AND bloom_filter_fp_chance = 0.01
>   AND dclocal_read_repair_chance = 0.1
>   AND crc_check_chance = 1.0
>   AND default_time_to_live = 864
>   AND gc_grace_seconds = 864000
>   AND min_index_interval = 128
>   AND max_index_interval = 2048
>   AND memtable_flush_period_in_ms = 0
>   AND read_repair_chance = 0.0
>   AND speculative_retry = '99PERCENTILE'
>   AND caching = { 'keys': 'NONE', 'rows_per_partition': 'NONE' }
>   AND compaction = { 'max_threshold': '32', 'min_threshold': '4', 
> 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' }
>   AND compression = { 'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor' }
>   AND cdc = false
>   AND extensions = {  };
> CREATE INDEX table1_last_update_date_idx ON keyspace1.table1 
> (last_update_date);
> I think the last part should be:
> CREATE INDEX IF NOT EXISTS table1_last_update_date_idx ON keyspace1.table1 
> (last_update_date);



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-13935) Indexes creation should have IF EXISTS on its String representation

[Javier Canillas (JIRA)]

Javier Canillas created CASSANDRA-13935:
---

 Summary: Indexes creation should have IF EXISTS on its String 
representation
 Key: CASSANDRA-13935
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13935
 Project: Cassandra
  Issue Type: Bug
  Components: CQL, Secondary Indexes
 Environment: Ubuntu 16.04.2 LTS
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
Reporter: Javier Canillas
Priority: Trivial


I came across something that bothers me a lot. I'm using snapshots to backup 
data from my Cassandra cluster in case something really bad happens (like 
dropping a table or a keyspace).

Exercising the recovery actions from those backups, I discover that the schema 
put on the file "schema.cql" as a result of the snapshot has the "CREATE IF NOT 
EXISTS" for the table, but not for the indexes.

When restoring from snapshots, and relying on the execution of these schemas to 
build up the table structure, everything seems fine for tables without 
secondary indexes, but for the ones that make use of them, the execution of 
these statements fail miserably.

Here I paste a generated schema.cql content for a table with indexes:

CREATE TABLE IF NOT EXISTS keyspace1.table1 (
id text PRIMARY KEY,
content text,
last_update_date date,
last_update_date_time timestamp)
WITH ID = f1045fc0-2f59-11e7-95ec-295c3c064920
AND bloom_filter_fp_chance = 0.01
AND dclocal_read_repair_chance = 0.1
AND crc_check_chance = 1.0
AND default_time_to_live = 864
AND gc_grace_seconds = 864000
AND min_index_interval = 128
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE'
AND caching = { 'keys': 'NONE', 'rows_per_partition': 'NONE' }
AND compaction = { 'max_threshold': '32', 'min_threshold': '4', 
'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' }
AND compression = { 'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor' }
AND cdc = false
AND extensions = {  };
CREATE INDEX table1_last_update_date_idx ON keyspace1.table1 (last_update_date);

I think the last part should be:

CREATE INDEX IF NOT EXISTS table1_last_update_date_idx ON keyspace1.table1 
(last_update_date);



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13002) per table slow query times

[Jon Haddad (JIRA)]

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

Jon Haddad commented on CASSANDRA-13002:


[~iamaleksey] Mind pointing us in the right direction regarding schema 
ugprades, etc?

> per table slow query times
> --
>
> Key: CASSANDRA-13002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13002
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Observability
>Reporter: Jon Haddad
>Assignee: Murukesh Mohanan
> Fix For: 4.x
>
> Attachments: 
> 0001-Add-per-table-slow_query_log_timeout_in_ms-property.patch, 
> 0001-Add-per-table-slow_query_log_timeout_in_ms-property.patch, 
> 0001-Add-per-table-slow_query_log_timeout_in_ms-property.patch
>
>
> CASSANDRA-12403 made it possible to log slow queries, but the time specified 
> is a global one.  This isn't useful if we know different tables have 
> different access patterns, as we'll end up with a lot of noise.  We should be 
> able to override the slow query time at a per table level.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-13934) xxHash as a new partitioner

[Salih Gedik (JIRA)]

Salih Gedik created CASSANDRA-13934:
---

 Summary: xxHash as a new partitioner
 Key: CASSANDRA-13934
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13934
 Project: Cassandra
  Issue Type: New Feature
Reporter: Salih Gedik
Priority: Minor


Hi,

According to [benchmarks|https://cyan4973.github.io/xxHash/] xxHash seems to be 
more performant when used as a consistent hasher. I would like to implement 
xxHash as a partitioner for Cassandra. It should not be strictly the default 
partitioner but as an optional. I am happy to have your ideas related to this.

Thanks



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13931) Cassandra JVM stop itself randomly

[Andrey Lataev (JIRA)]

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

Andrey Lataev commented on CASSANDRA-13931:
---

Now time I will try to set:
{code:java}
concurrent_reads: 32
concurrent_writes: 64
{code}

and 

{code:java}
MAX_HEAP_SIZE="16G"
JVM_OPTS="$JVM_OPTS -XX:MaxDirectMemorySize=24G"
{code}


> Cassandra JVM stop itself randomly
> --
>
> Key: CASSANDRA-13931
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13931
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: RHEL 7.3
> JDK HotSpot 1.8.0_121-b13
> cassandra-3.11 cluster with 43 nodes in 9 datacenters
> 8vCPU, 32 GB RAM
>Reporter: Andrey Lataev
> Attachments: cassandra-env.sh, cassandra.yaml, 
> system.log.2017-10-01.zip
>
>
> Before I set  -XX:MaxDirectMemorySize  I receive  OOM on OS level like;
> # # grep "Out of" /var/log/messages-20170918
> Sep 16 06:54:07 p00skimnosql04 kernel: Out of memory: Kill process 26619 
> (java) score 287 or sacrifice child
> Sep 16 06:54:07 p00skimnosql04 kernel: Out of memory: Kill process 26640 
> (java) score 289 or sacrifice child
> If set  -XX:MaxDirectMemorySize=5G limitation then periodicaly begin receive:
> HeapUtils.java:136 - Dumping heap to 
> /egov/dumps/cassandra-1506868110-pid11155.hprof
> It seems like  JVM kill itself when off-heap memory leaks occur.
> Typical errors in  system.log before JVM begin dumping:
> ERROR [MessagingService-Incoming-/172.20.4.143] 2017-10-01 19:00:36,336 
> CassandraDaemon.java:228 - Exception in thread 
> Thread[MessagingService-Incoming-/172.20.4.143,5,main]
> ERROR [Native-Transport-Requests-139] 2017-10-01 19:04:02,675 
> Message.java:625 - Unexpected exception during request; channel = [id: 
> 0x3c0c1c26, L:/172.20.4.142:9042 - R:/172.20.4.139:44874]
> Full stack traces:
> ERROR [Native-Transport-Requests-139] 2017-10-01 19:04:02,675 
> Message.java:625 - Unexpected exception during request; channel = [id: 
> 0x3c0c1c26, L:/172.20.4.142:9042 -
> R:/172.20.4.139:44874]
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.transport.ServerConnection.applyStateTransition(ServerConnection.java:97)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:521)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:348)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_121]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [apache-cassandra-3.11.0.jar:3.1
> 1.0]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.0.jar:3.11.0]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> INFO  [MutationStage-127] 2017-10-01 19:08:24,255 HeapUtils.java:136 - 
> Dumping heap to /egov/dumps/cassandra-1506868110-pid11155.hprof ...
> Heap dump file created
> ERROR [MessagingService-Incoming-/172.20.4.143] 2017-10-01 19:08:33,493 
> CassandraDaemon.java:228 - Exception in thread 
> Thread[MessagingService-Incoming-/172.20.4.143,5,main]
> java.io.IOError: java.io.EOFException: Stream ended prematurely
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:227)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:215)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize30(PartitionUpdate.java:839)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> 

[jira] [Commented] (CASSANDRA-13915) Create a Docker container to build the docs

[Joaquin Casares (JIRA)]

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

Joaquin Casares commented on CASSANDRA-13915:
-

Nice, thanks for confirming on {{ant realclean}} cleaning the docs directory. I 
thought it was weird that it wasn't already there.

I've removed the {{open}} keyword since it was definitely only for OS-X. 
{{exe-open}} works on my Linux machine, fwiw.

I haven't had great success getting the container to run as the local user's 
PID. For OSX, they do a great job with in-container permissions, most times. 
For Linux I always have to do a little dance, but rarely have had to implement 
something to make the container's data accessible to the host user. Most times 
I have to make the container's user be able to access the host's data.

As far as Mac vs Linux differences, I'll leave that to [~rustyrazorblade] to 
debug and send me anything he finds, if you wouldn't mind? If it's a 
permissions issue, send me to the file you're having issues with and I'll make 
necessary Docker changes since I'm on OSX right now. Other than permissions 
issues, I've never seen a difference between OSX and Linux containers and the 
container is currently running as the {{root}} user, so there shouldn't be any 
issues that I can think of.

As far as resolving the Linux permissions issues, won't a {{sudo ant 
realclean}} work for you [~jasobrown]? If not, I'll have to dig deeper to see 
if it's even possible to mount the volume and have the container's user match 
the host user's PID.

> Create a Docker container to build the docs
> ---
>
> Key: CASSANDRA-13915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13915
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>
> As requested by [~rustyrazorblade], I will be adding a Docker container to 
> build the docs without any prereqs (other than Docker).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13923) Flushers blocked due to many SSTables

[Dan Kinder (JIRA)]

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

Dan Kinder commented on CASSANDRA-13923:


So far the nodes seem to be performing better, they are doing a lot of 
compactions. So, that patch seemed to do the trick.

Sadly I was not able to get a jstack with -l.

> Flushers blocked due to many SSTables
> -
>
> Key: CASSANDRA-13923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13923
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction, Local Write-Read Paths
> Environment: Cassandra 3.11.0
> Centos 6 (downgraded JNA)
> 64GB RAM
> 12-disk JBOD
>Reporter: Dan Kinder
>Assignee: Marcus Eriksson
> Attachments: cassandra-jstack-readstage.txt, cassandra-jstack.txt
>
>
> This started on the mailing list and I'm not 100% sure of the root cause, 
> feel free to re-title if needed.
> I just upgraded Cassandra from 2.2.6 to 3.11.0. Within a few hours of serving 
> traffic, thread pools begin to back up and grow pending tasks indefinitely. 
> This happens to multiple different stages (Read, Mutation) and consistently 
> builds pending tasks for MemtablePostFlush and MemtableFlushWriter.
> Using jstack shows that there is blocking going on when trying to call 
> getCompactionCandidates, which seems to happen on flush. We have fairly large 
> nodes that have ~15,000 SSTables per node, all LCS.
> I seems like this can cause reads to get blocked because they try to acquire 
> a read lock when calling shouldDefragment.
> And writes, of course, block once we can't allocate anymore memtables, 
> because flushes are backed up.
> We did not have this problem in 2.2.6, so it seems like there is some 
> regression causing it to be incredibly slow trying to do calls like 
> getCompactionCandidates that list out the SSTables.
> In our case this causes nodes to build up pending tasks and simply stop 
> responding to requests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13915) Create a Docker container to build the docs

[Jason Brown (JIRA)]

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

Jason Brown edited comment on CASSANDRA-13915 at 10/4/17 5:42 PM:
--

bq.  Otherwise the backup message all the time works for me

Let's keep things simple and print the 'backup' message. Anyone in the know on 
macOS can do other, clever things.




was (Author: jasobrown):
bq.  Otherwise the backup message all the time works for me

Let's keep things simple and print the 'backup' message. Anyone in the know on 
Mac can do other, clever things.



> Create a Docker container to build the docs
> ---
>
> Key: CASSANDRA-13915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13915
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>
> As requested by [~rustyrazorblade], I will be adding a Docker container to 
> build the docs without any prereqs (other than Docker).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13915) Create a Docker container to build the docs

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13915:
-

bq.  Otherwise the backup message all the time works for me

Let's keep things simple and print the 'backup' message. Anyone in the know on 
Mac can do other, clever things.



> Create a Docker container to build the docs
> ---
>
> Key: CASSANDRA-13915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13915
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>
> As requested by [~rustyrazorblade], I will be adding a Docker container to 
> build the docs without any prereqs (other than Docker).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13915) Create a Docker container to build the docs

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-13915:

Reviewer: Jason Brown

> Create a Docker container to build the docs
> ---
>
> Key: CASSANDRA-13915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13915
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>
> As requested by [~rustyrazorblade], I will be adding a Docker container to 
> build the docs without any prereqs (other than Docker).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13915) Create a Docker container to build the docs

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13915:
-

Also, another mac vs linux difference: the navigation on the left works on a 
mac, completely broken on linux. Actually, all hyperlinks are broken on linux. 
Can you take a look?

> Create a Docker container to build the docs
> ---
>
> Key: CASSANDRA-13915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13915
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>
> As requested by [~rustyrazorblade], I will be adding a Docker container to 
> build the docs without any prereqs (other than Docker).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13741) Replace Cassandra's lz4-1.3.0.jar with lz4-java-1.4.0.jar

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-13741:


Github user jeffjirsa commented on the issue:

https://github.com/apache/cassandra/pull/138
  
CASSANDRA-13741 has been committed, would you mind closing this PR 
@ghatwala ? 


> Replace Cassandra's lz4-1.3.0.jar with lz4-java-1.4.0.jar
> -
>
> Key: CASSANDRA-13741
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13741
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Amitkumar Ghatwal
>Assignee: Michael Kjellman
> Fix For: 4.0
>
>
> Hi All,
> The latest lz4-java library has been released 
> (https://github.com/lz4/lz4-java/releases) and uploaded to maven central . 
> Please replace in mainline the current version ( 1.3.0) with the latest one ( 
> 1.4.0) from here - http://repo1.maven.org/maven2/org/lz4/lz4-java/1.4.0/
> Adding : [~ReiOdaira].
> Regards,
> Amit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13915) Create a Docker container to build the docs

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13915:
-

Also, fwiw, the design/look of the output html files is different that what we 
have currently [on the apache.org 
site|https://cassandra.apache.org/doc/latest/]. Was this is intentional? Is 
this a default? Does it matter?

I don't care too much either way, just want to make sure this is a known thing.

> Create a Docker container to build the docs
> ---
>
> Key: CASSANDRA-13915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13915
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>
> As requested by [~rustyrazorblade], I will be adding a Docker container to 
> build the docs without any prereqs (other than Docker).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13915) Create a Docker container to build the docs

[Jon Haddad (JIRA)]

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

Jon Haddad commented on CASSANDRA-13915:


>  At a minimum, the realclean problem needs to be fixed as I suspect we'll 
> have it part of the automation for building the online docs hosted on 
> cassandra.apache.org

Agreed, my Docker knowledge is also pretty low.  Maybe the volume needs to be 
mounted as the current user?  (just a guess)

> For open, either remove the whole statement or add a note saying "mac only" 
> or something. Jon Haddad thoughts?

Is there a linux alternative?  Is it even possible to identify the host OS?  
I'd be fine with spitting out the open command on mac and a backup "open 
build/html/index.htmlfile in your browser to view the docs" message if we 
don't know it's mac.  Otherwise the backup message all the time works for me.

> Create a Docker container to build the docs
> ---
>
> Key: CASSANDRA-13915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13915
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>
> As requested by [~rustyrazorblade], I will be adding a Docker container to 
> build the docs without any prereqs (other than Docker).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13642) Expose recent histograms in JmxHistograms

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-13642:


Github user asfgit closed the pull request at:

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


> Expose recent histograms in JmxHistograms
> -
>
> Key: CASSANDRA-13642
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13642
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
> Fix For: 4.0
>
>
> For monitoring tools that were written for the recent*Histograms the current 
> decaying and all time values exposed by the JmxHistograms is not consumable. 
> We can add a new attribute (easier with some tooling than operations to read) 
> to expose it just like in storage service previously.
> Should additionally make it so this attribute only stores previous values if 
> read, so that it does not add any additional memory cost to C* unless used 
> since we already storing 2 versions of histogram for the decaying/alltime 
> views.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13642) Expose recent histograms in JmxHistograms

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13642:
---
Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

Thanks to both of you. Committed as {{9a47974d6378b62dd2cdb2d3e509374b002caa2c}}


> Expose recent histograms in JmxHistograms
> -
>
> Key: CASSANDRA-13642
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13642
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>
> For monitoring tools that were written for the recent*Histograms the current 
> decaying and all time values exposed by the JmxHistograms is not consumable. 
> We can add a new attribute (easier with some tooling than operations to read) 
> to expose it just like in storage service previously.
> Should additionally make it so this attribute only stores previous values if 
> read, so that it does not add any additional memory cost to C* unless used 
> since we already storing 2 versions of histogram for the decaying/alltime 
> views.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13642) Expose recent histograms in JmxHistograms

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13642:
---
Fix Version/s: 4.0

> Expose recent histograms in JmxHistograms
> -
>
> Key: CASSANDRA-13642
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13642
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
> Fix For: 4.0
>
>
> For monitoring tools that were written for the recent*Histograms the current 
> decaying and all time values exposed by the JmxHistograms is not consumable. 
> We can add a new attribute (easier with some tooling than operations to read) 
> to expose it just like in storage service previously.
> Should additionally make it so this attribute only stores previous values if 
> read, so that it does not add any additional memory cost to C* unless used 
> since we already storing 2 versions of histogram for the decaying/alltime 
> views.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

cassandra git commit: Expose recent histograms in JmxHistograms

[jjirsa]

Repository: cassandra
Updated Branches:
  refs/heads/trunk d080a7372 -> 9a47974d6


Expose recent histograms in JmxHistograms

Closes #126

Patch by CHris Lohfink; Reviewed by Jeremiah Jordan for CASSANDRA-13642


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

Branch: refs/heads/trunk
Commit: 9a47974d6378b62dd2cdb2d3e509374b002caa2c
Parents: d080a73
Author: Chris Lohfink 
Authored: Tue Jun 27 14:10:50 2017 -0500
Committer: Jeff Jirsa 
Committed: Wed Oct 4 10:28:39 2017 -0700

--
 CHANGES.txt |  1 +
 .../metrics/CassandraMetricsRegistry.java   | 48 
 .../metrics/CassandraMetricsRegistryTest.java   | 29 ++--
 3 files changed, 74 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9a47974d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 635c2f4..e006db3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0
+ * Expose recent histograms in JmxHistograms (CASSANDRA-13642)
  * Fix buffer length comparison when decompressing in netty-based streaming 
(CASSANDRA-13899)
  * Properly close StreamCompressionInputStream to release any ByteBuf 
(CASSANDRA-13906)
  * Add SERIAL and LOCAL_SERIAL support for cassandra-stress (CASSANDRA-13925)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9a47974d/src/java/org/apache/cassandra/metrics/CassandraMetricsRegistry.java
--
diff --git 
a/src/java/org/apache/cassandra/metrics/CassandraMetricsRegistry.java 
b/src/java/org/apache/cassandra/metrics/CassandraMetricsRegistry.java
index e1a5703..97a932b 100644
--- a/src/java/org/apache/cassandra/metrics/CassandraMetricsRegistry.java
+++ b/src/java/org/apache/cassandra/metrics/CassandraMetricsRegistry.java
@@ -23,6 +23,8 @@ import java.util.Locale;
 import java.util.concurrent.TimeUnit;
 
 import com.codahale.metrics.*;
+import com.google.common.annotations.VisibleForTesting;
+
 import javax.management.*;
 
 /**
@@ -273,11 +275,14 @@ public class CassandraMetricsRegistry extends 
MetricRegistry
 double get999thPercentile();
 
 long[] values();
+
+long[] getRecentValues();
 }
 
 private static class JmxHistogram extends AbstractBean implements 
JmxHistogramMBean
 {
 private final Histogram metric;
+private long[] last = null;
 
 private JmxHistogram(Histogram metric, ObjectName objectName)
 {
@@ -356,6 +361,15 @@ public class CassandraMetricsRegistry extends 
MetricRegistry
 {
 return metric.getSnapshot().getValues();
 }
+
+@Override
+public long[] getRecentValues()
+{
+long[] now = metric.getSnapshot().getValues();
+long[] delta = delta(now, last);
+last = now;
+return delta;
+}
 }
 
 public interface JmxCounterMBean extends MetricMBean
@@ -476,6 +490,8 @@ public class CassandraMetricsRegistry extends MetricRegistry
 
 long[] values();
 
+long[] getRecentValues();
+
 String getDurationUnit();
 }
 
@@ -484,6 +500,7 @@ public class CassandraMetricsRegistry extends MetricRegistry
 private final Timer metric;
 private final double durationFactor;
 private final String durationUnit;
+private long[] last = null;
 
 private JmxTimer(Timer metric,
  ObjectName objectName,
@@ -563,6 +580,15 @@ public class CassandraMetricsRegistry extends 
MetricRegistry
 }
 
 @Override
+public long[] getRecentValues()
+{
+long[] now = metric.getSnapshot().getValues();
+long[] delta = delta(now, last);
+last = now;
+return delta;
+}
+
+@Override
 public String getDurationUnit()
 {
 return durationUnit;
@@ -570,6 +596,28 @@ public class CassandraMetricsRegistry extends 
MetricRegistry
 }
 
 /**
+ * Used to determine the changes in a histogram since the last time 
checked.
+ *
+ * @param now The current histogram
+ * @param last The previous value of the histogram
+ * @return the difference between now and last
+ */
+@VisibleForTesting
+static long[] delta(long[] now, long[] last)
+{
+long[] delta = new long[now.length];
+if (last == null)
+{
+last = new long[now.length];
+}
+for(int i = 0; i< now.length; i++)
+   

[jira] [Commented] (CASSANDRA-13915) Create a Docker container to build the docs

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13915:
-

bq. Dockerfile and docker-compose.yml are the default names for working with 
Docker-related projects

sgtm. as stated above, I am a container noob.

bq.  you two fine with me adding the doc/build directory to the ant realclean?

totally legit: {{realclean}} *should* clean all build artifacts.

When I build the docs, there's the message at the end:

{code}
The locally built documentation can be found here:

open build/html/index.html
{code}

However, when I do this on ubuntu 17.04, I get the following error:

{code}
$ open build/html/index.html   
Couldn't get a file descriptor referring to the console
{code}

A naive internet search reveals that {{open}} [isn't quite what we 
want|https://ubuntuforums.org/showthread.php?t=2124061}. How did you test this?

Next error: after I build the docs a few times, on the same linux install, I 
run {{ant realclean}} again, which produces this error:

{code}
BUILD FAILED
/opt/dev/cassandra/build.xml:196: Unable to delete directory 
/opt/dev/cassandra/build/test/lib
{code}

A quick look shows everything in {{/opt/dev/cassandra/build/}} is now owned by 
root, and I need to {{sudo rm -rf build}} to clean it up. Which, of course, 
leads to:

{code}
BUILD FAILED
/opt/dev/cassandra/build.xml:207: Unable to delete file 
/opt/dev/cassandra/doc/build/doctrees/configuration/index.doctree
{code}

Once again, {{sudo rm -rf}}. Can you change the privileges of the artifacts 
that get generated, both in ./build and ./doc/build?

UPDATE: I tried out all these commands on a Mac (High Sierra), and after 
installing Docker, everything was much smoother. No permissions issues for 
{{ant realclean}}, and {{open}} worked correctly. At a minimum, the 
{{realclean}} problem needs to be fixed as I suspect we'll have it part of thew 
automation for building the online docs hosted on cassandra.apache.org. For 
{{open}}, either remove the whole statement or add a note saying "mac only" or 
something. [~rustyrazorblade] thoughts?


> Create a Docker container to build the docs
> ---
>
> Key: CASSANDRA-13915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13915
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>
> As requested by [~rustyrazorblade], I will be adding a Docker container to 
> build the docs without any prereqs (other than Docker).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13915) Create a Docker container to build the docs

[Jason Brown (JIRA)]

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

Jason Brown edited comment on CASSANDRA-13915 at 10/4/17 5:28 PM:
--

bq. Dockerfile and docker-compose.yml are the default names for working with 
Docker-related projects

sgtm. as stated above, I am a container noob.

bq.  you two fine with me adding the doc/build directory to the ant realclean?

totally legit: {{realclean}} *should* clean all build artifacts.

When I build the docs, there's the message at the end:

{code}
The locally built documentation can be found here:

open build/html/index.html
{code}

However, when I do this on ubuntu 17.04, I get the following error:

{code}
$ open build/html/index.html   
Couldn't get a file descriptor referring to the console
{code}

A naive internet search reveals that {{open}} [isn't quite what we 
want|https://ubuntuforums.org/showthread.php?t=2124061}. How did you test this?

Next error: after I build the docs a few times, on the same linux install, I 
run {{ant realclean}} again, which produces this error:

{code}
BUILD FAILED
/opt/dev/cassandra/build.xml:196: Unable to delete directory 
/opt/dev/cassandra/build/test/lib
{code}

A quick look shows everything in {{/opt/dev/cassandra/build/}} is now owned by 
root, and I need to {{sudo rm -rf build}} to clean it up. Which, of course, 
leads to:

{code}
BUILD FAILED
/opt/dev/cassandra/build.xml:207: Unable to delete file 
/opt/dev/cassandra/doc/build/doctrees/configuration/index.doctree
{code}

Once again, {{sudo rm -rf}}. Can you change the privileges of the artifacts 
that get generated, both in ./build and ./doc/build?

UPDATE: I tried out all these commands on a Mac (High Sierra), and after 
installing Docker, everything was much smoother. No permissions issues for 
{{ant realclean}}, and {{open}} worked correctly. At a minimum, the 
{{realclean}} problem needs to be fixed as I suspect we'll have it part of the 
automation for building the online docs hosted on cassandra.apache.org. For 
{{open}}, either remove the whole statement or add a note saying "mac only" or 
something. [~rustyrazorblade] thoughts?



was (Author: jasobrown):
bq. Dockerfile and docker-compose.yml are the default names for working with 
Docker-related projects

sgtm. as stated above, I am a container noob.

bq.  you two fine with me adding the doc/build directory to the ant realclean?

totally legit: {{realclean}} *should* clean all build artifacts.

When I build the docs, there's the message at the end:

{code}
The locally built documentation can be found here:

open build/html/index.html
{code}

However, when I do this on ubuntu 17.04, I get the following error:

{code}
$ open build/html/index.html   
Couldn't get a file descriptor referring to the console
{code}

A naive internet search reveals that {{open}} [isn't quite what we 
want|https://ubuntuforums.org/showthread.php?t=2124061}. How did you test this?

Next error: after I build the docs a few times, on the same linux install, I 
run {{ant realclean}} again, which produces this error:

{code}
BUILD FAILED
/opt/dev/cassandra/build.xml:196: Unable to delete directory 
/opt/dev/cassandra/build/test/lib
{code}

A quick look shows everything in {{/opt/dev/cassandra/build/}} is now owned by 
root, and I need to {{sudo rm -rf build}} to clean it up. Which, of course, 
leads to:

{code}
BUILD FAILED
/opt/dev/cassandra/build.xml:207: Unable to delete file 
/opt/dev/cassandra/doc/build/doctrees/configuration/index.doctree
{code}

Once again, {{sudo rm -rf}}. Can you change the privileges of the artifacts 
that get generated, both in ./build and ./doc/build?

UPDATE: I tried out all these commands on a Mac (High Sierra), and after 
installing Docker, everything was much smoother. No permissions issues for 
{{ant realclean}}, and {{open}} worked correctly. At a minimum, the 
{{realclean}} problem needs to be fixed as I suspect we'll have it part of thew 
automation for building the online docs hosted on cassandra.apache.org. For 
{{open}}, either remove the whole statement or add a note saying "mac only" or 
something. [~rustyrazorblade] thoughts?


> Create a Docker container to build the docs
> ---
>
> Key: CASSANDRA-13915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13915
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>
> As requested by [~rustyrazorblade], I will be adding a Docker container to 
> build the docs without any prereqs (other than Docker).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, 

[jira] [Commented] (CASSANDRA-13915) Create a Docker container to build the docs

[Jon Haddad (JIRA)]

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

Jon Haddad commented on CASSANDRA-13915:


Yes, I think removing the built docs falls under the responsibility of 
realclean.

> Create a Docker container to build the docs
> ---
>
> Key: CASSANDRA-13915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13915
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>
> As requested by [~rustyrazorblade], I will be adding a Docker container to 
> build the docs without any prereqs (other than Docker).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13760) presize collections

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13760:
---
Status: Ready to Commit  (was: Patch Available)

> presize collections
> ---
>
> Key: CASSANDRA-13760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13760
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Dave Brosius
>Assignee: Dave Brosius
>Priority: Trivial
> Fix For: 4.x
>
> Attachments: 0001-Presize-collections.patch, 13760.txt, Screen Shot 
> 2017-09-18 at 9.50.17 PM.png, test-output.png
>
>
> presize collections where sane, to avoid reallocs, or excess garbage



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13760) presize collections

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13760:


Kicked off another run because I hate seeing all the failures, but none of the 
dtest failures in 329 or 357 ( 
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/357/testReport/
 ) seem to be unique to this patch, so I'm asserting they're all existing or 
environmental problems. Looks good to me to commit. +1 for either your version 
or my version 

> presize collections
> ---
>
> Key: CASSANDRA-13760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13760
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Dave Brosius
>Assignee: Dave Brosius
>Priority: Trivial
> Fix For: 4.x
>
> Attachments: 0001-Presize-collections.patch, 13760.txt, Screen Shot 
> 2017-09-18 at 9.50.17 PM.png, test-output.png
>
>
> presize collections where sane, to avoid reallocs, or excess garbage



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13915) Create a Docker container to build the docs

[Joaquin Casares (JIRA)]

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

Joaquin Casares commented on CASSANDRA-13915:
-

My feelings exactly on having too many scars of not running {{ant realclean}}. 
But I also understand quick turnaround times for this container. I've remove 
the {{ant realclean}}, but added a few documentation notes to prevent future 
scars.

[~jasobrown], {{Dockerfile}} and {{docker-compose.yml}} are the default names 
for working with Docker-related projects. Because both files are within 
{{doc/}} it typically implies that it will be a doc-centric container. I have 
however added a short comment to the top of the {{Dockerfile}} and 
{{docker-compose.yml}} to make this more evident.

Do also note that {{docker-compose build build-docs}} will only take so long 
the first time. If the command is executed again and no changes to the 
{{Dockerfile}} have occurred, docker will used the previously-built cached 
images.

Were you two fine with me adding the {{doc/build}} directory to the {{ant 
realclean}}? Just wanted to confirm.

> Create a Docker container to build the docs
> ---
>
> Key: CASSANDRA-13915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13915
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>
> As requested by [~rustyrazorblade], I will be adding a Docker container to 
> build the docs without any prereqs (other than Docker).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13931) Cassandra JVM stop itself randomly

[Andrey Lataev (JIRA)]

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

Andrey Lataev edited comment on CASSANDRA-13931 at 10/4/17 3:41 PM:


As you can see in attached cassandra-env.sh file
row:
{code:java}
JVM_OPTS="$JVM_OPTS -Djdk.nio.maxCachedBufferSize=262144"
{code}

- exist.
I will try to enlarge RAM and and increase heap size til 16Gb.
Eclipse Memory Analyser for heapdump shown top 3 problem suspect:

*Problem Suspect 1*
{code:java}
The thread org.apache.cassandra.net.OutboundTcpConnection @ 0x6cd263100 
MessagingService-Outgoing-p00skimnosql10.00.egov.local/172.20.4.148-Large keeps 
local variables with total size 306 114 312 (13,97%) bytes.

The memory is accumulated in one instance of 
"org.apache.cassandra.net.OutboundTcpConnection" loaded by 
"sun.misc.Launcher$AppClassLoader @ 0x6c000".
{code}

*Problem Suspect 2*

{code:java}
529 instances of "io.netty.util.concurrent.FastThreadLocalThread", loaded by 
"sun.misc.Launcher$AppClassLoader @ 0x6c000" occupy 776 362 840 (35,43%) 
bytes. 

Biggest instances:

•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d719e1e0 
epollEventLoopGroup-2-7 - 156 689 680 (7,15%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d719e7e0 
epollEventLoopGroup-2-3 - 125 567 112 (5,73%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d719da60 
epollEventLoopGroup-2-12 - 119 599 160 (5,46%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6ceab17b0 
epollEventLoopGroup-2-1 - 118 469 632 (5,41%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d7059b00 ReadStage-151 - 
66 494 040 (3,03%) bytes. 
{code}

*Problem Suspect 3*

{code:java}
126 instances of "byte[]", loaded by "" occupy 268 549 640 
(12,26%) bytes. These instances are referenced from one instance of 
"java.util.HashMap$Node[]", loaded by ""

Keywords
byte[]
java.util.HashMap$Node[]
{code}




was (Author: ljus):
As you can see in attached cassandra-env.sh file
row:
{code:java}
JVM_OPTS="$JVM_OPTS -Djdk.nio.maxCachedBufferSize=262144"
{code}

- exist.
I will try to enlarge RAM and and increase heap size til 16Gb.
Eclipse Memory Analyser for heapdump shown top 3 problem suspect:

*Problem Suspect 1*
{code:java}
The thread org.apache.cassandra.net.OutboundTcpConnection @ 0x6cd263100 
MessagingService-Outgoing-p00skimnosql10.00.egov.local/172.20.4.148-Large keeps 
local variables with total size 306 114 312 (13,97%) bytes.

The memory is accumulated in one instance of 
"org.apache.cassandra.net.OutboundTcpConnection" loaded by 
"sun.misc.Launcher$AppClassLoader @ 0x6c000".
{code}

* Problem Suspect 2*

{code:java}
529 instances of "io.netty.util.concurrent.FastThreadLocalThread", loaded by 
"sun.misc.Launcher$AppClassLoader @ 0x6c000" occupy 776 362 840 (35,43%) 
bytes. 

Biggest instances:

•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d719e1e0 
epollEventLoopGroup-2-7 - 156 689 680 (7,15%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d719e7e0 
epollEventLoopGroup-2-3 - 125 567 112 (5,73%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d719da60 
epollEventLoopGroup-2-12 - 119 599 160 (5,46%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6ceab17b0 
epollEventLoopGroup-2-1 - 118 469 632 (5,41%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d7059b00 ReadStage-151 - 
66 494 040 (3,03%) bytes. 
{code}

*Problem Suspect 3*

{code:java}
126 instances of "byte[]", loaded by "" occupy 268 549 640 
(12,26%) bytes. These instances are referenced from one instance of 
"java.util.HashMap$Node[]", loaded by ""

Keywords
byte[]
java.util.HashMap$Node[]
{code}



> Cassandra JVM stop itself randomly
> --
>
> Key: CASSANDRA-13931
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13931
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: RHEL 7.3
> JDK HotSpot 1.8.0_121-b13
> cassandra-3.11 cluster with 43 nodes in 9 datacenters
> 8vCPU, 32 GB RAM
>Reporter: Andrey Lataev
> Attachments: cassandra-env.sh, cassandra.yaml, 
> system.log.2017-10-01.zip
>
>
> Before I set  -XX:MaxDirectMemorySize  I receive  OOM on OS level like;
> # # grep "Out of" /var/log/messages-20170918
> Sep 16 06:54:07 p00skimnosql04 kernel: Out of memory: Kill process 26619 
> (java) score 287 or sacrifice child
> Sep 16 06:54:07 p00skimnosql04 kernel: Out of memory: Kill process 26640 
> (java) score 289 or sacrifice child
> If set  -XX:MaxDirectMemorySize=5G limitation then periodicaly begin receive:
> HeapUtils.java:136 - Dumping heap to 
> /egov/dumps/cassandra-1506868110-pid11155.hprof
> It seems like  JVM kill itself when off-heap memory leaks occur.
> Typical errors in  system.log before JVM begin dumping:
> ERROR 

[jira] [Comment Edited] (CASSANDRA-13931) Cassandra JVM stop itself randomly

[Andrey Lataev (JIRA)]

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

Andrey Lataev edited comment on CASSANDRA-13931 at 10/4/17 3:40 PM:


As you can see in attached cassandra-env.sh file
row:
{code:java}
JVM_OPTS="$JVM_OPTS -Djdk.nio.maxCachedBufferSize=262144"
{code}

- exist.
I will try to enlarge RAM and and increase heap size til 16Gb.
Eclipse Memory Analyser for heapdump shown top 3 problem suspect:

*Problem Suspect 1*
{code:java}
The thread org.apache.cassandra.net.OutboundTcpConnection @ 0x6cd263100 
MessagingService-Outgoing-p00skimnosql10.00.egov.local/172.20.4.148-Large keeps 
local variables with total size 306 114 312 (13,97%) bytes.

The memory is accumulated in one instance of 
"org.apache.cassandra.net.OutboundTcpConnection" loaded by 
"sun.misc.Launcher$AppClassLoader @ 0x6c000".
{code}

* Problem Suspect 2*

{code:java}
529 instances of "io.netty.util.concurrent.FastThreadLocalThread", loaded by 
"sun.misc.Launcher$AppClassLoader @ 0x6c000" occupy 776 362 840 (35,43%) 
bytes. 

Biggest instances:

•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d719e1e0 
epollEventLoopGroup-2-7 - 156 689 680 (7,15%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d719e7e0 
epollEventLoopGroup-2-3 - 125 567 112 (5,73%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d719da60 
epollEventLoopGroup-2-12 - 119 599 160 (5,46%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6ceab17b0 
epollEventLoopGroup-2-1 - 118 469 632 (5,41%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d7059b00 ReadStage-151 - 
66 494 040 (3,03%) bytes. 
{code}

*Problem Suspect 3*

{code:java}
126 instances of "byte[]", loaded by "" occupy 268 549 640 
(12,26%) bytes. These instances are referenced from one instance of 
"java.util.HashMap$Node[]", loaded by ""

Keywords
byte[]
java.util.HashMap$Node[]
{code}




was (Author: ljus):
As you can see in attached cassandra-env.sh file
row:
{code:java}
JVM_OPTS="$JVM_OPTS -Djdk.nio.maxCachedBufferSize=262144"
{code}

- exist.
I will try to enlarge RAM and and increase heap size til 16Gb.
Eclipse Memory Analyser for heapdump shown top 3 problem suspect:

*Problem Suspect 1*
{code:java}
The thread org.apache.cassandra.net.OutboundTcpConnection @ 0x6cd263100 
MessagingService-Outgoing-p00skimnosql10.00.egov.local/172.20.4.148-Large keeps 
local variables with total size 306 114 312 (13,97%) bytes.

The memory is accumulated in one instance of 
"org.apache.cassandra.net.OutboundTcpConnection" loaded by 
"sun.misc.Launcher$AppClassLoader @ 0x6c000".
{code}

* Problem Suspect 2*

{code:java}
529 instances of "io.netty.util.concurrent.FastThreadLocalThread", loaded by 
"sun.misc.Launcher$AppClassLoader @ 0x6c000" occupy 776 362 840 (35,43%) 
bytes. 

Biggest instances:

•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d719e1e0 
epollEventLoopGroup-2-7 - 156 689 680 (7,15%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d719e7e0 
epollEventLoopGroup-2-3 - 125 567 112 (5,73%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d719da60 
epollEventLoopGroup-2-12 - 119 599 160 (5,46%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6ceab17b0 
epollEventLoopGroup-2-1 - 118 469 632 (5,41%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d7059b00 ReadStage-151 - 
66 494 040 (3,03%) bytes. 
{code}

*Problem Suspect 3*

{code:java}
126 instances of "byte[]", loaded by "" occupy 268 549 640 
(12,26%) bytes. These instances are referenced from one instance of 
"java.util.HashMap$Node[]", loaded by ""

Keywords
byte[]
java.util.HashMap$Node[]
{code}



> Cassandra JVM stop itself randomly
> --
>
> Key: CASSANDRA-13931
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13931
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: RHEL 7.3
> JDK HotSpot 1.8.0_121-b13
> cassandra-3.11 cluster with 43 nodes in 9 datacenters
> 8vCPU, 32 GB RAM
>Reporter: Andrey Lataev
> Attachments: cassandra-env.sh, cassandra.yaml, 
> system.log.2017-10-01.zip
>
>
> Before I set  -XX:MaxDirectMemorySize  I receive  OOM on OS level like;
> # # grep "Out of" /var/log/messages-20170918
> Sep 16 06:54:07 p00skimnosql04 kernel: Out of memory: Kill process 26619 
> (java) score 287 or sacrifice child
> Sep 16 06:54:07 p00skimnosql04 kernel: Out of memory: Kill process 26640 
> (java) score 289 or sacrifice child
> If set  -XX:MaxDirectMemorySize=5G limitation then periodicaly begin receive:
> HeapUtils.java:136 - Dumping heap to 
> /egov/dumps/cassandra-1506868110-pid11155.hprof
> It seems like  JVM kill itself when off-heap memory leaks occur.
> Typical errors in  system.log before JVM begin dumping:
> ERROR 

[jira] [Commented] (CASSANDRA-13931) Cassandra JVM stop itself randomly

[Andrey Lataev (JIRA)]

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

Andrey Lataev commented on CASSANDRA-13931:
---

As you can see in attached cassandra-env.sh file
row:
{code:java}
JVM_OPTS="$JVM_OPTS -Djdk.nio.maxCachedBufferSize=262144"
{code}

- exist.
I will try to enlarge RAM and and increase heap size til 16Gb.
Eclipse Memory Analyser for heapdump shown top 3 problem suspect:

*Problem Suspect 1*
{code:java}
The thread org.apache.cassandra.net.OutboundTcpConnection @ 0x6cd263100 
MessagingService-Outgoing-p00skimnosql10.00.egov.local/172.20.4.148-Large keeps 
local variables with total size 306 114 312 (13,97%) bytes.

The memory is accumulated in one instance of 
"org.apache.cassandra.net.OutboundTcpConnection" loaded by 
"sun.misc.Launcher$AppClassLoader @ 0x6c000".
{code}

* Problem Suspect 2*

{code:java}
529 instances of "io.netty.util.concurrent.FastThreadLocalThread", loaded by 
"sun.misc.Launcher$AppClassLoader @ 0x6c000" occupy 776 362 840 (35,43%) 
bytes. 

Biggest instances:

•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d719e1e0 
epollEventLoopGroup-2-7 - 156 689 680 (7,15%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d719e7e0 
epollEventLoopGroup-2-3 - 125 567 112 (5,73%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d719da60 
epollEventLoopGroup-2-12 - 119 599 160 (5,46%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6ceab17b0 
epollEventLoopGroup-2-1 - 118 469 632 (5,41%) bytes. 
•io.netty.util.concurrent.FastThreadLocalThread @ 0x6d7059b00 ReadStage-151 - 
66 494 040 (3,03%) bytes. 
{code}

*Problem Suspect 3*

{code:java}
126 instances of "byte[]", loaded by "" occupy 268 549 640 
(12,26%) bytes. These instances are referenced from one instance of 
"java.util.HashMap$Node[]", loaded by ""

Keywords
byte[]
java.util.HashMap$Node[]
{code}



> Cassandra JVM stop itself randomly
> --
>
> Key: CASSANDRA-13931
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13931
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: RHEL 7.3
> JDK HotSpot 1.8.0_121-b13
> cassandra-3.11 cluster with 43 nodes in 9 datacenters
> 8vCPU, 32 GB RAM
>Reporter: Andrey Lataev
> Attachments: cassandra-env.sh, cassandra.yaml, 
> system.log.2017-10-01.zip
>
>
> Before I set  -XX:MaxDirectMemorySize  I receive  OOM on OS level like;
> # # grep "Out of" /var/log/messages-20170918
> Sep 16 06:54:07 p00skimnosql04 kernel: Out of memory: Kill process 26619 
> (java) score 287 or sacrifice child
> Sep 16 06:54:07 p00skimnosql04 kernel: Out of memory: Kill process 26640 
> (java) score 289 or sacrifice child
> If set  -XX:MaxDirectMemorySize=5G limitation then periodicaly begin receive:
> HeapUtils.java:136 - Dumping heap to 
> /egov/dumps/cassandra-1506868110-pid11155.hprof
> It seems like  JVM kill itself when off-heap memory leaks occur.
> Typical errors in  system.log before JVM begin dumping:
> ERROR [MessagingService-Incoming-/172.20.4.143] 2017-10-01 19:00:36,336 
> CassandraDaemon.java:228 - Exception in thread 
> Thread[MessagingService-Incoming-/172.20.4.143,5,main]
> ERROR [Native-Transport-Requests-139] 2017-10-01 19:04:02,675 
> Message.java:625 - Unexpected exception during request; channel = [id: 
> 0x3c0c1c26, L:/172.20.4.142:9042 - R:/172.20.4.139:44874]
> Full stack traces:
> ERROR [Native-Transport-Requests-139] 2017-10-01 19:04:02,675 
> Message.java:625 - Unexpected exception during request; channel = [id: 
> 0x3c0c1c26, L:/172.20.4.142:9042 -
> R:/172.20.4.139:44874]
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.transport.ServerConnection.applyStateTransition(ServerConnection.java:97)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:521)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:348)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_121]
> at 
> 

[jira] [Commented] (CASSANDRA-13002) per table slow query times

[Murukesh Mohanan (JIRA)]

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

Murukesh Mohanan commented on CASSANDRA-13002:
--

Except for {{CHANGES.txt}}, the patch still applies cleanly on trunk. I've 
created an issue and PR for the python driver:

https://datastax-oss.atlassian.net/browse/PYTHON-835
https://github.com/datastax/python-driver/pull/838

> per table slow query times
> --
>
> Key: CASSANDRA-13002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13002
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Observability
>Reporter: Jon Haddad
>Assignee: Murukesh Mohanan
> Fix For: 4.x
>
> Attachments: 
> 0001-Add-per-table-slow_query_log_timeout_in_ms-property.patch, 
> 0001-Add-per-table-slow_query_log_timeout_in_ms-property.patch, 
> 0001-Add-per-table-slow_query_log_timeout_in_ms-property.patch
>
>
> CASSANDRA-12403 made it possible to log slow queries, but the time specified 
> is a global one.  This isn't useful if we know different tables have 
> different access patterns, as we'll end up with a lot of noise.  We should be 
> able to override the slow query time at a per table level.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-10404) Node to Node encryption transitional mode

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-10404:
-

Missed this update, for some stupid reason

bq. 1) Assuming we have a 3.x cluster already running with ssl enabled and now 
start to bump the first node to 4.0. If we connect to storage_port by default 
in 4.0, won't the upgraded node fail to start with a "Unable to gossip with any 
seeds" error?

As I explained in the previous comment, this is the trickiest part of this 
patch. The upgraded node, after it bounces, must have at least one 3.0 node 
connect to it, and have a gossip session, for the upgraded node to a) learn 
about the version of the node that contacted via the handshake protocol, and b) 
learn about the version of other nodes in the the cluster via that round of 
gossip. Having that first round of gossip is critical for getting the versions 
of peers, which we check on each {{OutboundMessagingService#tryConnect}} 
attempt.

This does not guarantee that the upgraded node will learn about the 3.0 status 
of nodes in it's seed list before the shadow round fails, although I think the 
possiblity of shadow round failure is rather low as un-upgraded nodes will be 
trying to connect to the upgraded node (as it will be seen as DOWN by the 
peers, and they will be attempting to connect via gossip). The possibility of 
shadow round failure is non-zero, however, and I'm open to ideas on the cluster 
upgrade scenario.

bq. 2) Do we want to add an option to disable the ssl_storage_port? E.g. by 
setting it to the same value as storage_port?

Maybe we can add another property under the {{server_encryption_options}}, 
something like {{enable_legacy_ssl_storage_port}}. That would also clean up 
{{MessagingService#listen}} a little bit. wdyt?


bq. 3) doc/source/operating/security.rst: needs to be updated

Yup, I'll be happy do so when we have solid idea of where the code is going.


bq. 4) cassandra.yaml: comments for storage_port and ssl_storage_port not 
accurate anymore, as both can use encryption now. We also should clearly 
describe the port as legacy port only used during upgrades. There should be a 
link to security.rst for further details.

Ahh, good catch. Let's figure out the code and yaml props first, then I'll come 
back to properly wording the yaml comments.



bq. 5) Some of the native transport and internode netty code has become 
redundant, e.g. Server.OptionalSecureInitializer and the new 
OptionalSslHandler. It's probably not in scope of this ticket, but should maybe 
addressed in another ticket at some point.

I totally agree about the redundancy, and I would like to make that a follow up 
ticket.


bq. 6) Use of server_encryption in NettyFactory.OutboundInitializer could use 
some comments, especially on why we don't have to check all remaining options 
such as internode_encryption (already checked in MessagingService)

I've added a comment to {{NettyFactory.OutboundInitializeer#initChannel()}} 
about where the TLS determination happens, but admittedly I'm not a fan of 
burying the pointer to that so far down the code path. Not sure what's a better 
solution ...



> Node to Node encryption transitional mode
> -
>
> Key: CASSANDRA-10404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10404
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Tom Lewis
>Assignee: Jason Brown
> Fix For: 4.x
>
>
> Create a transitional mode for encryption that allows encrypted and 
> unencrypted traffic node-to-node during a change over to encryption from 
> unencrypted. This alleviates downtime during the switch.
>  This is similar to CASSANDRA-10559 which is intended for client-to-node



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13899) Fix buffer length comparison when decompressing in netty-based streaming

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13899:
-

updated the ticket title to more accurately describe the problem

> Fix buffer length comparison when decompressing in netty-based streaming
> 
>
> Key: CASSANDRA-13899
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13899
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Paulo Motta
>Assignee: Jason Brown
> Fix For: 4.0
>
> Attachments: largepartition.yaml
>
>
> Streaming a single partition with ~100K rows fails with the following 
> exception:
> {noformat}
> ERROR [Stream-Deserializer-/127.0.0.1:35149-a92e5e12] 2017-09-21 04:03:41,237 
> StreamSession.java:617 - [Stream #c2e5b640-9eab-11e7-99c0-e9864ca8da8e] 
> Streaming error occurred on session with peer 127.0.0.1
> org.apache.cassandra.streaming.StreamReceiveException: 
> java.lang.RuntimeException: Last written key 
> DecoratedKey(-1000328290821038380) >= current key 
> DecoratedKey(-1055007227842125139)  writing into 
> /home/paulo/.ccm/test/node2/data0/stresscql/typestest-482ac7b09e8d11e787cf85d073c
> 8e037/na-1-big-Data.db
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:63)
>  ~[main/:na]
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:41)
>  ~[main/:na]
> at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:55)
>  ~[main/:na]
> at 
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:178)
>  ~[main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> {noformat}
> Reproduction steps:
>  * Create CCM cluster with 2 nodes
> * Start only first node, disable hinted handoff
>  * Run stress with the attached yaml: {{tools/bin/cassandra-stress "user 
> profile=largepartition.yaml n=10K ops(insert=1) no-warmup -node whitelist 
> 127.0.0.1 -mode native cql3 compression=lz4 -rate threads=4 -insert 
> visits=FIXED(100K) revisit=FIXED(100K)"}}
> * Start second node, run repair on {{stresscql}} table - the exception above 
> will be thrown.
> I investigated briefly and haven't found anything suspicious. This seems to 
> be related to CASSANDRA-12229 as I tested the steps above in a branch without 
> that and the repair completed successfully. I haven't tested with a smaller 
> number of rows per partition to see at which point it starts to be a problem.
> We should probably add a regression dtest to stream large partitions to catch 
> similar problems in the future.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13899) Fix buffer length comparison when decompressing in netty-based streaming

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-13899:

Summary: Fix buffer length comparison when decompressing in netty-based 
streaming  (was: Streaming of compressed partition fails )

> Fix buffer length comparison when decompressing in netty-based streaming
> 
>
> Key: CASSANDRA-13899
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13899
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Paulo Motta
>Assignee: Jason Brown
> Fix For: 4.0
>
> Attachments: largepartition.yaml
>
>
> Streaming a single partition with ~100K rows fails with the following 
> exception:
> {noformat}
> ERROR [Stream-Deserializer-/127.0.0.1:35149-a92e5e12] 2017-09-21 04:03:41,237 
> StreamSession.java:617 - [Stream #c2e5b640-9eab-11e7-99c0-e9864ca8da8e] 
> Streaming error occurred on session with peer 127.0.0.1
> org.apache.cassandra.streaming.StreamReceiveException: 
> java.lang.RuntimeException: Last written key 
> DecoratedKey(-1000328290821038380) >= current key 
> DecoratedKey(-1055007227842125139)  writing into 
> /home/paulo/.ccm/test/node2/data0/stresscql/typestest-482ac7b09e8d11e787cf85d073c
> 8e037/na-1-big-Data.db
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:63)
>  ~[main/:na]
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:41)
>  ~[main/:na]
> at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:55)
>  ~[main/:na]
> at 
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:178)
>  ~[main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> {noformat}
> Reproduction steps:
>  * Create CCM cluster with 2 nodes
> * Start only first node, disable hinted handoff
>  * Run stress with the attached yaml: {{tools/bin/cassandra-stress "user 
> profile=largepartition.yaml n=10K ops(insert=1) no-warmup -node whitelist 
> 127.0.0.1 -mode native cql3 compression=lz4 -rate threads=4 -insert 
> visits=FIXED(100K) revisit=FIXED(100K)"}}
> * Start second node, run repair on {{stresscql}} table - the exception above 
> will be thrown.
> I investigated briefly and haven't found anything suspicious. This seems to 
> be related to CASSANDRA-12229 as I tested the steps above in a branch without 
> that and the repair completed successfully. I haven't tested with a smaller 
> number of rows per partition to see at which point it starts to be a problem.
> We should probably add a regression dtest to stream large partitions to catch 
> similar problems in the future.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13899) Streaming of compressed partition fails

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-13899:

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

Holy crap - I didn't know you were vacationing. Sorry about that, but thanks 
soo much for the review!!

committed as sha {{d080a73723d9aa402507c1ae04eef92ff6d44948}} to the cassandra 
repo, and as sha {{6ea3964d18b54b4e23b6e7ebf63ca42080e8404b}} to the dtests 
repo.

> Streaming of compressed partition fails 
> 
>
> Key: CASSANDRA-13899
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13899
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Paulo Motta
>Assignee: Jason Brown
> Fix For: 4.0
>
> Attachments: largepartition.yaml
>
>
> Streaming a single partition with ~100K rows fails with the following 
> exception:
> {noformat}
> ERROR [Stream-Deserializer-/127.0.0.1:35149-a92e5e12] 2017-09-21 04:03:41,237 
> StreamSession.java:617 - [Stream #c2e5b640-9eab-11e7-99c0-e9864ca8da8e] 
> Streaming error occurred on session with peer 127.0.0.1
> org.apache.cassandra.streaming.StreamReceiveException: 
> java.lang.RuntimeException: Last written key 
> DecoratedKey(-1000328290821038380) >= current key 
> DecoratedKey(-1055007227842125139)  writing into 
> /home/paulo/.ccm/test/node2/data0/stresscql/typestest-482ac7b09e8d11e787cf85d073c
> 8e037/na-1-big-Data.db
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:63)
>  ~[main/:na]
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:41)
>  ~[main/:na]
> at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:55)
>  ~[main/:na]
> at 
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:178)
>  ~[main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> {noformat}
> Reproduction steps:
>  * Create CCM cluster with 2 nodes
> * Start only first node, disable hinted handoff
>  * Run stress with the attached yaml: {{tools/bin/cassandra-stress "user 
> profile=largepartition.yaml n=10K ops(insert=1) no-warmup -node whitelist 
> 127.0.0.1 -mode native cql3 compression=lz4 -rate threads=4 -insert 
> visits=FIXED(100K) revisit=FIXED(100K)"}}
> * Start second node, run repair on {{stresscql}} table - the exception above 
> will be thrown.
> I investigated briefly and haven't found anything suspicious. This seems to 
> be related to CASSANDRA-12229 as I tested the steps above in a branch without 
> that and the repair completed successfully. I haven't tested with a smaller 
> number of rows per partition to see at which point it starts to be a problem.
> We should probably add a regression dtest to stream large partitions to catch 
> similar problems in the future.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

cassandra-dtest git commit: Add dtest for repairing wide rows

[jasobrown]

Repository: cassandra-dtest
Updated Branches:
  refs/heads/master b0f34e3a6 -> 6ea3964d1


Add dtest for repairing wide rows

patch by jasobrown, reviewed by Paulo Motta for CASSANDRA-13899


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

Branch: refs/heads/master
Commit: 6ea3964d18b54b4e23b6e7ebf63ca42080e8404b
Parents: b0f34e3
Author: Jason Brown 
Authored: Thu Sep 28 06:39:24 2017 -0700
Committer: Jason Brown 
Committed: Wed Oct 4 16:03:38 2017 +0900

--
 repair_tests/repair_test.py   | 20 +++
 stress_profiles/repair_wide_rows.yaml | 54 ++
 2 files changed, 74 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/6ea3964d/repair_tests/repair_test.py
--
diff --git a/repair_tests/repair_test.py b/repair_tests/repair_test.py
index ad46d18..1d5bf8f 100644
--- a/repair_tests/repair_test.py
+++ b/repair_tests/repair_test.py
@@ -1,3 +1,5 @@
+import os
+import os.path
 import threading
 import time
 import re
@@ -1061,6 +1063,24 @@ class TestRepair(BaseRepairTest):
 _, _, rc = node2.stress(['read', 'n=1M', 'no-warmup', '-rate', 
'threads=30'], whitelist=True)
 self.assertEqual(rc, 0)
 
+@since('4.0')
+def test_wide_row_repair(self):
+"""
+@jira_ticket CASSANDRA-13899
+Make sure compressed vs uncompressed blocks are handled correctly when 
stream decompressing
+"""
+cluster = self.cluster
+cluster.set_configuration_options(values={'hinted_handoff_enabled': 
False})
+cluster.populate(2).start(wait_for_binary_proto=True)
+node1, node2 = cluster.nodelist()
+node2.stop(wait_other_notice=True)
+profile_path = os.path.join(os.getcwd(), 
'stress_profiles/repair_wide_rows.yaml')
+print("yaml = " + profile_path)
+node1.stress(['user', 'profile=' + profile_path, 'n=50', 
'ops(insert=1)', 'no-warmup', '-rate', 'threads=8',
+  '-insert', 'visits=FIXED(100K)', 'revisit=FIXED(100K)'])
+node2.start(wait_for_binary_proto=True)
+node2.repair()
+
 def test_dead_coordinator(self):
 """
 @jira_ticket CASSANDRA-11824

http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/6ea3964d/stress_profiles/repair_wide_rows.yaml
--
diff --git a/stress_profiles/repair_wide_rows.yaml 
b/stress_profiles/repair_wide_rows.yaml
new file mode 100644
index 000..87f46f0
--- /dev/null
+++ b/stress_profiles/repair_wide_rows.yaml
@@ -0,0 +1,54 @@
+keyspace: stresscql
+keyspace_definition: |
+  CREATE KEYSPACE stresscql WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': 2};
+
+table: typestest
+table_definition: |
+  CREATE TABLE typestest (
+key text,
+col1 text,
+val blob,
+PRIMARY KEY(key, col1)
+  ) 
+WITH compaction = { 'class':'LeveledCompactionStrategy' }
+AND compression = {'chunk_length_in_kb': '1', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'};
+
+#
+# Optional meta information on the generated columns in the above table
+# The min and max only apply to text and blob types
+# The distribution field represents the total unique population
+# distribution of that column across rows.  Supported types are
+# 
+#  EXP(min..max)An exponential distribution over 
the range [min..max]
+#  EXTREME(min..max,shape)  An extreme value (Weibull) 
distribution over the range [min..max]
+#  GAUSSIAN(min..max,stdvrng)   A gaussian/normal distribution, 
where mean=(min+max)/2, and stdev is (mean-min)/stdvrng
+#  GAUSSIAN(min..max,mean,stdev)A gaussian/normal distribution, 
with explicitly defined mean and stdev
+#  UNIFORM(min..max)A uniform distribution over the 
range [min, max]
+#  FIXED(val)   A fixed distribution, always 
returning the same value
+#  SEQ(min..max)A fixed sequence, returning values 
in the range min to max sequentially (starting based on seed), wrapping if 
necessary.
+#  Aliases: extr, gauss, normal, norm, weibull
+#
+#  If preceded by ~, the distribution is inverted
+#
+# Defaults for all columns are size: uniform(4..8), population: 
uniform(1..100B), cluster: fixed(1)
+#
+columnspec:
+  - name: key
+size: fixed(10)
+population: fixed(1) # the range of unique values to select for the 
field (default 

cassandra git commit: Fix buffer length comparison when decompressing in netty-based streaming

[jasobrown]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 0cb27a781 -> d080a7372


Fix buffer length comparison when decompressing in netty-based streaming

patch by jasobrown; reviewed by Paulo Motta for CASSANDRA-13899


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

Branch: refs/heads/trunk
Commit: d080a73723d9aa402507c1ae04eef92ff6d44948
Parents: 0cb27a7
Author: Jason Brown 
Authored: Tue Sep 26 13:30:17 2017 -0700
Committer: Jason Brown 
Committed: Wed Oct 4 15:56:59 2017 +0900

--
 CHANGES.txt| 1 +
 .../cassandra/streaming/compress/CompressedInputStream.java| 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d080a737/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index b146778..635c2f4 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0
+ * Fix buffer length comparison when decompressing in netty-based streaming 
(CASSANDRA-13899)
  * Properly close StreamCompressionInputStream to release any ByteBuf 
(CASSANDRA-13906)
  * Add SERIAL and LOCAL_SERIAL support for cassandra-stress (CASSANDRA-13925)
  * LCS needlessly checks for L0 STCS candidates multiple times 
(CASSANDRA-12961)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d080a737/src/java/org/apache/cassandra/streaming/compress/CompressedInputStream.java
--
diff --git 
a/src/java/org/apache/cassandra/streaming/compress/CompressedInputStream.java 
b/src/java/org/apache/cassandra/streaming/compress/CompressedInputStream.java
index 4b9fc61..dd0ba80 100644
--- 
a/src/java/org/apache/cassandra/streaming/compress/CompressedInputStream.java
+++ 
b/src/java/org/apache/cassandra/streaming/compress/CompressedInputStream.java
@@ -151,13 +151,12 @@ public class CompressedInputStream extends 
RebufferingInputStream implements Aut
 
 private void decompress(ByteBuffer compressed) throws IOException
 {
-final int compressedChunkLength = info.parameters.chunkLength();
 int length = compressed.remaining();
 
-// uncompress if the buffer size is less than chunk size. else, if the 
buffer size is equal to the compressedChunkLength,
+// uncompress if the buffer size is less than the max chunk size. 
else, if the buffer size is greater than or equal to the maxCompressedLength,
 // we assume the buffer is not compressed. see CASSANDRA-10520
 final boolean releaseCompressedBuffer;
-if (length - CHECKSUM_LENGTH < compressedChunkLength)
+if (length - CHECKSUM_LENGTH < info.parameters.maxCompressedLength())
 {
 buffer.clear();
 compressed.limit(length - CHECKSUM_LENGTH);
@@ -191,6 +190,7 @@ public class CompressedInputStream extends 
RebufferingInputStream implements Aut
 FileUtils.clean(compressed);
 
 // buffer offset is always aligned
+final int compressedChunkLength = info.parameters.chunkLength();
 bufferOffset = current & ~(compressedChunkLength - 1);
 }
 


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13922) nodetool verify should also verify sstable metadata

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-13922:
-

Committed, thanks, opted not to fix the mutateRepairedAt change as it felt a 
tiny bit more non-nit:y, created CASSANDRA-13933

> nodetool verify should also verify sstable metadata
> ---
>
> Key: CASSANDRA-13922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13922
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 4.0, 3.0.16, 3.11.2
>
>
> nodetool verify should also try to deserialize the sstable metadata (and once 
> CASSANDRA-13321 makes it in, verify the checksums)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-13933) Handle mutateRepaired failure in nodetool verify

[Marcus Eriksson (JIRA)]

Marcus Eriksson created CASSANDRA-13933:
---

 Summary: Handle mutateRepaired failure in nodetool verify
 Key: CASSANDRA-13933
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13933
 Project: Cassandra
  Issue Type: Bug
Reporter: Marcus Eriksson


See comment here: 
https://issues.apache.org/jira/browse/CASSANDRA-13922?focusedCommentId=16189875=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16189875



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

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

[marcuse]

Merge branch 'cassandra-3.11' into trunk


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

Branch: refs/heads/trunk
Commit: 0cb27a781ef74f66788e98624313e7750b183c59
Parents: 8ebef8e 12a09ec
Author: Marcus Eriksson 
Authored: Wed Oct 4 08:27:19 2017 +0200
Committer: Marcus Eriksson 
Committed: Wed Oct 4 08:27:19 2017 +0200

--
 CHANGES.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0cb27a78/CHANGES.txt
--
diff --cc CHANGES.txt
index 134ec2e,e231bf2..b146778
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,150 -1,8 +1,155 @@@
 +4.0
 + * Properly close StreamCompressionInputStream to release any ByteBuf 
(CASSANDRA-13906)
 + * Add SERIAL and LOCAL_SERIAL support for cassandra-stress (CASSANDRA-13925)
 + * LCS needlessly checks for L0 STCS candidates multiple times 
(CASSANDRA-12961)
 + * Correctly close netty channels when a stream session ends (CASSANDRA-13905)
 + * Update lz4 to 1.4.0 (CASSANDRA-13741)
 + * Optimize Paxos prepare and propose stage for local requests 
(CASSANDRA-13862)
 + * Throttle base partitions during MV repair streaming to prevent OOM 
(CASSANDRA-13299)
 + * Use compaction threshold for STCS in L0 (CASSANDRA-13861)
 + * Fix problem with min_compress_ratio: 1 and disallow ratio < 1 
(CASSANDRA-13703)
 + * Add extra information to SASI timeout exception (CASSANDRA-13677)
 + * Add incremental repair support for --hosts, --force, and subrange repair 
(CASSANDRA-13818)
 + * Rework CompactionStrategyManager.getScanners synchronization 
(CASSANDRA-13786)
 + * Add additional unit tests for batch behavior, TTLs, Timestamps 
(CASSANDRA-13846)
 + * Add keyspace and table name in schema validation exception 
(CASSANDRA-13845)
 + * Emit metrics whenever we hit tombstone failures and warn thresholds 
(CASSANDRA-13771)
 + * Make netty EventLoopGroups daemon threads (CASSANDRA-13837)
 + * Race condition when closing stream sessions (CASSANDRA-13852)
 + * NettyFactoryTest is failing in trunk on macOS (CASSANDRA-13831)
 + * Allow changing log levels via nodetool for related classes 
(CASSANDRA-12696)
 + * Add stress profile yaml with LWT (CASSANDRA-7960)
 + * Reduce memory copies and object creations when acting on ByteBufs 
(CASSANDRA-13789)
 + * Simplify mx4j configuration (Cassandra-13578)
 + * Fix trigger example on 4.0 (CASSANDRA-13796)
 + * Force minumum timeout value (CASSANDRA-9375)
 + * Use netty for streaming (CASSANDRA-12229)
 + * Use netty for internode messaging (CASSANDRA-8457)
 + * Add bytes repaired/unrepaired to nodetool tablestats (CASSANDRA-13774)
 + * Don't delete incremental repair sessions if they still have sstables 
(CASSANDRA-13758)
 + * Fix pending repair manager index out of bounds check (CASSANDRA-13769)
 + * Don't use RangeFetchMapCalculator when RF=1 (CASSANDRA-13576)
 + * Don't optimise trivial ranges in RangeFetchMapCalculator (CASSANDRA-13664)
 + * Use an ExecutorService for repair commands instead of new 
Thread(..).start() (CASSANDRA-13594)
 + * Fix race / ref leak in anticompaction (CASSANDRA-13688)
 + * Expose tasks queue length via JMX (CASSANDRA-12758)
 + * Fix race / ref leak in PendingRepairManager (CASSANDRA-13751)
 + * Enable ppc64le runtime as unsupported architecture (CASSANDRA-13615)
 + * Improve sstablemetadata output (CASSANDRA-11483)
 + * Support for migrating legacy users to roles has been dropped 
(CASSANDRA-13371)
 + * Introduce error metrics for repair (CASSANDRA-13387)
 + * Refactoring to primitive functional interfaces in AuthCache 
(CASSANDRA-13732)
 + * Update metrics to 3.1.5 (CASSANDRA-13648)
 + * batch_size_warn_threshold_in_kb can now be set at runtime (CASSANDRA-13699)
 + * Avoid always rebuilding secondary indexes at startup (CASSANDRA-13725)
 + * Upgrade JMH from 1.13 to 1.19 (CASSANDRA-13727)
 + * Upgrade SLF4J from 1.7.7 to 1.7.25 (CASSANDRA-12996)
 + * Default for start_native_transport now true if not set in config 
(CASSANDRA-13656)
 + * Don't add localhost to the graph when calculating where to stream from 
(CASSANDRA-13583)
 + * Make CDC availability more deterministic via hard-linking (CASSANDRA-12148)
 + * Allow skipping equality-restricted clustering columns in ORDER BY clause 
(CASSANDRA-10271)
 + * Use common nowInSec for validation compactions (CASSANDRA-13671)
 + * Improve handling of IR prepare failures (CASSANDRA-13672)
 + * Send IR coordinator messages synchronously (CASSANDRA-13673)
 + * Flush system.repair table before IR finalize promise (CASSANDRA-13660)
 + * Fix column filter creation for 

[2/3] cassandra git commit: fixup CHANGES.txt

[marcuse]

fixup CHANGES.txt


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

Branch: refs/heads/trunk
Commit: 12a09ec3f2028fa8e9182e027afb8bf96613721a
Parents: f5bc429
Author: Marcus Eriksson 
Authored: Wed Oct 4 08:24:47 2017 +0200
Committer: Marcus Eriksson 
Committed: Wed Oct 4 08:24:47 2017 +0200

--
 CHANGES.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/12a09ec3/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 4a22af4..e231bf2 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,8 @@
+3.11.2
+Merged from 3.0:
+ * Deserialise sstable metadata in nodetool verify (CASSANDRA-13922)
+
+
 3.11.1
  * Fix the computation of cdc_total_space_in_mb for exabyte filesystems 
(CASSANDRA-13808)
  * AbstractTokenTreeBuilder#serializedSize returns wrong value when there is a 
single leaf and overflow collisions (CASSANDRA-13869)
@@ -12,7 +17,6 @@
  * Duplicate the buffer before passing it to analyser in SASI operation 
(CASSANDRA-13512)
  * Properly evict pstmts from prepared statements cache (CASSANDRA-13641)
 Merged from 3.0:
- * Deserialise sstable metadata in nodetool verify (CASSANDRA-13922)
  * Improve TRUNCATE performance (CASSANDRA-13909)
  * Implement short read protection on partition boundaries (CASSANDRA-13595)
  * Fix ISE thrown by UPI.Serializer.hasNext() for some SELECT queries 
(CASSANDRA-13911)


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[1/3] cassandra git commit: fixup CHANGES.txt

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.11 f5bc42996 -> 12a09ec3f
  refs/heads/trunk 8ebef8e71 -> 0cb27a781


fixup CHANGES.txt


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

Branch: refs/heads/cassandra-3.11
Commit: 12a09ec3f2028fa8e9182e027afb8bf96613721a
Parents: f5bc429
Author: Marcus Eriksson 
Authored: Wed Oct 4 08:24:47 2017 +0200
Committer: Marcus Eriksson 
Committed: Wed Oct 4 08:24:47 2017 +0200

--
 CHANGES.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/12a09ec3/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 4a22af4..e231bf2 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,8 @@
+3.11.2
+Merged from 3.0:
+ * Deserialise sstable metadata in nodetool verify (CASSANDRA-13922)
+
+
 3.11.1
  * Fix the computation of cdc_total_space_in_mb for exabyte filesystems 
(CASSANDRA-13808)
  * AbstractTokenTreeBuilder#serializedSize returns wrong value when there is a 
single leaf and overflow collisions (CASSANDRA-13869)
@@ -12,7 +17,6 @@
  * Duplicate the buffer before passing it to analyser in SASI operation 
(CASSANDRA-13512)
  * Properly evict pstmts from prepared statements cache (CASSANDRA-13641)
 Merged from 3.0:
- * Deserialise sstable metadata in nodetool verify (CASSANDRA-13922)
  * Improve TRUNCATE performance (CASSANDRA-13909)
  * Implement short read protection on partition boundaries (CASSANDRA-13595)
  * Fix ISE thrown by UPI.Serializer.hasNext() for some SELECT queries 
(CASSANDRA-13911)


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13922) nodetool verify should also verify sstable metadata

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-13922:

Fix Version/s: 4.0

> nodetool verify should also verify sstable metadata
> ---
>
> Key: CASSANDRA-13922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13922
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 4.0, 3.0.16, 3.11.2
>
>
> nodetool verify should also try to deserialize the sstable metadata (and once 
> CASSANDRA-13321 makes it in, verify the checksums)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13922) nodetool verify should also verify sstable metadata

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-13922:

   Resolution: Fixed
Fix Version/s: (was: 3.11.x)
   (was: 4.x)
   (was: 3.0.x)
   3.11.2
   3.0.16
   Status: Resolved  (was: Ready to Commit)

> nodetool verify should also verify sstable metadata
> ---
>
> Key: CASSANDRA-13922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13922
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 3.0.16, 3.11.2
>
>
> nodetool verify should also try to deserialize the sstable metadata (and once 
> CASSANDRA-13321 makes it in, verify the checksums)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

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

[marcuse]

Merge branch 'cassandra-3.11' into trunk


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

Branch: refs/heads/trunk
Commit: 8ebef8e71a5ded0d5964e1ae315c9875db2e005f
Parents: 982ab93 f5bc429
Author: Marcus Eriksson 
Authored: Wed Oct 4 08:20:54 2017 +0200
Committer: Marcus Eriksson 
Committed: Wed Oct 4 08:20:54 2017 +0200

--
 CHANGES.txt |  1 +
 .../cassandra/db/compaction/Verifier.java   | 31 
 .../org/apache/cassandra/db/VerifyTest.java | 25 
 3 files changed, 52 insertions(+), 5 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8ebef8e7/src/java/org/apache/cassandra/db/compaction/Verifier.java
--
diff --cc src/java/org/apache/cassandra/db/compaction/Verifier.java
index bca6e79,4c07bb6..22cf813
--- a/src/java/org/apache/cassandra/db/compaction/Verifier.java
+++ b/src/java/org/apache/cassandra/db/compaction/Verifier.java
@@@ -234,8 -250,14 +249,14 @@@ public class Verifier implements Closea
  
  private void markAndThrow() throws IOException
  {
- 
sstable.descriptor.getMetadataSerializer().mutateRepaired(sstable.descriptor, 
ActiveRepairService.UNREPAIRED_SSTABLE, 
sstable.getSSTableMetadata().pendingRepair);
- throw new CorruptSSTableException(new 
Exception(String.format("Invalid SSTable %s, please force repair", 
sstable.getFilename())), sstable.getFilename());
+ markAndThrow(true);
+ }
+ 
+ private void markAndThrow(boolean mutateRepaired) throws IOException
+ {
+ if (mutateRepaired) // if we are able to mutate repaired flag, an 
incremental repair should be enough
 -
sstable.descriptor.getMetadataSerializer().mutateRepairedAt(sstable.descriptor, 
ActiveRepairService.UNREPAIRED_SSTABLE);
++
sstable.descriptor.getMetadataSerializer().mutateRepaired(sstable.descriptor, 
ActiveRepairService.UNREPAIRED_SSTABLE, 
sstable.getSSTableMetadata().pendingRepair);
+ throw new CorruptSSTableException(new 
Exception(String.format("Invalid SSTable %s, please force %srepair", 
sstable.getFilename(), mutateRepaired ? "" : "a full ")), 
sstable.getFilename());
  }
  
  public CompactionInfo.Holder getVerifyInfo()

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8ebef8e7/test/unit/org/apache/cassandra/db/VerifyTest.java
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

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

[marcuse]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/trunk
Commit: f5bc42996b671ae26793691af3fd06fbcabbe4cc
Parents: 983c72a e400b97
Author: Marcus Eriksson 
Authored: Wed Oct 4 08:18:36 2017 +0200
Committer: Marcus Eriksson 
Committed: Wed Oct 4 08:19:15 2017 +0200

--
 CHANGES.txt |  1 +
 .../cassandra/db/compaction/Verifier.java   | 31 
 .../org/apache/cassandra/db/VerifyTest.java | 26 
 3 files changed, 53 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f5bc4299/CHANGES.txt
--
diff --cc CHANGES.txt
index aca219e,df05f7f..4a22af4
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,17 -1,8 +1,18 @@@
 -3.0.16
 -  * Deserialise sstable metadata in nodetool verify (CASSANDRA-13922)
 -
 -
 -3.0.15
 +3.11.1
 + * Fix the computation of cdc_total_space_in_mb for exabyte filesystems 
(CASSANDRA-13808)
 + * AbstractTokenTreeBuilder#serializedSize returns wrong value when there is 
a single leaf and overflow collisions (CASSANDRA-13869)
 + * Add a compaction option to TWCS to ignore sstables overlapping checks 
(CASSANDRA-13418)
 + * BTree.Builder memory leak (CASSANDRA-13754)
 + * Revert CASSANDRA-10368 of supporting non-pk column filtering due to 
correctness (CASSANDRA-13798)
 + * Add a skip read validation flag to cassandra-stress (CASSANDRA-13772)
 + * Fix cassandra-stress hang issues when an error during cluster connection 
happens (CASSANDRA-12938)
 + * Better bootstrap failure message when blocked by (potential) range 
movement (CASSANDRA-13744)
 + * "ignore" option is ignored in sstableloader (CASSANDRA-13721)
 + * Deadlock in AbstractCommitLogSegmentManager (CASSANDRA-13652)
 + * Duplicate the buffer before passing it to analyser in SASI operation 
(CASSANDRA-13512)
 + * Properly evict pstmts from prepared statements cache (CASSANDRA-13641)
 +Merged from 3.0:
++ * Deserialise sstable metadata in nodetool verify (CASSANDRA-13922)
   * Improve TRUNCATE performance (CASSANDRA-13909)
   * Implement short read protection on partition boundaries (CASSANDRA-13595)
   * Fix ISE thrown by UPI.Serializer.hasNext() for some SELECT queries 
(CASSANDRA-13911)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f5bc4299/src/java/org/apache/cassandra/db/compaction/Verifier.java
--
diff --cc src/java/org/apache/cassandra/db/compaction/Verifier.java
index df659e4,68088b3..4c07bb6
--- a/src/java/org/apache/cassandra/db/compaction/Verifier.java
+++ b/src/java/org/apache/cassandra/db/compaction/Verifier.java
@@@ -88,7 -89,21 +90,21 @@@ public class Verifier implements Closea
  {
  long rowStart = 0;
  
 -outputHandler.output(String.format("Verifying %s (%s bytes)", 
sstable, dataFile.length()));
 +outputHandler.output(String.format("Verifying %s (%s)", sstable, 
FBUtilities.prettyPrintMemory(dataFile.length(;
+ outputHandler.output(String.format("Deserializing sstable metadata 
for %s ", sstable));
+ try
+ {
+ EnumSet types = EnumSet.of(MetadataType.VALIDATION, 
MetadataType.STATS, MetadataType.HEADER);
+ Map sstableMetadata = 
sstable.descriptor.getMetadataSerializer().deserialize(sstable.descriptor, 
types);
+ if (sstableMetadata.containsKey(MetadataType.VALIDATION) &&
+ 
!((ValidationMetadata)sstableMetadata.get(MetadataType.VALIDATION)).partitioner.equals(sstable.getPartitioner().getClass().getCanonicalName()))
+ throw new IOException("Partitioner does not match validation 
metadata");
+ }
+ catch (Throwable t)
+ {
+ outputHandler.debug(t.getMessage());
+ markAndThrow(false);
+ }
  outputHandler.output(String.format("Checking computed hash of %s ", 
sstable));
  
  
@@@ -187,8 -202,8 +203,8 @@@
  if (key == null || dataSize > dataFile.length())
  markAndThrow();
  
- //mimic the scrub read path
+ //mimic the scrub read path, intentionally unused
 -try (UnfilteredRowIterator iterator = new 
SSTableIdentityIterator(sstable, dataFile, key))
 +try (UnfilteredRowIterator iterator = 
SSTableIdentityIterator.create(sstable, dataFile, key))
  {

[3/6] cassandra git commit: Deserialize sstable metadata in nodetool verify

[marcuse]

Deserialize sstable metadata in nodetool verify

Patch by marcuse; reviewed by Jason Brown for CASSANDRA-13922


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

Branch: refs/heads/trunk
Commit: e400b976751110d41405bac614189152bf88f7ef
Parents: b32a9e6
Author: Marcus Eriksson 
Authored: Mon Oct 2 10:11:17 2017 +0200
Committer: Marcus Eriksson 
Committed: Wed Oct 4 08:15:23 2017 +0200

--
 CHANGES.txt |  4 +++
 .../cassandra/db/compaction/Verifier.java   | 32 
 .../org/apache/cassandra/db/VerifyTest.java | 25 +++
 3 files changed, 55 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e400b976/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d6423b4..df05f7f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,7 @@
+3.0.16
+  * Deserialise sstable metadata in nodetool verify (CASSANDRA-13922)
+
+
 3.0.15
  * Improve TRUNCATE performance (CASSANDRA-13909)
  * Implement short read protection on partition boundaries (CASSANDRA-13595)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e400b976/src/java/org/apache/cassandra/db/compaction/Verifier.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/Verifier.java 
b/src/java/org/apache/cassandra/db/compaction/Verifier.java
index 88bc3a7..68088b3 100644
--- a/src/java/org/apache/cassandra/db/compaction/Verifier.java
+++ b/src/java/org/apache/cassandra/db/compaction/Verifier.java
@@ -26,13 +26,15 @@ import org.apache.cassandra.io.sstable.Component;
 import org.apache.cassandra.io.sstable.CorruptSSTableException;
 import org.apache.cassandra.io.sstable.SSTableIdentityIterator;
 import org.apache.cassandra.io.sstable.format.SSTableReader;
+import org.apache.cassandra.io.sstable.metadata.MetadataComponent;
+import org.apache.cassandra.io.sstable.metadata.MetadataType;
+import org.apache.cassandra.io.sstable.metadata.ValidationMetadata;
 import org.apache.cassandra.io.util.DataIntegrityMetadata;
 import org.apache.cassandra.io.util.DataIntegrityMetadata.FileDigestValidator;
 import org.apache.cassandra.io.util.FileUtils;
 import org.apache.cassandra.io.util.RandomAccessReader;
 import org.apache.cassandra.service.ActiveRepairService;
 import org.apache.cassandra.utils.ByteBufferUtil;
-import org.apache.cassandra.utils.FBUtilities;
 import org.apache.cassandra.utils.OutputHandler;
 import org.apache.cassandra.utils.UUIDGen;
 
@@ -58,7 +60,6 @@ public class Verifier implements Closeable
 private final RowIndexEntry.IndexSerializer rowIndexEntrySerializer;
 
 private int goodRows;
-private int badRows;
 
 private final OutputHandler outputHandler;
 private FileDigestValidator validator;
@@ -89,6 +90,20 @@ public class Verifier implements Closeable
 long rowStart = 0;
 
 outputHandler.output(String.format("Verifying %s (%s bytes)", sstable, 
dataFile.length()));
+outputHandler.output(String.format("Deserializing sstable metadata for 
%s ", sstable));
+try
+{
+EnumSet types = EnumSet.of(MetadataType.VALIDATION, 
MetadataType.STATS, MetadataType.HEADER);
+Map sstableMetadata = 
sstable.descriptor.getMetadataSerializer().deserialize(sstable.descriptor, 
types);
+if (sstableMetadata.containsKey(MetadataType.VALIDATION) &&
+
!((ValidationMetadata)sstableMetadata.get(MetadataType.VALIDATION)).partitioner.equals(sstable.getPartitioner().getClass().getCanonicalName()))
+throw new IOException("Partitioner does not match validation 
metadata");
+}
+catch (Throwable t)
+{
+outputHandler.debug(t.getMessage());
+markAndThrow(false);
+}
 outputHandler.output(String.format("Checking computed hash of %s ", 
sstable));
 
 
@@ -187,7 +202,7 @@ public class Verifier implements Closeable
 if (key == null || dataSize > dataFile.length())
 markAndThrow();
 
-//mimic the scrub read path
+//mimic the scrub read path, intentionally unused
 try (UnfilteredRowIterator iterator = new 
SSTableIdentityIterator(sstable, dataFile, key))
 {
 }
@@ -204,7 +219,6 @@ public class Verifier implements Closeable
 }
 catch (Throwable th)

[1/6] cassandra git commit: Deserialize sstable metadata in nodetool verify

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 b32a9e645 -> e400b9767
  refs/heads/cassandra-3.11 983c72a84 -> f5bc42996
  refs/heads/trunk 982ab93a2 -> 8ebef8e71


Deserialize sstable metadata in nodetool verify

Patch by marcuse; reviewed by Jason Brown for CASSANDRA-13922


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

Branch: refs/heads/cassandra-3.0
Commit: e400b976751110d41405bac614189152bf88f7ef
Parents: b32a9e6
Author: Marcus Eriksson 
Authored: Mon Oct 2 10:11:17 2017 +0200
Committer: Marcus Eriksson 
Committed: Wed Oct 4 08:15:23 2017 +0200

--
 CHANGES.txt |  4 +++
 .../cassandra/db/compaction/Verifier.java   | 32 
 .../org/apache/cassandra/db/VerifyTest.java | 25 +++
 3 files changed, 55 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e400b976/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d6423b4..df05f7f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,7 @@
+3.0.16
+  * Deserialise sstable metadata in nodetool verify (CASSANDRA-13922)
+
+
 3.0.15
  * Improve TRUNCATE performance (CASSANDRA-13909)
  * Implement short read protection on partition boundaries (CASSANDRA-13595)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e400b976/src/java/org/apache/cassandra/db/compaction/Verifier.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/Verifier.java 
b/src/java/org/apache/cassandra/db/compaction/Verifier.java
index 88bc3a7..68088b3 100644
--- a/src/java/org/apache/cassandra/db/compaction/Verifier.java
+++ b/src/java/org/apache/cassandra/db/compaction/Verifier.java
@@ -26,13 +26,15 @@ import org.apache.cassandra.io.sstable.Component;
 import org.apache.cassandra.io.sstable.CorruptSSTableException;
 import org.apache.cassandra.io.sstable.SSTableIdentityIterator;
 import org.apache.cassandra.io.sstable.format.SSTableReader;
+import org.apache.cassandra.io.sstable.metadata.MetadataComponent;
+import org.apache.cassandra.io.sstable.metadata.MetadataType;
+import org.apache.cassandra.io.sstable.metadata.ValidationMetadata;
 import org.apache.cassandra.io.util.DataIntegrityMetadata;
 import org.apache.cassandra.io.util.DataIntegrityMetadata.FileDigestValidator;
 import org.apache.cassandra.io.util.FileUtils;
 import org.apache.cassandra.io.util.RandomAccessReader;
 import org.apache.cassandra.service.ActiveRepairService;
 import org.apache.cassandra.utils.ByteBufferUtil;
-import org.apache.cassandra.utils.FBUtilities;
 import org.apache.cassandra.utils.OutputHandler;
 import org.apache.cassandra.utils.UUIDGen;
 
@@ -58,7 +60,6 @@ public class Verifier implements Closeable
 private final RowIndexEntry.IndexSerializer rowIndexEntrySerializer;
 
 private int goodRows;
-private int badRows;
 
 private final OutputHandler outputHandler;
 private FileDigestValidator validator;
@@ -89,6 +90,20 @@ public class Verifier implements Closeable
 long rowStart = 0;
 
 outputHandler.output(String.format("Verifying %s (%s bytes)", sstable, 
dataFile.length()));
+outputHandler.output(String.format("Deserializing sstable metadata for 
%s ", sstable));
+try
+{
+EnumSet types = EnumSet.of(MetadataType.VALIDATION, 
MetadataType.STATS, MetadataType.HEADER);
+Map sstableMetadata = 
sstable.descriptor.getMetadataSerializer().deserialize(sstable.descriptor, 
types);
+if (sstableMetadata.containsKey(MetadataType.VALIDATION) &&
+
!((ValidationMetadata)sstableMetadata.get(MetadataType.VALIDATION)).partitioner.equals(sstable.getPartitioner().getClass().getCanonicalName()))
+throw new IOException("Partitioner does not match validation 
metadata");
+}
+catch (Throwable t)
+{
+outputHandler.debug(t.getMessage());
+markAndThrow(false);
+}
 outputHandler.output(String.format("Checking computed hash of %s ", 
sstable));
 
 
@@ -187,7 +202,7 @@ public class Verifier implements Closeable
 if (key == null || dataSize > dataFile.length())
 markAndThrow();
 
-//mimic the scrub read path
+//mimic the scrub read path, intentionally unused
 try (UnfilteredRowIterator iterator = new 
SSTableIdentityIterator(sstable, 

[2/6] cassandra git commit: Deserialize sstable metadata in nodetool verify

[marcuse]

Deserialize sstable metadata in nodetool verify

Patch by marcuse; reviewed by Jason Brown for CASSANDRA-13922


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

Branch: refs/heads/cassandra-3.11
Commit: e400b976751110d41405bac614189152bf88f7ef
Parents: b32a9e6
Author: Marcus Eriksson 
Authored: Mon Oct 2 10:11:17 2017 +0200
Committer: Marcus Eriksson 
Committed: Wed Oct 4 08:15:23 2017 +0200

--
 CHANGES.txt |  4 +++
 .../cassandra/db/compaction/Verifier.java   | 32 
 .../org/apache/cassandra/db/VerifyTest.java | 25 +++
 3 files changed, 55 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e400b976/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d6423b4..df05f7f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,7 @@
+3.0.16
+  * Deserialise sstable metadata in nodetool verify (CASSANDRA-13922)
+
+
 3.0.15
  * Improve TRUNCATE performance (CASSANDRA-13909)
  * Implement short read protection on partition boundaries (CASSANDRA-13595)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e400b976/src/java/org/apache/cassandra/db/compaction/Verifier.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/Verifier.java 
b/src/java/org/apache/cassandra/db/compaction/Verifier.java
index 88bc3a7..68088b3 100644
--- a/src/java/org/apache/cassandra/db/compaction/Verifier.java
+++ b/src/java/org/apache/cassandra/db/compaction/Verifier.java
@@ -26,13 +26,15 @@ import org.apache.cassandra.io.sstable.Component;
 import org.apache.cassandra.io.sstable.CorruptSSTableException;
 import org.apache.cassandra.io.sstable.SSTableIdentityIterator;
 import org.apache.cassandra.io.sstable.format.SSTableReader;
+import org.apache.cassandra.io.sstable.metadata.MetadataComponent;
+import org.apache.cassandra.io.sstable.metadata.MetadataType;
+import org.apache.cassandra.io.sstable.metadata.ValidationMetadata;
 import org.apache.cassandra.io.util.DataIntegrityMetadata;
 import org.apache.cassandra.io.util.DataIntegrityMetadata.FileDigestValidator;
 import org.apache.cassandra.io.util.FileUtils;
 import org.apache.cassandra.io.util.RandomAccessReader;
 import org.apache.cassandra.service.ActiveRepairService;
 import org.apache.cassandra.utils.ByteBufferUtil;
-import org.apache.cassandra.utils.FBUtilities;
 import org.apache.cassandra.utils.OutputHandler;
 import org.apache.cassandra.utils.UUIDGen;
 
@@ -58,7 +60,6 @@ public class Verifier implements Closeable
 private final RowIndexEntry.IndexSerializer rowIndexEntrySerializer;
 
 private int goodRows;
-private int badRows;
 
 private final OutputHandler outputHandler;
 private FileDigestValidator validator;
@@ -89,6 +90,20 @@ public class Verifier implements Closeable
 long rowStart = 0;
 
 outputHandler.output(String.format("Verifying %s (%s bytes)", sstable, 
dataFile.length()));
+outputHandler.output(String.format("Deserializing sstable metadata for 
%s ", sstable));
+try
+{
+EnumSet types = EnumSet.of(MetadataType.VALIDATION, 
MetadataType.STATS, MetadataType.HEADER);
+Map sstableMetadata = 
sstable.descriptor.getMetadataSerializer().deserialize(sstable.descriptor, 
types);
+if (sstableMetadata.containsKey(MetadataType.VALIDATION) &&
+
!((ValidationMetadata)sstableMetadata.get(MetadataType.VALIDATION)).partitioner.equals(sstable.getPartitioner().getClass().getCanonicalName()))
+throw new IOException("Partitioner does not match validation 
metadata");
+}
+catch (Throwable t)
+{
+outputHandler.debug(t.getMessage());
+markAndThrow(false);
+}
 outputHandler.output(String.format("Checking computed hash of %s ", 
sstable));
 
 
@@ -187,7 +202,7 @@ public class Verifier implements Closeable
 if (key == null || dataSize > dataFile.length())
 markAndThrow();
 
-//mimic the scrub read path
+//mimic the scrub read path, intentionally unused
 try (UnfilteredRowIterator iterator = new 
SSTableIdentityIterator(sstable, dataFile, key))
 {
 }
@@ -204,7 +219,6 @@ public class Verifier implements Closeable
 }
 catch (Throwable th)
   

[5/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[marcuse]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/cassandra-3.11
Commit: f5bc42996b671ae26793691af3fd06fbcabbe4cc
Parents: 983c72a e400b97
Author: Marcus Eriksson 
Authored: Wed Oct 4 08:18:36 2017 +0200
Committer: Marcus Eriksson 
Committed: Wed Oct 4 08:19:15 2017 +0200

--
 CHANGES.txt |  1 +
 .../cassandra/db/compaction/Verifier.java   | 31 
 .../org/apache/cassandra/db/VerifyTest.java | 26 
 3 files changed, 53 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f5bc4299/CHANGES.txt
--
diff --cc CHANGES.txt
index aca219e,df05f7f..4a22af4
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,17 -1,8 +1,18 @@@
 -3.0.16
 -  * Deserialise sstable metadata in nodetool verify (CASSANDRA-13922)
 -
 -
 -3.0.15
 +3.11.1
 + * Fix the computation of cdc_total_space_in_mb for exabyte filesystems 
(CASSANDRA-13808)
 + * AbstractTokenTreeBuilder#serializedSize returns wrong value when there is 
a single leaf and overflow collisions (CASSANDRA-13869)
 + * Add a compaction option to TWCS to ignore sstables overlapping checks 
(CASSANDRA-13418)
 + * BTree.Builder memory leak (CASSANDRA-13754)
 + * Revert CASSANDRA-10368 of supporting non-pk column filtering due to 
correctness (CASSANDRA-13798)
 + * Add a skip read validation flag to cassandra-stress (CASSANDRA-13772)
 + * Fix cassandra-stress hang issues when an error during cluster connection 
happens (CASSANDRA-12938)
 + * Better bootstrap failure message when blocked by (potential) range 
movement (CASSANDRA-13744)
 + * "ignore" option is ignored in sstableloader (CASSANDRA-13721)
 + * Deadlock in AbstractCommitLogSegmentManager (CASSANDRA-13652)
 + * Duplicate the buffer before passing it to analyser in SASI operation 
(CASSANDRA-13512)
 + * Properly evict pstmts from prepared statements cache (CASSANDRA-13641)
 +Merged from 3.0:
++ * Deserialise sstable metadata in nodetool verify (CASSANDRA-13922)
   * Improve TRUNCATE performance (CASSANDRA-13909)
   * Implement short read protection on partition boundaries (CASSANDRA-13595)
   * Fix ISE thrown by UPI.Serializer.hasNext() for some SELECT queries 
(CASSANDRA-13911)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f5bc4299/src/java/org/apache/cassandra/db/compaction/Verifier.java
--
diff --cc src/java/org/apache/cassandra/db/compaction/Verifier.java
index df659e4,68088b3..4c07bb6
--- a/src/java/org/apache/cassandra/db/compaction/Verifier.java
+++ b/src/java/org/apache/cassandra/db/compaction/Verifier.java
@@@ -88,7 -89,21 +90,21 @@@ public class Verifier implements Closea
  {
  long rowStart = 0;
  
 -outputHandler.output(String.format("Verifying %s (%s bytes)", 
sstable, dataFile.length()));
 +outputHandler.output(String.format("Verifying %s (%s)", sstable, 
FBUtilities.prettyPrintMemory(dataFile.length(;
+ outputHandler.output(String.format("Deserializing sstable metadata 
for %s ", sstable));
+ try
+ {
+ EnumSet types = EnumSet.of(MetadataType.VALIDATION, 
MetadataType.STATS, MetadataType.HEADER);
+ Map sstableMetadata = 
sstable.descriptor.getMetadataSerializer().deserialize(sstable.descriptor, 
types);
+ if (sstableMetadata.containsKey(MetadataType.VALIDATION) &&
+ 
!((ValidationMetadata)sstableMetadata.get(MetadataType.VALIDATION)).partitioner.equals(sstable.getPartitioner().getClass().getCanonicalName()))
+ throw new IOException("Partitioner does not match validation 
metadata");
+ }
+ catch (Throwable t)
+ {
+ outputHandler.debug(t.getMessage());
+ markAndThrow(false);
+ }
  outputHandler.output(String.format("Checking computed hash of %s ", 
sstable));
  
  
@@@ -187,8 -202,8 +203,8 @@@
  if (key == null || dataSize > dataFile.length())
  markAndThrow();
  
- //mimic the scrub read path
+ //mimic the scrub read path, intentionally unused
 -try (UnfilteredRowIterator iterator = new 
SSTableIdentityIterator(sstable, dataFile, key))
 +try (UnfilteredRowIterator iterator = 
SSTableIdentityIterator.create(sstable, dataFile, key))
  {
   

[jira] [Comment Edited] (CASSANDRA-13929) BTree$Builder / io.netty.util.Recycler$Stack leaking memory

[Thomas Steinmaurer (JIRA)]

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

Thomas Steinmaurer edited comment on CASSANDRA-13929 at 10/4/17 6:19 AM:
-

Ok, if this sort of caching is entirely only useful during streaming, this 
somehow explains why I do not see any difference between the nodes here, cause 
they process regular business and no repair, bootstrapping etc, thus I can't 
comment on the performance gain with the cache (possibly this has been tested 
in CASSANDRA-9766 anyway).

If the cache is useful for streaming, it still would definitely make sense 
IMHO, to make the max capacity configurable (with a somewhat useful small 
default value) via a system property, cassandra.yaml or whatever place is 
preferred here, cause ~ 2,4G+ heap usage for this sort of cache at -XmX8G does 
not make sense or perhaps the majority of Cassandra users don't scale out with 
smaller sized machines anymore.

As you have mentioned *per thread*. I guess we are talking about the number of 
threads serving client requests, aka e.g. {{native_transport_max_threads}}? If 
so, there should be somewhere a clear pointer in a comment, documentation etc., 
that heap usage is directly related to number of threads * configurable max size


was (Author: tsteinmaurer):
Ok, if this sort of caching is entirely only useful during streaming, this 
somehow explains why I do not see any difference between the nodes here, cause 
they process regular business and no repair, bootstrapping etc, thus I can't 
comment on the performance gain with the cache (possibly this has been tested 
in CASSANDRA-9766 anyway).

If the cache is useful for streaming, it still would definitely make sense 
IMHO, to make the max capacity configurable (with a somewhat useful small 
default value) via a system property, cassandra.yaml or whatever place is 
preferred here, cause ~ 2,4G+ heap usage for this sort of cache at -XmX8G does 
not make sense.

As you have mentioned *per thread*. I guess we are talking about the number of 
threads serving client requests, aka e.g. {{native_transport_max_threads}}? If 
so, there should be somewhere a clear pointer in a comment, documentation etc., 
that heap usage is directly related to number of threads * configurable max size

> BTree$Builder / io.netty.util.Recycler$Stack leaking memory
> ---
>
> Key: CASSANDRA-13929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13929
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Thomas Steinmaurer
> Attachments: cassandra_3.11.0_min_memory_utilization.jpg, 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png, 
> cassandra_3.11.1_mat_dominator_classes.png, 
> cassandra_3.11.1_snapshot_heaputilization.png
>
>
> Different to CASSANDRA-13754, there seems to be another memory leak in 
> 3.11.0+ in BTree$Builder / io.netty.util.Recycler$Stack.
> * heap utilization increase after upgrading to 3.11.0 => 
> cassandra_3.11.0_min_memory_utilization.jpg
> * No difference after upgrading to 3.11.1 (snapshot build) => 
> cassandra_3.11.1_snapshot_heaputilization.png; thus most likely after fixing 
> CASSANDRA-13754, more visible now
> * MAT shows io.netty.util.Recycler$Stack as top contributing class => 
> cassandra_3.11.1_mat_dominator_classes.png
> * With -Xmx8G (CMS) and our load pattern, we have to do a rolling restart 
> after ~ 72 hours
> Verified the following fix, namely explicitly unreferencing the 
> _recycleHandle_ member (making it non-final). In 
> _org.apache.cassandra.utils.btree.BTree.Builder.recycle()_
> {code}
> public void recycle()
> {
> if (recycleHandle != null)
> {
> this.cleanup();
> builderRecycler.recycle(this, recycleHandle);
> recycleHandle = null; // ADDED
> }
> }
> {code}
> Patched a single node in our loadtest cluster with this change and after ~ 10 
> hours uptime, no sign of the previously offending class in MAT anymore => 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png
> Can' say if this has any other side effects etc., but I doubt.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13929) BTree$Builder / io.netty.util.Recycler$Stack leaking memory

[Thomas Steinmaurer (JIRA)]

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

Thomas Steinmaurer edited comment on CASSANDRA-13929 at 10/4/17 6:18 AM:
-

Ok, if this sort of caching is entirely only useful during streaming, this 
somehow explains why I do not see any difference between the nodes here, cause 
they process regular business and no repair, bootstrapping etc, thus I can't 
comment on the performance gain with the cache (possibly this has been tested 
in CASSANDRA-9766 anyway).

If the cache is useful for streaming, it still would definitely make sense 
IMHO, to make the max capacity configurable (with a somewhat useful small 
default value) via a system property, cassandra.yaml or whatever place is 
preferred here, cause ~ 2,4G+ heap usage for this sort of cache at -XmX8G does 
not make sense.

As you have mentioned *per thread*. I guess we are talking about the number of 
threads serving client requests, aka e.g. {{native_transport_max_threads}}? If 
so, there should be somewhere a clear pointer in a comment, documentation etc., 
that heap usage is directly related to number of threads * configurable max size


was (Author: tsteinmaurer):
Ok, if this sort of caching is entirely only useful during streaming, this 
somehow explains why I do not see any difference between the nodes here, cause 
they process regular business and no repair, bootstrapping etc, thus I can't 
comment on the performance gain with the cache (possibly this has been tested 
in CASSANDRA-9766 anyway).

If the cache is useful for streaming, it still would definitely make sense 
IMHO, to make the max capacity configurable via a system property, 
cassandra.yaml or whatever place is preferred here, cause ~ 2,4G+ heap usage 
for this sort of cache at -XmX8G does not make sense.

As you have mentioned *per thread*. I guess we are talking about the number of 
threads serving client requests, aka e.g. {{native_transport_max_threads}}? If 
so, there should be somewhere a clear pointer in a comment, documentation etc., 
that heap usage is directly related to number of threads * configurable max size

> BTree$Builder / io.netty.util.Recycler$Stack leaking memory
> ---
>
> Key: CASSANDRA-13929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13929
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Thomas Steinmaurer
> Attachments: cassandra_3.11.0_min_memory_utilization.jpg, 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png, 
> cassandra_3.11.1_mat_dominator_classes.png, 
> cassandra_3.11.1_snapshot_heaputilization.png
>
>
> Different to CASSANDRA-13754, there seems to be another memory leak in 
> 3.11.0+ in BTree$Builder / io.netty.util.Recycler$Stack.
> * heap utilization increase after upgrading to 3.11.0 => 
> cassandra_3.11.0_min_memory_utilization.jpg
> * No difference after upgrading to 3.11.1 (snapshot build) => 
> cassandra_3.11.1_snapshot_heaputilization.png; thus most likely after fixing 
> CASSANDRA-13754, more visible now
> * MAT shows io.netty.util.Recycler$Stack as top contributing class => 
> cassandra_3.11.1_mat_dominator_classes.png
> * With -Xmx8G (CMS) and our load pattern, we have to do a rolling restart 
> after ~ 72 hours
> Verified the following fix, namely explicitly unreferencing the 
> _recycleHandle_ member (making it non-final). In 
> _org.apache.cassandra.utils.btree.BTree.Builder.recycle()_
> {code}
> public void recycle()
> {
> if (recycleHandle != null)
> {
> this.cleanup();
> builderRecycler.recycle(this, recycleHandle);
> recycleHandle = null; // ADDED
> }
> }
> {code}
> Patched a single node in our loadtest cluster with this change and after ~ 10 
> hours uptime, no sign of the previously offending class in MAT anymore => 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png
> Can' say if this has any other side effects etc., but I doubt.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13929) BTree$Builder / io.netty.util.Recycler$Stack leaking memory

[Thomas Steinmaurer (JIRA)]

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

Thomas Steinmaurer edited comment on CASSANDRA-13929 at 10/4/17 6:17 AM:
-

Ok, if this sort of caching is entirely only useful during streaming, this 
somehow explains why I do not see any difference between the nodes here, cause 
they process regular business and no repair, bootstrapping etc, thus I can't 
comment on the performance gain with the cache (possibly this has been tested 
in CASSANDRA-9766 anyway).

If the cache is useful for streaming, it still would definitely make sense 
IMHO, to make the max capacity configurable via a system property, 
cassandra.yaml or whatever place is preferred here, cause ~ 2,4G+ heap usage 
for this sort of cache at -XmX8G does not make sense.

As you have mentioned *per thread*. I guess we are talking about the number of 
threads serving client requests, aka e.g. {{native_transport_max_threads}}? If 
so, there should be somewhere a clear pointer in a comment, documentation etc., 
that heap usage is directly related to number of threads * configurable max size


was (Author: tsteinmaurer):
Ok, if this sort of caching is entirely only useful during streaming, this 
somehow explains why I do not see any difference between the nodes here, cause 
they process regular business and no repair, bootstrapping etc, thus I can't 
comment on the performance gain with the cache (possibly this has been tested 
in CASSANDRA-9766 anyway).

If the cache is useful for streaming, it still would definitely make sense 
IMHO, to make the max capacity configurable via a system property, 
cassandra.yaml or whatever place is preferred here, cause ~ 2,4G+ heap usage 
for this sort of cache at -XmX8G does not make sense.

As you have mentioned *per thread*. I guess we are talking about the number of 
threads serving client requests, aka e.g. {{native_transport_max_threads}}. If 
so, there should be somewhere a clear pointer in a comment, documentation etc., 
that heap usage is directly related to number of threads * configurable max size

> BTree$Builder / io.netty.util.Recycler$Stack leaking memory
> ---
>
> Key: CASSANDRA-13929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13929
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Thomas Steinmaurer
> Attachments: cassandra_3.11.0_min_memory_utilization.jpg, 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png, 
> cassandra_3.11.1_mat_dominator_classes.png, 
> cassandra_3.11.1_snapshot_heaputilization.png
>
>
> Different to CASSANDRA-13754, there seems to be another memory leak in 
> 3.11.0+ in BTree$Builder / io.netty.util.Recycler$Stack.
> * heap utilization increase after upgrading to 3.11.0 => 
> cassandra_3.11.0_min_memory_utilization.jpg
> * No difference after upgrading to 3.11.1 (snapshot build) => 
> cassandra_3.11.1_snapshot_heaputilization.png; thus most likely after fixing 
> CASSANDRA-13754, more visible now
> * MAT shows io.netty.util.Recycler$Stack as top contributing class => 
> cassandra_3.11.1_mat_dominator_classes.png
> * With -Xmx8G (CMS) and our load pattern, we have to do a rolling restart 
> after ~ 72 hours
> Verified the following fix, namely explicitly unreferencing the 
> _recycleHandle_ member (making it non-final). In 
> _org.apache.cassandra.utils.btree.BTree.Builder.recycle()_
> {code}
> public void recycle()
> {
> if (recycleHandle != null)
> {
> this.cleanup();
> builderRecycler.recycle(this, recycleHandle);
> recycleHandle = null; // ADDED
> }
> }
> {code}
> Patched a single node in our loadtest cluster with this change and after ~ 10 
> hours uptime, no sign of the previously offending class in MAT anymore => 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png
> Can' say if this has any other side effects etc., but I doubt.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13929) BTree$Builder / io.netty.util.Recycler$Stack leaking memory

[Thomas Steinmaurer (JIRA)]

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

Thomas Steinmaurer edited comment on CASSANDRA-13929 at 10/4/17 6:17 AM:
-

Ok, if this sort of caching is entirely only useful during streaming, this 
somehow explains why I do not see any difference between the nodes here, cause 
they process regular business and no repair, bootstrapping etc, thus I can't 
comment on the performance gain with the cache (possibly this has been tested 
in CASSANDRA-9766 anyway).

If the cache is useful for streaming, it still would definitely make sense 
IMHO, to make the max capacity configurable via a system property, 
cassandra.yaml or whatever place is preferred here, cause ~ 2,4G+ heap usage 
for this sort of cache at -XmX8G does not make sense.

As you have mentioned *per thread*. I guess we are talking about the number of 
threads serving client requests, aka e.g. {{native_transport_max_threads}}. If 
so, there should be somewhere a clear pointer in a comment, documentation etc., 
that heap usage is directly related to number of threads * configurable max size


was (Author: tsteinmaurer):
Ok, if this sort of caching is entirely only useful during streaming, this 
somehow explains why I do not see any difference between the nodes here, cause 
they process regular business and no repair, bootstrapping etc, thus I can't 
comment on the performance gain with the cache (possibly this has been tested 
in CASSANDRA-9766 anyway).

If the cache is useful for streaming, it still would definitely make sense 
IMHO, to make the max capacity configurable via a system property, 
cassandra.yaml or whatever place is preferred here, cause ~ 1,8G heap usage for 
this sort of cache at -XmX8G does not make sense.

> BTree$Builder / io.netty.util.Recycler$Stack leaking memory
> ---
>
> Key: CASSANDRA-13929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13929
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Thomas Steinmaurer
> Attachments: cassandra_3.11.0_min_memory_utilization.jpg, 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png, 
> cassandra_3.11.1_mat_dominator_classes.png, 
> cassandra_3.11.1_snapshot_heaputilization.png
>
>
> Different to CASSANDRA-13754, there seems to be another memory leak in 
> 3.11.0+ in BTree$Builder / io.netty.util.Recycler$Stack.
> * heap utilization increase after upgrading to 3.11.0 => 
> cassandra_3.11.0_min_memory_utilization.jpg
> * No difference after upgrading to 3.11.1 (snapshot build) => 
> cassandra_3.11.1_snapshot_heaputilization.png; thus most likely after fixing 
> CASSANDRA-13754, more visible now
> * MAT shows io.netty.util.Recycler$Stack as top contributing class => 
> cassandra_3.11.1_mat_dominator_classes.png
> * With -Xmx8G (CMS) and our load pattern, we have to do a rolling restart 
> after ~ 72 hours
> Verified the following fix, namely explicitly unreferencing the 
> _recycleHandle_ member (making it non-final). In 
> _org.apache.cassandra.utils.btree.BTree.Builder.recycle()_
> {code}
> public void recycle()
> {
> if (recycleHandle != null)
> {
> this.cleanup();
> builderRecycler.recycle(this, recycleHandle);
> recycleHandle = null; // ADDED
> }
> }
> {code}
> Patched a single node in our loadtest cluster with this change and after ~ 10 
> hours uptime, no sign of the previously offending class in MAT anymore => 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png
> Can' say if this has any other side effects etc., but I doubt.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13929) BTree$Builder / io.netty.util.Recycler$Stack leaking memory

[Thomas Steinmaurer (JIRA)]

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

Thomas Steinmaurer commented on CASSANDRA-13929:


Ok, if this sort of caching is entirely only useful during streaming, this 
somehow explains why I do not see any difference between the nodes here, cause 
they process regular business and no repair, bootstrapping etc, thus I can't 
comment on the performance gain with the cache (possibly this has been tested 
in CASSANDRA-9766 anyway).

If the cache is useful for streaming, it still would definitely make sense 
IMHO, to make the max capacity configurable via a system property, 
cassandra.yaml or whatever place is preferred here, cause ~ 1,8G heap usage for 
this sort of cache at -XmX8G does not make sense.

> BTree$Builder / io.netty.util.Recycler$Stack leaking memory
> ---
>
> Key: CASSANDRA-13929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13929
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Thomas Steinmaurer
> Attachments: cassandra_3.11.0_min_memory_utilization.jpg, 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png, 
> cassandra_3.11.1_mat_dominator_classes.png, 
> cassandra_3.11.1_snapshot_heaputilization.png
>
>
> Different to CASSANDRA-13754, there seems to be another memory leak in 
> 3.11.0+ in BTree$Builder / io.netty.util.Recycler$Stack.
> * heap utilization increase after upgrading to 3.11.0 => 
> cassandra_3.11.0_min_memory_utilization.jpg
> * No difference after upgrading to 3.11.1 (snapshot build) => 
> cassandra_3.11.1_snapshot_heaputilization.png; thus most likely after fixing 
> CASSANDRA-13754, more visible now
> * MAT shows io.netty.util.Recycler$Stack as top contributing class => 
> cassandra_3.11.1_mat_dominator_classes.png
> * With -Xmx8G (CMS) and our load pattern, we have to do a rolling restart 
> after ~ 72 hours
> Verified the following fix, namely explicitly unreferencing the 
> _recycleHandle_ member (making it non-final). In 
> _org.apache.cassandra.utils.btree.BTree.Builder.recycle()_
> {code}
> public void recycle()
> {
> if (recycleHandle != null)
> {
> this.cleanup();
> builderRecycler.recycle(this, recycleHandle);
> recycleHandle = null; // ADDED
> }
> }
> {code}
> Patched a single node in our loadtest cluster with this change and after ~ 10 
> hours uptime, no sign of the previously offending class in MAT anymore => 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png
> Can' say if this has any other side effects etc., but I doubt.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org