[jira] [Commented] (CASSANDRA-13065) Consistent range movements to not require MV updates to go through write paths

[Benjamin Roth (JIRA)]

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

Benjamin Roth commented on CASSANDRA-13065:
---

[~pauloricardomg]

There you go. My first complete patch. I hope its ok and works :)
https://github.com/Jaumo/cassandra/commit/88699700feb6b9a504df88ff063b82641d7939f7

> Consistent range movements to not require MV updates to go through write 
> paths 
> ---
>
> Key: CASSANDRA-13065
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13065
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benjamin Roth
>Assignee: Benjamin Roth
>Priority: Critical
> Fix For: 4.0
>
>
> Booting or decommisioning nodes with MVs is unbearably slow as all streams go 
> through the regular write paths. This causes read-before-writes for every 
> mutation and during bootstrap it causes them to be sent to batchlog.
> The makes it virtually impossible to boot a new node in an acceptable amount 
> of time.
> Using the regular streaming behaviour for consistent range movements works 
> much better in this case and does not break the MV local consistency contract.
> Already tested on own cluster.
> Bootstrap case is super easy to handle, decommission case requires 
> CASSANDRA-13064



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

[jira] [Resolved] (CASSANDRA-13402) testall failure in org.apache.cassandra.dht.StreamStateStoreTest.testUpdateAndQueryAvailableRanges

[Joel Knighton (JIRA)]

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

Joel Knighton resolved CASSANDRA-13402.
---
Resolution: Duplicate

> testall failure in 
> org.apache.cassandra.dht.StreamStateStoreTest.testUpdateAndQueryAvailableRanges
> --
>
> Key: CASSANDRA-13402
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13402
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>  Labels: test-failure, testall
> Attachments: TEST-org.apache.cassandra.dht.StreamStateStoreTest.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_testall/1488/testReport/org.apache.cassandra.dht/StreamStateStoreTest/testUpdateAndQueryAvailableRanges
> {code}
> Stacktrace
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.streaming.StreamSession.isKeepAliveSupported(StreamSession.java:244)
>   at 
> org.apache.cassandra.streaming.StreamSession.(StreamSession.java:196)
>   at 
> org.apache.cassandra.dht.StreamStateStoreTest.testUpdateAndQueryAvailableRanges(StreamStateStoreTest.java:53)
> {code}
> Related failures: (13)
> http://cassci.datastax.com/job/trunk_testall/1488/testReport/



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

[jira] [Reopened] (CASSANDRA-12929) Fix version check to enable streaming keep-alive

[Joel Knighton (JIRA)]

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

Joel Knighton reopened CASSANDRA-12929:
---

It looks like this is causing quite a few test failures on commit.

In dtests, this includes many tests in sstable_generation_loading_test and 
snapshot_test.TestSnapshot.test_basic_snapshot_and_restore.

in testall, this includes 
StreamStateStoreTest.testUpdateAndQueryAvailableRanges, 
LocalSyncTaskTest.testDifference, 
StreamingRepairTaskTest.incrementalStreamPlan, 
StreamingRepairTaskTest.fullStreamPlan, 
StreamTransferTaskTest.testScheduleTimeout, and 
StreamTransferTaskTest.testFailSessionDuringTransferShouldNotReleaseReferences.

There may be others that I missed, but that list should get things pointed in 
the right direction.

> Fix version check to enable streaming keep-alive
> 
>
> Key: CASSANDRA-12929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12929
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Michael Shuler
>Assignee: Paulo Motta
>  Labels: dtest, test-failure
> Fix For: 4.0
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/494/testReport/bootstrap_test/TestBootstrap/simple_bootstrap_test_small_keepalive_period
> {noformat}
> Error Message
> Expected [['COMPLETED']] from SELECT bootstrapped FROM system.local WHERE 
> key='local', but got [[u'IN_PROGRESS']]
>  >> begin captured logging << 
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-YmnyEI
> dtest: DEBUG: Done setting configuration options:
> {   'num_tokens': None, 'phi_convict_threshold': 5, 'start_rpc': 'true'}
> cassandra.cluster: INFO: New Cassandra host  
> discovered
> - >> end captured logging << -
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools/decorators.py", line 46, in 
> wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/bootstrap_test.py", line 163, in 
> simple_bootstrap_test_small_keepalive_period
> assert_bootstrap_state(self, node2, 'COMPLETED')
>   File "/home/automaton/cassandra-dtest/tools/assertions.py", line 297, in 
> assert_bootstrap_state
> assert_one(session, "SELECT bootstrapped FROM system.local WHERE 
> key='local'", [expected_bootstrap_state])
>   File "/home/automaton/cassandra-dtest/tools/assertions.py", line 130, in 
> assert_one
> assert list_res == [expected], "Expected {} from {}, but got 
> {}".format([expected], query, list_res)
> "Expected [['COMPLETED']] from SELECT bootstrapped FROM system.local WHERE 
> key='local', but got [[u'IN_PROGRESS']]\n >> begin 
> captured logging << \ndtest: DEBUG: cluster ccm 
> directory: /tmp/dtest-YmnyEI\ndtest: DEBUG: Done setting configuration 
> options:\n{   'num_tokens': None, 'phi_convict_threshold': 5, 'start_rpc': 
> 'true'}\ncassandra.cluster: INFO: New Cassandra host  datacenter1> discovered\n- >> end captured logging << 
> -"
> {noformat}



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

[jira] [Comment Edited] (CASSANDRA-13346) Failed unregistering mbean during drop keyspace

[JIRA]

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

Gábor Auth edited comment on CASSANDRA-13346 at 4/4/17 5:22 AM:


[~jjirsa]: yes, as I mentioned in the description: "All node throw exceptions 
about materialized views during drop keyspace". :)

All nodes throws this exception about all materialized view of the keyspace 
during drop keyspace command.


was (Author: gabor.auth):
[~jjirsa]: yes, as I mentioned in the description: "All node throw exceptions 
about materialized views during drop keyspace". :)

> Failed unregistering mbean during drop keyspace
> ---
>
> Key: CASSANDRA-13346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13346
> Project: Cassandra
>  Issue Type: Bug
>  Components: Materialized Views
> Environment: Cassandra 3.9
>Reporter: Gábor Auth
>Priority: Minor
>  Labels: lhf
>
> All node throw exceptions about materialized views during drop keyspace:
> {code}
> WARN  [MigrationStage:1] 2017-03-16 16:54:25,016 ColumnFamilyStore.java:535 - 
> Failed unregistering mbean: 
> org.apache.cassandra.db:type=Tables,keyspace=test20160810,table=unit_by_account
> java.lang.NullPointerException: null
> at 
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ConcurrentHashMap$KeySetView.remove(ConcurrentHashMap.java:4569)
>  ~[na:1.8.0_121]
> at 
> org.apache.cassandra.metrics.TableMetrics.release(TableMetrics.java:712) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.unregisterMBean(ColumnFamilyStore.java:570)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:527)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:517)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.db.Keyspace.unloadCf(Keyspace.java:365) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.db.Keyspace.dropCf(Keyspace.java:358) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.config.Schema.dropView(Schema.java:744) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.lambda$mergeSchema$373(SchemaKeyspace.java:1287)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_121]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1287)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1256)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:51)
>  ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_121]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  ~[na:1.8.0_121]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {code}



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

[jira] [Updated] (CASSANDRA-13346) Failed unregistering mbean during drop keyspace

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13346:
---
Component/s: Materialized Views

> Failed unregistering mbean during drop keyspace
> ---
>
> Key: CASSANDRA-13346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13346
> Project: Cassandra
>  Issue Type: Bug
>  Components: Materialized Views
> Environment: Cassandra 3.9
>Reporter: Gábor Auth
>Priority: Minor
>  Labels: lhf
>
> All node throw exceptions about materialized views during drop keyspace:
> {code}
> WARN  [MigrationStage:1] 2017-03-16 16:54:25,016 ColumnFamilyStore.java:535 - 
> Failed unregistering mbean: 
> org.apache.cassandra.db:type=Tables,keyspace=test20160810,table=unit_by_account
> java.lang.NullPointerException: null
> at 
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ConcurrentHashMap$KeySetView.remove(ConcurrentHashMap.java:4569)
>  ~[na:1.8.0_121]
> at 
> org.apache.cassandra.metrics.TableMetrics.release(TableMetrics.java:712) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.unregisterMBean(ColumnFamilyStore.java:570)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:527)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:517)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.db.Keyspace.unloadCf(Keyspace.java:365) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.db.Keyspace.dropCf(Keyspace.java:358) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.config.Schema.dropView(Schema.java:744) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.lambda$mergeSchema$373(SchemaKeyspace.java:1287)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_121]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1287)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1256)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:51)
>  ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_121]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  ~[na:1.8.0_121]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {code}



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

[jira] [Commented] (CASSANDRA-13346) Failed unregistering mbean during drop keyspace

[JIRA]

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

Gábor Auth commented on CASSANDRA-13346:


"Is there any context around this?"

Hm... I saw only this exception.

"Were you doing any other schema modification at the time?"

No, only `DROP KEYSPACE test20160810`.

"Also was there any other effect other than this error in the logs?"

As I see, everything is okay but this exception.

> Failed unregistering mbean during drop keyspace
> ---
>
> Key: CASSANDRA-13346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13346
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.9
>Reporter: Gábor Auth
>Priority: Minor
>  Labels: lhf
>
> All node throw exceptions about materialized views during drop keyspace:
> {code}
> WARN  [MigrationStage:1] 2017-03-16 16:54:25,016 ColumnFamilyStore.java:535 - 
> Failed unregistering mbean: 
> org.apache.cassandra.db:type=Tables,keyspace=test20160810,table=unit_by_account
> java.lang.NullPointerException: null
> at 
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ConcurrentHashMap$KeySetView.remove(ConcurrentHashMap.java:4569)
>  ~[na:1.8.0_121]
> at 
> org.apache.cassandra.metrics.TableMetrics.release(TableMetrics.java:712) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.unregisterMBean(ColumnFamilyStore.java:570)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:527)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:517)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.db.Keyspace.unloadCf(Keyspace.java:365) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.db.Keyspace.dropCf(Keyspace.java:358) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.config.Schema.dropView(Schema.java:744) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.lambda$mergeSchema$373(SchemaKeyspace.java:1287)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_121]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1287)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1256)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:51)
>  ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_121]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  ~[na:1.8.0_121]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {code}



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

[jira] [Commented] (CASSANDRA-13346) Failed unregistering mbean during drop keyspace

[JIRA]

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

Gábor Auth commented on CASSANDRA-13346:


[~jjirsa]: yes, as I mentioned in the description: "All node throw exceptions 
about materialized views during drop keyspace". :)

> Failed unregistering mbean during drop keyspace
> ---
>
> Key: CASSANDRA-13346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13346
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.9
>Reporter: Gábor Auth
>Priority: Minor
>  Labels: lhf
>
> All node throw exceptions about materialized views during drop keyspace:
> {code}
> WARN  [MigrationStage:1] 2017-03-16 16:54:25,016 ColumnFamilyStore.java:535 - 
> Failed unregistering mbean: 
> org.apache.cassandra.db:type=Tables,keyspace=test20160810,table=unit_by_account
> java.lang.NullPointerException: null
> at 
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ConcurrentHashMap$KeySetView.remove(ConcurrentHashMap.java:4569)
>  ~[na:1.8.0_121]
> at 
> org.apache.cassandra.metrics.TableMetrics.release(TableMetrics.java:712) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.unregisterMBean(ColumnFamilyStore.java:570)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:527)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:517)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.db.Keyspace.unloadCf(Keyspace.java:365) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.db.Keyspace.dropCf(Keyspace.java:358) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.config.Schema.dropView(Schema.java:744) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.lambda$mergeSchema$373(SchemaKeyspace.java:1287)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_121]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1287)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1256)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:51)
>  ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_121]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  ~[na:1.8.0_121]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {code}



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

[jira] [Commented] (CASSANDRA-13346) Failed unregistering mbean during drop keyspace

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13346:


[~gabor.auth] - is {{test20160810.unit_by_account}} a materialized view as 
well? 



> Failed unregistering mbean during drop keyspace
> ---
>
> Key: CASSANDRA-13346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13346
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.9
>Reporter: Gábor Auth
>Priority: Minor
>  Labels: lhf
>
> All node throw exceptions about materialized views during drop keyspace:
> {code}
> WARN  [MigrationStage:1] 2017-03-16 16:54:25,016 ColumnFamilyStore.java:535 - 
> Failed unregistering mbean: 
> org.apache.cassandra.db:type=Tables,keyspace=test20160810,table=unit_by_account
> java.lang.NullPointerException: null
> at 
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ConcurrentHashMap$KeySetView.remove(ConcurrentHashMap.java:4569)
>  ~[na:1.8.0_121]
> at 
> org.apache.cassandra.metrics.TableMetrics.release(TableMetrics.java:712) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.unregisterMBean(ColumnFamilyStore.java:570)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:527)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:517)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.db.Keyspace.unloadCf(Keyspace.java:365) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.db.Keyspace.dropCf(Keyspace.java:358) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.config.Schema.dropView(Schema.java:744) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.lambda$mergeSchema$373(SchemaKeyspace.java:1287)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_121]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1287)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1256)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:51)
>  ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_121]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  ~[na:1.8.0_121]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {code}



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

[jira] [Comment Edited] (CASSANDRA-13346) Failed unregistering mbean during drop keyspace

[Andrew Efimov (JIRA)]

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

Andrew Efimov edited comment on CASSANDRA-13346 at 4/4/17 1:06 AM:
---

Hi Jeremy, Gábor
I have the same issue in 3.10, in my case, this occurs only for materialized 
views at the end of the test phase.
Also I am using org.cassandraunit for testing in embedded mode.
{noformat}
java.lang.NullPointerException: null
at 
java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106) 
~[na:1.8.0_121]
at 
java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097) 
~[na:1.8.0_121]
at 
java.util.concurrent.ConcurrentHashMap$KeySetView.remove(ConcurrentHashMap.java:4569)
 ~[na:1.8.0_121]
at 
org.apache.cassandra.metrics.TableMetrics.release(TableMetrics.java:713) 
~[cassandra-all-3.10.jar:3.10]
at 
org.apache.cassandra.db.ColumnFamilyStore.unregisterMBean(ColumnFamilyStore.java:577)
 [cassandra-all-3.10.jar:3.10]
at 
org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:534)
 [cassandra-all-3.10.jar:3.10]
at 
org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:524)
 [cassandra-all-3.10.jar:3.10]
at org.apache.cassandra.db.Keyspace.unloadCf(Keyspace.java:370) 
[cassandra-all-3.10.jar:3.10]
at org.apache.cassandra.db.Keyspace.dropCf(Keyspace.java:363) 
[cassandra-all-3.10.jar:3.10]
at org.apache.cassandra.config.Schema.dropView(Schema.java:704) 
[cassandra-all-3.10.jar:3.10]
at 
org.apache.cassandra.schema.SchemaKeyspace.lambda$mergeSchema$17(SchemaKeyspace.java:1313)
 [cassandra-all-3.10.jar:3.10]
at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_121]
at 
org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1313)
 [cassandra-all-3.10.jar:3.10]
at 
org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1282)
 [cassandra-all-3.10.jar:3.10]
at 
org.apache.cassandra.service.MigrationManager$1.runMayThrow(MigrationManager.java:535)
 ~[cassandra-all-3.10.jar:3.10]
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
~[cassandra-all-3.10.jar:3.10]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_121]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~[na:1.8.0_121]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_121]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
~[na:1.8.0_121]
at 
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
 ~[cassandra-all-3.10.jar:3.10]
at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
{noformat}


was (Author: andrew efimov):
Hi Jeremy, Gábor
I have the same issue in 3.10, in my case, it is occurred only for materialized 
views.
Also I am using org.cassandraunit for testing in embedded mode.

> Failed unregistering mbean during drop keyspace
> ---
>
> Key: CASSANDRA-13346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13346
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.9
>Reporter: Gábor Auth
>Priority: Minor
>  Labels: lhf
>
> All node throw exceptions about materialized views during drop keyspace:
> {code}
> WARN  [MigrationStage:1] 2017-03-16 16:54:25,016 ColumnFamilyStore.java:535 - 
> Failed unregistering mbean: 
> org.apache.cassandra.db:type=Tables,keyspace=test20160810,table=unit_by_account
> java.lang.NullPointerException: null
> at 
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ConcurrentHashMap$KeySetView.remove(ConcurrentHashMap.java:4569)
>  ~[na:1.8.0_121]
> at 
> org.apache.cassandra.metrics.TableMetrics.release(TableMetrics.java:712) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.unregisterMBean(ColumnFamilyStore.java:570)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:527)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:517)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.db.Keyspace.unloadCf(Keyspace.java:365) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at 

[jira] [Commented] (CASSANDRA-13346) Failed unregistering mbean during drop keyspace

[Andrew Efimov (JIRA)]

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

Andrew Efimov commented on CASSANDRA-13346:
---

Hi Jeremy, Gábor
I have the same issue in 3.10, in my case, it is occurred only for materialized 
views.
Also I am using org.cassandraunit for testing in embedded mode.

> Failed unregistering mbean during drop keyspace
> ---
>
> Key: CASSANDRA-13346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13346
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.9
>Reporter: Gábor Auth
>Priority: Minor
>  Labels: lhf
>
> All node throw exceptions about materialized views during drop keyspace:
> {code}
> WARN  [MigrationStage:1] 2017-03-16 16:54:25,016 ColumnFamilyStore.java:535 - 
> Failed unregistering mbean: 
> org.apache.cassandra.db:type=Tables,keyspace=test20160810,table=unit_by_account
> java.lang.NullPointerException: null
> at 
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ConcurrentHashMap$KeySetView.remove(ConcurrentHashMap.java:4569)
>  ~[na:1.8.0_121]
> at 
> org.apache.cassandra.metrics.TableMetrics.release(TableMetrics.java:712) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.unregisterMBean(ColumnFamilyStore.java:570)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:527)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:517)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.db.Keyspace.unloadCf(Keyspace.java:365) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.db.Keyspace.dropCf(Keyspace.java:358) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.config.Schema.dropView(Schema.java:744) 
> [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.lambda$mergeSchema$373(SchemaKeyspace.java:1287)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_121]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1287)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1256)
>  [apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:51)
>  ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_121]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  ~[na:1.8.0_121]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {code}



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

[jira] [Commented] (CASSANDRA-13289) Make it possible to monitor an ideal consistency level separate from actual consistency level

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-13289:


I want to add some docs for the ideal consistency level metrics 
https://github.com/apache/cassandra/compare/trunk...aweisberg:cassandra-13289-2?expand=1
[~jasobrown] can you take a look? 

> Make it possible to monitor an ideal consistency level separate from actual 
> consistency level
> -
>
> Key: CASSANDRA-13289
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13289
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
> Fix For: 4.0
>
>
> As an operator there are several issues related to multi-datacenter 
> replication and consistency you may want to have more information on from 
> your production database.
> For instance. If your application writes at LOCAL_QUORUM how often are those 
> writes failing to achieve EACH_QUORUM at other data centers. If you failed 
> your application over to one of those data centers roughly how inconsistent 
> might it be given the number of writes that didn't propagate since the last 
> incremental repair?
> You might also want to know roughly what the latency of writes would be if 
> you switched to a different consistency level. For instance you are writing 
> at LOCAL_QUORUM and want to know what would happen if you switched to 
> EACH_QUORUM.
> The proposed change is to allow an ideal_consistency_level to be specified in 
> cassandra.yaml as well as get/set via JMX. If no ideal consistency level is 
> specified no additional tracking is done.
> if an ideal consistency level is specified then the 
> {{AbstractWriteResponesHandler}} will contain a delegate WriteResponseHandler 
> that tracks whether the ideal consistency level is met before a write times 
> out. It also tracks the latency for achieving the ideal CL  of successful 
> writes.
> These two metrics would be reported on a per keyspace basis.



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

[jira] [Updated] (CASSANDRA-13373) Provide additional speculative retry statistics

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-13373:
---
Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

Committed as 
[2c6924b561ddf0b0df9315946b21260d6e27fdb9|https://github.com/apache/cassandra/commit/2c6924b561ddf0b0df9315946b21260d6e27fdb9]

> Provide additional speculative retry statistics
> ---
>
> Key: CASSANDRA-13373
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13373
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
> Fix For: 4.x
>
>
> Right now there is a single metric for speculative retry on reads that is the 
> number of speculative retries attempted. You can't tell how many of those 
> actually succeeded in salvaging the read.
> The metric is also per table and there is no keyspace level rollup as there 
> is for several other metrics.
> Add a metric that counts reads that attempt to speculate but fail to complete 
> before the timeout (ignoring read errors).
> Add a rollup metric for the current count of speculation attempts as well as 
> the count of failed speculations.



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

cassandra git commit: Add additional statistics for speculative retry.

[aweisberg]

Repository: cassandra
Updated Branches:
  refs/heads/trunk ab7aa57b3 -> 2c6924b56


Add additional statistics for speculative retry.

Patch by Ariel Weisberg; Reviewed by Blake Eggleston for CASSANDRA-13373


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

Branch: refs/heads/trunk
Commit: 2c6924b561ddf0b0df9315946b21260d6e27fdb9
Parents: ab7aa57
Author: Ariel Weisberg 
Authored: Thu Mar 23 19:25:54 2017 -0400
Committer: Ariel Weisberg 
Committed: Mon Apr 3 18:24:02 2017 -0400

--
 doc/source/operating/metrics.rst|   3 +
 .../cassandra/metrics/KeyspaceMetrics.java  |  52 +
 .../apache/cassandra/metrics/TableMetrics.java  |  12 ++
 .../cassandra/service/AbstractReadExecutor.java | 102 ++---
 .../apache/cassandra/service/ReadCallback.java  |   2 +-
 .../cassandra/service/ReadExecutorTest.java | 215 +++
 6 files changed, 360 insertions(+), 26 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2c6924b5/doc/source/operating/metrics.rst
--
diff --git a/doc/source/operating/metrics.rst b/doc/source/operating/metrics.rst
index af2e36e..6e1b212 100644
--- a/doc/source/operating/metrics.rst
+++ b/doc/source/operating/metrics.rst
@@ -127,6 +127,9 @@ CasPropose  Latency
Latency of paxos propose
 CasCommit   LatencyLatency of paxos commit 
round.
 PercentRepaired Gauge  Percent of table data 
that is repaired on disk.
 SpeculativeRetries  CounterNumber of times 
speculative retries were sent for this table.
+SpeculativeFailedRetriesCounterNumber of speculative 
retries that failed to prevent a timeout
+SpeculativeInsufficientReplicas CounterNumber of speculative 
retries that couldn't be attempted due to lack of replicas
+SpeculativeSampleLatencyNanos   GaugeNumber of nanoseconds 
to wait before speculation is attempted. Value may be statically configured or 
updated periodically based on coordinator latency.
 WaitingOnFreeMemtableSpace  Histogram  Histogram of time spent 
waiting for free memtable space, either on- or off-heap.
 DroppedMutationsCounterNumber of dropped 
mutations on this table.
 === == ===

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2c6924b5/src/java/org/apache/cassandra/metrics/KeyspaceMetrics.java
--
diff --git a/src/java/org/apache/cassandra/metrics/KeyspaceMetrics.java 
b/src/java/org/apache/cassandra/metrics/KeyspaceMetrics.java
index 63f8dd0..3c6b604 100644
--- a/src/java/org/apache/cassandra/metrics/KeyspaceMetrics.java
+++ b/src/java/org/apache/cassandra/metrics/KeyspaceMetrics.java
@@ -97,6 +97,12 @@ public class KeyspaceMetrics
 public final Counter writeFailedIdealCL;
 /** Ideal CL write latency metrics */
 public final LatencyMetrics idealCLWriteLatency;
+/** Speculative retries **/
+public final Counter speculativeRetries;
+/** Speculative retry occured but still timed out **/
+public final Counter speculativeFailedRetries;
+/** Needed to speculate, but didn't have enough replicas **/
+public final Counter speculativeInsufficientReplicas;
 
 public final MetricNameFactory factory;
 private Keyspace keyspace;
@@ -244,6 +250,28 @@ public class KeyspaceMetrics
 casCommit = new LatencyMetrics(factory, "CasCommit");
 writeFailedIdealCL = 
Metrics.counter(factory.createMetricName("WriteFailedIdealCL"));
 idealCLWriteLatency = new LatencyMetrics(factory, "IdealCLWrite");
+
+speculativeRetries = createKeyspaceCounter("SpeculativeRetries", new 
MetricValue()
+{
+public Long getValue(TableMetrics metric)
+{
+return metric.speculativeRetries.getCount();
+}
+});
+speculativeFailedRetries = 
createKeyspaceCounter("SpeculativeFailedRetries", new MetricValue()
+{
+public Long getValue(TableMetrics metric)
+{
+return metric.speculativeFailedRetries.getCount();
+}
+});
+speculativeInsufficientReplicas = 
createKeyspaceCounter("SpeculativeInsufficientReplicas", new MetricValue()
+{
+public Long getValue(TableMetrics metric)
+{
+return 

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

[Michael Kjellman (JIRA)]

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

Michael Kjellman updated CASSANDRA-13216:
-
Reviewer: Michael Kjellman

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



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

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

[Michael Kjellman (JIRA)]

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

Michael Kjellman reassigned CASSANDRA-13216:


Assignee: Alex Petrov  (was: Michael Kjellman)

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



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

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

[Michael Kjellman (JIRA)]

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

Michael Kjellman commented on CASSANDRA-13216:
--

Yes, I can review again.

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



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

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

[Michael Kjellman (JIRA)]

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

Michael Kjellman reassigned CASSANDRA-13216:


Assignee: Michael Kjellman  (was: Alex Petrov)

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



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

[jira] [Commented] (CASSANDRA-11483) Enhance sstablemetadata

[Chris Lohfink (JIRA)]

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

Chris Lohfink commented on CASSANDRA-11483:
---

Is there anything outstanding on this issue to get in?

> Enhance sstablemetadata
> ---
>
> Key: CASSANDRA-11483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11483
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Minor
> Fix For: 4.0
>
> Attachments: CASSANDRA-11483.txt, CASSANDRA-11483v2.txt, 
> CASSANDRA-11483v3.txt, CASSANDRA-11483v4.txt, CASSANDRA-11483v5.txt, Screen 
> Shot 2016-04-03 at 11.40.32 PM.png
>
>
> sstablemetadata provides quite a bit of useful information but theres a few 
> hiccups I would like to see addressed:
> * Does not use client mode
> * Units are not provided (or anything for that matter). There is data in 
> micros, millis, seconds as durations and timestamps from epoch. But there is 
> no way to tell what one is without a non-trival code dive
> * in general pretty frustrating to parse



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

[jira] [Commented] (CASSANDRA-13257) Add repair streaming preview

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-13257:
-

/cc [~yukim] ^^

> Add repair streaming preview
> 
>
> Key: CASSANDRA-13257
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13257
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Streaming and Messaging
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
> Fix For: 4.0
>
>
> It would be useful to be able to estimate the amount of repair streaming that 
> needs to be done, without actually doing any streaming. Our main motivation 
> for this having something this is validating CASSANDRA-9143 in production, 
> but I’d imagine it could also be a useful tool in troubleshooting.



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

[jira] [Comment Edited] (CASSANDRA-13403) nodetool repair breaks SASI index

[Igor Novgorodov (JIRA)]

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

Igor Novgorodov edited comment on CASSANDRA-13403 at 4/3/17 9:19 PM:
-

P.S.
I can't seem to reproduce this in a separate test cluster. Maybe my on-disk 
data on production cluster has been corrupted in some weird way?

In a production cluster i can reproduce this 100% in at least two different 
keyspaces (with same structure):

{code}
> select bulk_id from bulks_recipients where bulk_id = 
> 69135a30-531d-43b0-a93a-f751875fc14d; 

 bulk_id
--
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d

(10 rows)
{code}
... do repair ...
{code}
> select bulk_id from bulks_recipients where bulk_id = 
> 69135a30-531d-43b0-a93a-f751875fc14d;

 bulk_id
--
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d

(5 rows)

> select bulk_id from bulks_recipients;

 bulk_id
--
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d
 69135a30-531d-43b0-a93a-f751875fc14d

(10 rows)
{code}


was (Author: blind_oracle):
P.S.
I can't seem to reproduce this in a separate test cluster. Maybe my on-disk 
data on production cluster has been corrupted in some weird way?

> nodetool repair breaks SASI index
> -
>
> Key: CASSANDRA-13403
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13403
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
> Environment: 3.10
>Reporter: Igor Novgorodov
>
> I've got table:
> {code}
> CREATE TABLE cservice.bulks_recipients (
> recipient text,
> bulk_id uuid,
> datetime_final timestamp,
> datetime_sent timestamp,
> request_id uuid,
> status int,
> PRIMARY KEY (recipient, bulk_id)
> ) WITH CLUSTERING ORDER BY (bulk_id ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> CREATE CUSTOM INDEX bulk_recipients_bulk_id ON cservice.bulks_recipients 
> (bulk_id) USING 'org.apache.cassandra.index.sasi.SASIIndex';
> {code}
> There are 11 rows in it:
> {code}
> > select * from bulks_recipients;
> ...
> (11 rows)
> {code}
> Let's query by index (all rows have the same *bulk_id*):
> {code}
> > select * from bulks_recipients where bulk_id = 
> > baa94815-e276-4ca4-adda-5b9734e6c4a5;   
> >   
> ...
> (11 rows)
> {code}
> Ok, everything is fine.
> Now i'm doing *nodetool repair --partitioner-range --job-threads 4 --full* on 
> each node in cluster sequentially.
> After it finished:
> {code}
> > select * from bulks_recipients where bulk_id = 
> > baa94815-e276-4ca4-adda-5b9734e6c4a5;
> ...
> (2 rows)
> {code}
> Only two rows.
> While the rows are actually there:
> {code}
> > select * from bulks_recipients;
> ...
> (11 rows)
> {code}
> If i issue an incremental repair on a random node, i can get like 7 rows 
> after index query.
> Dropping index and recreating it fixes the issue. Is it a bug or am i doing 
> the repair the wrong way?



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

[jira] [Commented] (CASSANDRA-13403) nodetool repair breaks SASI index

[Igor Novgorodov (JIRA)]

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

Igor Novgorodov commented on CASSANDRA-13403:
-

P.S.
I can't seem to reproduce this in a separate test cluster. Maybe my on-disk 
data on production cluster has been corrupted in some weird way?

> nodetool repair breaks SASI index
> -
>
> Key: CASSANDRA-13403
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13403
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
> Environment: 3.10
>Reporter: Igor Novgorodov
>
> I've got table:
> {code}
> CREATE TABLE cservice.bulks_recipients (
> recipient text,
> bulk_id uuid,
> datetime_final timestamp,
> datetime_sent timestamp,
> request_id uuid,
> status int,
> PRIMARY KEY (recipient, bulk_id)
> ) WITH CLUSTERING ORDER BY (bulk_id ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> CREATE CUSTOM INDEX bulk_recipients_bulk_id ON cservice.bulks_recipients 
> (bulk_id) USING 'org.apache.cassandra.index.sasi.SASIIndex';
> {code}
> There are 11 rows in it:
> {code}
> > select * from bulks_recipients;
> ...
> (11 rows)
> {code}
> Let's query by index (all rows have the same *bulk_id*):
> {code}
> > select * from bulks_recipients where bulk_id = 
> > baa94815-e276-4ca4-adda-5b9734e6c4a5;   
> >   
> ...
> (11 rows)
> {code}
> Ok, everything is fine.
> Now i'm doing *nodetool repair --partitioner-range --job-threads 4 --full* on 
> each node in cluster sequentially.
> After it finished:
> {code}
> > select * from bulks_recipients where bulk_id = 
> > baa94815-e276-4ca4-adda-5b9734e6c4a5;
> ...
> (2 rows)
> {code}
> Only two rows.
> While the rows are actually there:
> {code}
> > select * from bulks_recipients;
> ...
> (11 rows)
> {code}
> If i issue an incremental repair on a random node, i can get like 7 rows 
> after index query.
> Dropping index and recreating it fixes the issue. Is it a bug or am i doing 
> the repair the wrong way?



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

[jira] [Commented] (CASSANDRA-13373) Provide additional speculative retry statistics

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-13373:


Good point. I need to do that for the ideal CL metrics as well.

> Provide additional speculative retry statistics
> ---
>
> Key: CASSANDRA-13373
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13373
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
> Fix For: 4.x
>
>
> Right now there is a single metric for speculative retry on reads that is the 
> number of speculative retries attempted. You can't tell how many of those 
> actually succeeded in salvaging the read.
> The metric is also per table and there is no keyspace level rollup as there 
> is for several other metrics.
> Add a metric that counts reads that attempt to speculate but fail to complete 
> before the timeout (ignoring read errors).
> Add a rollup metric for the current count of speculation attempts as well as 
> the count of failed speculations.



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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13396:


Let's focus on the problems and solutions. 

There were missing and incomplete comments around a broken piece of code that 
fixed a very-hard-to-troubleshoot bug. We've fixed the missing and incomplete 
comments, we still need to fix the broken code, and we can do so without 
ignoring the past very-hard-to-troubleshoot-bug. 

We have a patch that fixes the ClassCastException, which should be reviewed. We 
have a (non-binding) -1 on that review. One of the thing that 3 committers 
(including myself) seem to have suggested is at least adding a warning. 
[~snazy] is that agreeable to you?




> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Commented] (CASSANDRA-13405) ViewBuilder can miss data due to sstable generation filter

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-13405:
-

bq. The view builder for one MV is restarted when other MVs are added on the 
same keyspace.

Just curious, is there any reason for this? I don't see a reason for 
interrupting current view builds when a new view is added so perhaps we should 
improve this? Either here or in another ticket..

bq. I don't see a need for this generation tracking across restarts, it only 
needs to be tracked during a builders life (to avoid adding in newly compacted 
data). 

good catch, I think the original idea was to support resume after crash but 
this is not safe since compacted sstables can be garbage collected in-between 
view build restart - we could try to handle this by keeping the references 
between rebuild, but resuming by token range is probably good enough already 
and much simpler.

The patch looks good and new logs will be very helpful, commented a few minor 
nits directly on github code. +1 after nits are addressed and 3.11 dtest 
results look good. Thanks!

> ViewBuilder can miss data due to sstable generation filter
> --
>
> Key: CASSANDRA-13405
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13405
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
>  Labels: materializedviews
> Fix For: 3.0.13
>
>
> The view builder for one MV is restarted when other MVs are added on the same 
> keyspace.  There is an issue if compactions are running between these 
> restarts that can cause the view builder to skip data, since the builder 
> tracks the max sstable generation to filter by when it starts back up.
> I don't see a need for this generation tracking across restarts, it only 
> needs to be tracked during a builders life (to avoid adding in newly 
> compacted data).  



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

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

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-11471:


I don't have any objections to using Optional and I don't think there is a 
codified objection to it in the project. For this use case it's fine. I would 
just keep optional allocations out of any per request, or per row or column 
loops and avoid them for frequently used lookups. I think it's fine to use them 
when accepting a connection.

I guess what is confusing me here is that all the tests passed when the new 
startup message was being sent to the v4 client that is checked in and used for 
the tests. I can't tell if I check this in, will it break things since the 
v5-beta driver doesn't understand the new SASL mechanism? It seems like things 
should have not worked, but then they did.

The dtests use cassandra-test branch of the python driver which claims v5 
support. The checked in Python and Java driver both don't claim v5 support so 
those should continue to work even if we commit this change without doing the 
driver work.

Wha I am afraid of is checking this in and breaking the dtests. CassCI is no 
longer available so right now I don't have a great way to run the tests.

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



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

[jira] [Created] (CASSANDRA-13406) Stress chooses batch size 1 if cluster column name in YAML is not all lower case

[Eric Pederson (JIRA)]

Eric Pederson created CASSANDRA-13406:
-

 Summary: Stress chooses batch size 1 if cluster column name in 
YAML is not all lower case
 Key: CASSANDRA-13406
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13406
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Eric Pederson


If you give the cluster column name in mixed case then the batch size is always 
chosen as 1, for example:

{code}
columnspec:
  - name: creationdate
size: fixed(10)
population: seq(1..400)
  - name: UniqueSequenceNumber  # Note mixed case  
cluster: uniform(100..200)

insert:
  partitions: fixed(1)  
  batchtype: UNLOGGED
  select: uniform(10..15)/200
{code}

Running this results in
{code}
Generating batches with [1..1] partitions and [1..1] rows (of [1..1] total rows 
in the partitions)
{code}

Changing the cluster column name to {{uniquesequencenumber}} gives the expected 
results:
{code}
Generating batches with [1..1] partitions and [5..15] rows (of [100..200] total 
rows in the partitions)
{code}



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

[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Edward Capriolo (JIRA)]

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

Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 7:31 PM:
-

{quote}
The project has always allowed ninja fixing minor (especially non-code) things. 
Comments here are a net positive. There's no reason to fight about adding 
comments after the fact.
{quote}
No. It is important. The -1 er is using his technical insight as a 
justification for his -1. The incomplete comment shows how much time he really 
spent working on the given code. No tests, no argument checking, and a half 
done comment.


was (Author: appodictic):
{quote}
The project has always allowed ninja fixing minor (especially non-code) things. 
Comments here are a net positive. There's no reason to fight about adding 
comments after the fact.
{quote}
No. It is important. The -1 er is using his technical insight as a 
justification for his -1. The incomplete comment shows how much time he really 
spent working on the given code. 

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Edward Capriolo (JIRA)]

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

Edward Capriolo commented on CASSANDRA-13396:
-

{quote}
The project has always allowed ninja fixing minor (especially non-code) things. 
Comments here are a net positive. There's no reason to fight about adding 
comments after the fact.
{quote}
No. It is important. The -1 er is using his technical insight as a 
justification for his -1. The incomplete comment shows how much time he really 
spent working on the given code. 

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Edward Capriolo (JIRA)]

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

Edward Capriolo commented on CASSANDRA-13396:
-

{quote}
Logging a warning for users isn't the same as throwing an exception. It's not 
like we're talking about a system property here that requires explicit operator 
involvement to even run with another logger, it's logging a single warning 
message that bugs may happen and we haven't actively tested other configs. I 
don't think that's unreasonable, and it's not "get off my lawn". This isn't an 
unreasonable compromise - we don't crash, but we give operators a chance to 
know that they're running an untested config.
{quote}

The "get off my lawn" is related to this entire process. It had not even 
checked who added the code originally. I did not quite understand why it got a 
-1 so fast. -1s are "rare" and kill the proposal dead.

https://www.apache.org/foundation/voting.html
For code-modification votes, +1 votes are in favour of the proposal, but -1 
votes are vetos and kill the proposal dead until all vetoers withdraw their -1 
votes.

The original reasons given were "This change will cause weird and hard to catch 
follow-up issues (see the discussions and issues around that piece code), which 
cannot be caught by neither unit nor dtests because it's an unsupported setup. 
We do not support embedding C* in a container (i.e. a JVM not controlled "by 
us")"

Lets break this down:
1) "This change will cause weird and hard to catch follow-up issues"
Hard to quantify and the statement itself is a hypothesis. Can "WILL CAUSE" be 
proven? No.

2) which cannot be caught by neither unit nor dtests because it's an 
unsupported setup
Even though we are SURE issues that "WILL HAPPEN" they "CANNOT BE CAUGHT" . 
Amazing how that logic works.

3) We do not support embedding C* in a container
Untrue. How does one run the CDC daemon? Not a written rule anyway.

If adding a single if statement to block of code and getting 3 completely 
ludicrous objections from the person who happened to write said code is not 
"get off my lawn" then I don't know what is.



> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Updated] (CASSANDRA-12042) Decouple messaging protocol versioning from individual message types

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-12042:
--
Reviewer:   (was: Aleksey Yeschenko)

> Decouple messaging protocol versioning from individual message types
> 
>
> Key: CASSANDRA-12042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12042
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Streaming and Messaging
>Reporter: Aleksey Yeschenko
>Assignee: Sylvain Lebresne
>Priority: Blocker
> Fix For: 4.0
>
>
> At the moment we have a single constant - 
> {{MessagingService.current_version}} defining serialization format for 
> *everything*, including every possible message type.
> In practice it means that any tiniest change to any message requires bumping 
> the global {{MessagingService}} version.
> This is problematic for several reasons, the primary of which is currently 
> the schema propagation barrier between differently versioned C* nodes. In 
> tick-tock world, it means that any change (say, to a read command message), 
> would require a messaging service bump, putting nodes on split versions of 
> the service, and making schema changes during this now considered minor 
> upgrade, impossible, which is not neat.
> I propose that starting with 4.0 we version all messages individually 
> instead, and separately version messaging service protocol itself - which 
> will basically amount to just framing, once CASSANDRA-8457 is completed.
> In practice, this might be implemented the following way:
> # We use an extra byte with each message to specify the version of that 
> particular message type encoding
> # Instead of relying on messaging service of the sending note (determining 
> which can be racy, especially during upgrades), we use that byte to determine 
> the version of the message during deserialisation
> # On sending side, we can use the gossipped version of Cassandra itself - not 
> the messaging service version - to determine the maximum supported message 
> type version of the destination node
> In the new world, I expect the framing protocol version to change very rarely 
> after 4.0, if ever, and most message types to change extremely rarely as 
> well, with schema, read, and write messages to change version most often.



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

[jira] [Updated] (CASSANDRA-10825) OverloadedException is untested

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10825:
--
Reviewer:   (was: Aleksey Yeschenko)

> OverloadedException is untested
> ---
>
> Key: CASSANDRA-10825
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10825
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Ariel Weisberg
> Attachments: jmx-hint.png
>
>
> If you grep test/src and cassandra-dtest you will find that the string 
> OverloadedException doesn't appear anywhere.
> In CASSANDRA-10477 it was found that there were cases where Paxos should 
> back-pressure and throw OverloadedException but didn't.
> If OverloadedException is used for functional purposes then we should test 
> that it is thrown under expected conditions. If there are behaviors driven by 
> catching or tracking OverloadedException we should test those as well.



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

[jira] [Updated] (CASSANDRA-13405) ViewBuilder can miss data due to sstable generation filter

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-13405:

Reviewer: Paulo Motta

> ViewBuilder can miss data due to sstable generation filter
> --
>
> Key: CASSANDRA-13405
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13405
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
>  Labels: materializedviews
> Fix For: 3.0.13
>
>
> The view builder for one MV is restarted when other MVs are added on the same 
> keyspace.  There is an issue if compactions are running between these 
> restarts that can cause the view builder to skip data, since the builder 
> tracks the max sstable generation to filter by when it starts back up.
> I don't see a need for this generation tracking across restarts, it only 
> needs to be tracked during a builders life (to avoid adding in newly 
> compacted data).  



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

[jira] [Updated] (CASSANDRA-13405) ViewBuilder can miss data due to sstable generation filter

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-13405:
---
Description: 
The view builder for one MV is restarted when other MVs are added on the same 
keyspace.  There is an issue if compactions are running between these restarts 
that can cause the view builder to skip data, since the builder tracks the max 
sstable generation to filter by when it starts back up.

I don't see a need for this generation tracking across restarts, it only needs 
to be tracked during a builders life (to avoid adding in newly compacted data). 
 



  was:
The view builder for one MV is restarted when other MVs are added on the same 
keyspace.  There is an issue if compactions are running between these restarts 
that can cause the view build is lost since the builder tracks the max sstable 
generation to filter by when it starts back up.

I don't see a need for this generation tracking across restarts, it only needs 
to be tracked during a builders life (to avoid adding in newly compacted data). 
 




> ViewBuilder can miss data due to sstable generation filter
> --
>
> Key: CASSANDRA-13405
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13405
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
>  Labels: materializedviews
> Fix For: 3.0.13
>
>
> The view builder for one MV is restarted when other MVs are added on the same 
> keyspace.  There is an issue if compactions are running between these 
> restarts that can cause the view builder to skip data, since the builder 
> tracks the max sstable generation to filter by when it starts back up.
> I don't see a need for this generation tracking across restarts, it only 
> needs to be tracked during a builders life (to avoid adding in newly 
> compacted data).  



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

[jira] [Updated] (CASSANDRA-13405) ViewBuilder can miss data due to sstable generation filter

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-13405:
---
Description: 
The view builder for one MV is restarted when other MVs are added on the same 
keyspace.  There is an issue if compactions are running between these restarts 
that can cause the view build is lost since the builder tracks the max sstable 
generation to filter by when it starts back up.

I don't see a need for this generation tracking across restarts, it only needs 
to be tracked during a builders life (to avoid adding in newly compacted data). 
 



  was:
The view builder for one MV is restarted when other MVs are added on the same 
keyspace.  There is an issue if compaction are running between these restarts 
that can cause the view build is lost since the builder tracks the max sstable 
generation to filter by when it starts back up.

I don't see a need for this generation tracking across restarts, it only needs 
to be tracked during a builders life (to avoid adding in newly compacted data). 
 




> ViewBuilder can miss data due to sstable generation filter
> --
>
> Key: CASSANDRA-13405
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13405
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
>  Labels: materializedviews
> Fix For: 3.0.13
>
>
> The view builder for one MV is restarted when other MVs are added on the same 
> keyspace.  There is an issue if compactions are running between these 
> restarts that can cause the view build is lost since the builder tracks the 
> max sstable generation to filter by when it starts back up.
> I don't see a need for this generation tracking across restarts, it only 
> needs to be tracked during a builders life (to avoid adding in newly 
> compacted data).  



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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Edward Capriolo (JIRA)]

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

Edward Capriolo commented on CASSANDRA-13396:
-

A true cassandra special. A patch with a dubious ClassCastException and a half 
finished comment passed a review, and now the next person who touches the code 
needs to "sufficiently test" to earn the "officially supported" designation 
only granted to committers that make statements like "We do not support 
embedding C* in a container " and ninja fix stuff.

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Edward Capriolo (JIRA)]

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

Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 6:40 PM:
-

A true cassandra special. A patch with a dubious ClassCastException and a half 
finished comment passed a review, and now the next person who touches the code 
needs to "sufficiently test" to earn the "officially supported" designation 
only granted to committers that make untrue statements like "We do not support 
embedding C* in a container " and ninja fix stuff.


was (Author: appodictic):
A true cassandra special. A patch with a dubious ClassCastException and a half 
finished comment passed a review, and now the next person who touches the code 
needs to "sufficiently test" to earn the "officially supported" designation 
only granted to committers that make statements like "We do not support 
embedding C* in a container " and ninja fix stuff.

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13396:


{quote}
How does meritocracy work when we spend globs of time striking down patches, 
while simultaneously 'ninja fixing' stuff? Go make a patch and get it reviewed 
like everyone else.
{quote}

The project has always allowed ninja fixing minor (especially non-code) things. 
Comments here are a net positive. There's no reason to fight about adding 
comments after the fact. 

{quote}
This directly translates to "No one can edit the buggy code I introduced 
because THEY might make bugs."
{quote}

Logging a warning for users isn't the same as throwing an exception. It's not 
like we're talking about a system property here that requires explicit operator 
involvement to even run with another logger, it's logging a single warning 
message that bugs may happen and we haven't actively tested other configs. I 
don't think that's unreasonable, and it's not "get off my lawn". This isn't an 
unreasonable compromise - we don't crash, but we give operators a chance to 
know that they're running an untested config. 

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

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

[Ben Bromhead (JIRA)]

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

Ben Bromhead commented on CASSANDRA-11471:
--

I've created a new Jira for the Datastax Java Driver 
(https://datastax-oss.atlassian.net/browse/JAVA-1434), I'll look to do one for 
the Python driver as well as iirc cqlsh depends on it.

Updated to address nits:
* Authenticator flow is now only for v5 and up
* Spelling error in IAuthenticator

Any thoughts on passing null certs vs an extra method in the IAuthenticator?

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



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

[jira] [Updated] (CASSANDRA-13405) ViewBuilder can miss data due to sstable generation filter

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-13405:
---
Component/s: Local Write-Read Paths

> ViewBuilder can miss data due to sstable generation filter
> --
>
> Key: CASSANDRA-13405
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13405
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
>  Labels: materializedviews
> Fix For: 3.0.13
>
>
> The view builder for one MV is restarted when other MVs are added on the same 
> keyspace.  There is an issue if compaction are running between these restarts 
> that can cause the view build is lost since the builder tracks the max 
> sstable generation to filter by when it starts back up.
> I don't see a need for this generation tracking across restarts, it only 
> needs to be tracked during a builders life (to avoid adding in newly 
> compacted data).  



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

[jira] [Updated] (CASSANDRA-13405) ViewBuilder can miss data due to sstable generation filter

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-13405:
---
Labels: materializedviews  (was: )

> ViewBuilder can miss data due to sstable generation filter
> --
>
> Key: CASSANDRA-13405
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13405
> Project: Cassandra
>  Issue Type: Bug
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
>  Labels: materializedviews
> Fix For: 3.0.13
>
>
> The view builder for one MV is restarted when other MVs are added on the same 
> keyspace.  There is an issue if compaction are running between these restarts 
> that can cause the view build is lost since the builder tracks the max 
> sstable generation to filter by when it starts back up.
> I don't see a need for this generation tracking across restarts, it only 
> needs to be tracked during a builders life (to avoid adding in newly 
> compacted data).  



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

[jira] [Comment Edited] (CASSANDRA-13405) ViewBuilder can miss data due to sstable generation filter

[T Jake Luciani (JIRA)]

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

T Jake Luciani edited comment on CASSANDRA-13405 at 4/3/17 6:25 PM:


Fix with test to repro.
Basically ignore the generation value...

I've also added some better debug logging to help operators and us see what's 
happening.

[3.0|https://github.com/tjake/cassandra/tree/13405-3.0]
[testall|http://cassci.datastax.com/view/Dev/view/tjake/job/tjake-13405-3.0-testall/]
[dtest|http://cassci.datastax.com/view/Dev/view/tjake/job/tjake-13405-3.0-dtest/]


[3.11|https://github.com/tjake/cassandra/tree/13405-3.11]
[testall|http://cassci.datastax.com/view/Dev/view/tjake/job/tjake-13405-3.11-testall/]
[dtest|http://cassci.datastax.com/view/Dev/view/tjake/job/tjake-13405-3.11-dtest/]


was (Author: tjake):
Fix with test to repro.
Basically ignore the generation value...

I've also added some better debug logging to help operators and us see what's 
happening.

[3.0|https://github.com/tjake/cassandra/tree/13405-3.0]
[testall|cassci.datastax.com/view/Dev/view/tjake/job/tjake-13405-3.0-testall/]
[dtest|cassci.datastax.com/view/Dev/view/tjake/job/tjake-13405-3.0-dtest/]


[3.11|https://github.com/tjake/cassandra/tree/13405-3.11]
[testall|cassci.datastax.com/view/Dev/view/tjake/job/tjake-13405-3.11-testall/]
[dtest|cassci.datastax.com/view/Dev/view/tjake/job/tjake-13405-3.11-dtest/]

> ViewBuilder can miss data due to sstable generation filter
> --
>
> Key: CASSANDRA-13405
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13405
> Project: Cassandra
>  Issue Type: Bug
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
>  Labels: materializedviews
> Fix For: 3.0.13
>
>
> The view builder for one MV is restarted when other MVs are added on the same 
> keyspace.  There is an issue if compaction are running between these restarts 
> that can cause the view build is lost since the builder tracks the max 
> sstable generation to filter by when it starts back up.
> I don't see a need for this generation tracking across restarts, it only 
> needs to be tracked during a builders life (to avoid adding in newly 
> compacted data).  



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

[jira] [Updated] (CASSANDRA-13405) ViewBuilder can miss data due to sstable generation filter

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-13405:
---
Status: Patch Available  (was: Open)

Fix with test to repro.
Basically ignore the generation value...

I've also added some better debug logging to help operators and us see what's 
happening.

[3.0|https://github.com/tjake/cassandra/tree/13405-3.0]
[testall|cassci.datastax.com/view/Dev/view/tjake/job/tjake-13405-3.0-testall/]
[dtest|cassci.datastax.com/view/Dev/view/tjake/job/tjake-13405-3.0-dtest/]


[3.11|https://github.com/tjake/cassandra/tree/13405-3.11]
[testall|cassci.datastax.com/view/Dev/view/tjake/job/tjake-13405-3.11-testall/]
[dtest|cassci.datastax.com/view/Dev/view/tjake/job/tjake-13405-3.11-dtest/]

> ViewBuilder can miss data due to sstable generation filter
> --
>
> Key: CASSANDRA-13405
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13405
> Project: Cassandra
>  Issue Type: Bug
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
> Fix For: 3.0.13
>
>
> The view builder for one MV is restarted when other MVs are added on the same 
> keyspace.  There is an issue if compaction are running between these restarts 
> that can cause the view build is lost since the builder tracks the max 
> sstable generation to filter by when it starts back up.
> I don't see a need for this generation tracking across restarts, it only 
> needs to be tracked during a builders life (to avoid adding in newly 
> compacted data).  



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

[jira] [Updated] (CASSANDRA-13020) Hint delivery fails when prefer_local enabled

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13020:
---
   Resolution: Fixed
Fix Version/s: 4.0
   3.11.0
   3.0.13
   Status: Resolved  (was: Ready to Commit)

Thanks for the ping! 
Merged as 2e36eb6ca38dd018e7ef0cda61d43ec9a7eb144c

> Hint delivery fails when prefer_local enabled
> -
>
> Key: CASSANDRA-13020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13020
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: v3.0.9
>Reporter: Aleksandr Ivanov
>Assignee: Stefan Podkowinski
>  Labels: decommission, hints
> Fix For: 3.0.13, 3.11.0, 4.0
>
>
> I tried to decommission one node.
> Node sent all data to another node and got stuck in LEAVING state.
> Log message shows Exception in HintsDispatcher thread.
> Could it be reason of stuck in LEAVING state?
> command output:
> {noformat}
> root@cas-node6:~# time nodetool decommission
> error: null
> -- StackTrace --
> java.lang.NullPointerException
> at 
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at 
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:203)
> at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3566)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at 
> org.apache.cassandra.hints.HintsDispatchExecutor$TransferHintsTask.transfer(HintsDispatchExecutor.java:168)
> at 
> org.apache.cassandra.hints.HintsDispatchExecutor$TransferHintsTask.run(HintsDispatchExecutor.java:141)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> real147m7.483s
> user0m17.388s
> sys 0m1.968s
> {noformat}
> nodetool netstats:
> {noformat}
> root@cas-node6:~# nodetool netstats
> Mode: LEAVING
> Not sending any streams.
> Read Repair Statistics:
> Attempted: 35082
> Mismatch (Blocking): 18
> Mismatch (Background): 0
> Pool NameActive   Pending  Completed   Dropped
> Large messages  n/a 1  0 0
> Small messages  n/a 0   16109860   112
> Gossip messages n/a 0 287074 0
> {noformat}
> Log:
> {noformat}
> INFO  [RMI TCP Connection(58)-127.0.0.1] 2016-12-07 12:52:59,467 
> StorageService.java:1170 - LEAVING: sleeping 3 ms for batch processing 
> and pending range setup
> INFO  [RMI TCP Connection(58)-127.0.0.1] 2016-12-07 12:53:39,455 
> StorageService.java:1170 - LEAVING: replaying batch log and streaming data to 
> other nodes
> INFO  [RMI TCP Connection(58)-127.0.0.1] 2016-12-07 12:53:39,910 
> StreamResultFuture.java:87 - [Stream #2cc874c0-bc7c-11e6-b0df-e7f1ecd3dcfb] 
> Executing streaming plan for Unbootstrap
> INFO  [StreamConnectionEstablisher:1] 2016-12-07 12:53:39,911 
> StreamSession.java:239 - [Stream #2cc874c0-bc7c-11e6-b0df-e7f1ecd3dcfb] 
> Starting streaming to /10.10.10.17
> INFO  [StreamConnectionEstablisher:2] 2016-12-07 12:53:39,911 
> StreamSession.java:232 - [Stream #2cc874c0-bc7c-11e6-b0df-e7f1ecd3dcfb] 
> Session does not have any tasks.
> INFO  [StreamConnectionEstablisher:3] 2016-12-07 12:53:39,912 
> StreamSession.java:232 - [Stream #2cc874c0-bc7c-11e6-b0df-e7f1ecd3dcfb] 
> Session does not have any tasks.
> INFO  [StreamConnectionEstablisher:4] 2016-12-07 12:53:39,912 
> StreamSession.java:232 - [Stream #2cc874c0-bc7c-11e6-b0df-e7f1ecd3dcfb] 
> Session does not have any tasks.
> INFO  [RMI TCP Connection(58)-127.0.0.1] 

[1/6] cassandra git commit: Fix hint delivery when prefer_local enabled

[spod]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 13e6699da -> 2e36eb6ca
  refs/heads/cassandra-3.11 05a0658d7 -> 420c91c9a
  refs/heads/trunk 39bca4813 -> ab7aa57b3


Fix hint delivery when prefer_local enabled

patch by Stefan Podkowinski; reviewed by Aleksey Yeschenko for CASSANDRA-13020


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

Branch: refs/heads/cassandra-3.0
Commit: 2e36eb6ca38dd018e7ef0cda61d43ec9a7eb144c
Parents: 13e6699
Author: Stefan Podkowinski 
Authored: Fri Mar 10 14:34:29 2017 +0100
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 20:10:52 2017 +0200

--
 CHANGES.txt   | 1 +
 src/java/org/apache/cassandra/service/StorageService.java | 3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2e36eb6c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 371abed..41489c1 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.13
+ * Fix hint delivery when using ext+internal IPs with prefer_local enabled 
(CASSANDRA-13020)
  * Fix possible NPE on upgrade to 3.0/3.X in case of IO errors 
(CASSANDRA-13389)
  * Legacy deserializer can create empty range tombstones (CASSANDRA-13341)
  * Use the Kernel32 library to retrieve the PID on Windows and fix startup 
checks (CASSANDRA-1)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2e36eb6c/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index 6760040..aa3407b 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -3655,8 +3655,7 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 // stream to the closest peer as chosen by the snitch
 
DatabaseDescriptor.getEndpointSnitch().sortByProximity(FBUtilities.getBroadcastAddress(),
 candidates);
 InetAddress hintsDestinationHost = candidates.get(0);
-InetAddress preferred = 
SystemKeyspace.getPreferredIP(hintsDestinationHost);
-return tokenMetadata.getHostId(preferred);
+return tokenMetadata.getHostId(hintsDestinationHost);
 }
 }
 

[3/6] cassandra git commit: Fix hint delivery when prefer_local enabled

[spod]

Fix hint delivery when prefer_local enabled

patch by Stefan Podkowinski; reviewed by Aleksey Yeschenko for CASSANDRA-13020


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

Branch: refs/heads/trunk
Commit: 2e36eb6ca38dd018e7ef0cda61d43ec9a7eb144c
Parents: 13e6699
Author: Stefan Podkowinski 
Authored: Fri Mar 10 14:34:29 2017 +0100
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 20:10:52 2017 +0200

--
 CHANGES.txt   | 1 +
 src/java/org/apache/cassandra/service/StorageService.java | 3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2e36eb6c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 371abed..41489c1 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.13
+ * Fix hint delivery when using ext+internal IPs with prefer_local enabled 
(CASSANDRA-13020)
  * Fix possible NPE on upgrade to 3.0/3.X in case of IO errors 
(CASSANDRA-13389)
  * Legacy deserializer can create empty range tombstones (CASSANDRA-13341)
  * Use the Kernel32 library to retrieve the PID on Windows and fix startup 
checks (CASSANDRA-1)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2e36eb6c/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index 6760040..aa3407b 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -3655,8 +3655,7 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 // stream to the closest peer as chosen by the snitch
 
DatabaseDescriptor.getEndpointSnitch().sortByProximity(FBUtilities.getBroadcastAddress(),
 candidates);
 InetAddress hintsDestinationHost = candidates.get(0);
-InetAddress preferred = 
SystemKeyspace.getPreferredIP(hintsDestinationHost);
-return tokenMetadata.getHostId(preferred);
+return tokenMetadata.getHostId(hintsDestinationHost);
 }
 }
 

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

[spod]

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

Branch: refs/heads/trunk
Commit: 420c91c9ab5702305886ce0c06dda97d4c382fe6
Parents: 05a0658 2e36eb6
Author: Stefan Podkowinski 
Authored: Mon Apr 3 20:12:34 2017 +0200
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 20:13:35 2017 +0200

--
 CHANGES.txt   | 1 +
 src/java/org/apache/cassandra/service/StorageService.java | 3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/420c91c9/CHANGES.txt
--
diff --cc CHANGES.txt
index 2408b8a,41489c1..fc7a2bb
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,27 -1,7 +1,28 @@@
 -3.0.13
 +3.11.0
 + * Fix testLimitSSTables flake caused by concurrent flush (CASSANDRA-12820)
 + * cdc column addition strikes again (CASSANDRA-13382)
 + * Fix static column indexes (CASSANDRA-13277) 
 + * DataOutputBuffer.asNewBuffer broken (CASSANDRA-13298)
 + * unittest CipherFactoryTest failed on MacOS (CASSANDRA-13370)
 + * Forbid SELECT restrictions and CREATE INDEX over non-frozen UDT columns 
(CASSANDRA-13247)
 + * Default logging we ship will incorrectly print "?:?" for "%F:%L" pattern 
(CASSANDRA-13317)
 + * Possible AssertionError in UnfilteredRowIteratorWithLowerBound 
(CASSANDRA-13366)
 + * Support unaligned memory access for AArch64 (CASSANDRA-13326)
 + * Improve SASI range iterator efficiency on intersection with an empty range 
(CASSANDRA-12915).
 + * Fix equality comparisons of columns using the duration type 
(CASSANDRA-13174)
 + * Obfuscate password in stress-graphs (CASSANDRA-12233)
 + * Move to FastThreadLocalThread and FastThreadLocal (CASSANDRA-13034)
 + * nodetool stopdaemon errors out (CASSANDRA-13030)
 + * Tables in system_distributed should not use gcgs of 0 (CASSANDRA-12954)
 + * Fix primary index calculation for SASI (CASSANDRA-12910)
 + * More fixes to the TokenAllocator (CASSANDRA-12990)
 + * NoReplicationTokenAllocator should work with zero replication factor 
(CASSANDRA-12983)
 + * Address message coalescing regression (CASSANDRA-12676)
 +Merged from 3.0:
+  * Fix hint delivery when using ext+internal IPs with prefer_local enabled 
(CASSANDRA-13020)
   * Fix possible NPE on upgrade to 3.0/3.X in case of IO errors 
(CASSANDRA-13389)
   * Legacy deserializer can create empty range tombstones (CASSANDRA-13341)
 + * Legacy caching options can prevent 3.0 upgrade (CASSANDRA-13384)
   * Use the Kernel32 library to retrieve the PID on Windows and fix startup 
checks (CASSANDRA-1)
   * Fix code to not exchange schema across major versions (CASSANDRA-13274)
   * Dropping column results in "corrupt" SSTable (CASSANDRA-13337)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/420c91c9/src/java/org/apache/cassandra/service/StorageService.java
--

[2/6] cassandra git commit: Fix hint delivery when prefer_local enabled

[spod]

Fix hint delivery when prefer_local enabled

patch by Stefan Podkowinski; reviewed by Aleksey Yeschenko for CASSANDRA-13020


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

Branch: refs/heads/cassandra-3.11
Commit: 2e36eb6ca38dd018e7ef0cda61d43ec9a7eb144c
Parents: 13e6699
Author: Stefan Podkowinski 
Authored: Fri Mar 10 14:34:29 2017 +0100
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 20:10:52 2017 +0200

--
 CHANGES.txt   | 1 +
 src/java/org/apache/cassandra/service/StorageService.java | 3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2e36eb6c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 371abed..41489c1 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.13
+ * Fix hint delivery when using ext+internal IPs with prefer_local enabled 
(CASSANDRA-13020)
  * Fix possible NPE on upgrade to 3.0/3.X in case of IO errors 
(CASSANDRA-13389)
  * Legacy deserializer can create empty range tombstones (CASSANDRA-13341)
  * Use the Kernel32 library to retrieve the PID on Windows and fix startup 
checks (CASSANDRA-1)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2e36eb6c/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index 6760040..aa3407b 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -3655,8 +3655,7 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 // stream to the closest peer as chosen by the snitch
 
DatabaseDescriptor.getEndpointSnitch().sortByProximity(FBUtilities.getBroadcastAddress(),
 candidates);
 InetAddress hintsDestinationHost = candidates.get(0);
-InetAddress preferred = 
SystemKeyspace.getPreferredIP(hintsDestinationHost);
-return tokenMetadata.getHostId(preferred);
+return tokenMetadata.getHostId(hintsDestinationHost);
 }
 }
 

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

[spod]

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

Branch: refs/heads/trunk
Commit: ab7aa57b376658e87a8fd4221ddc7712734ffcd8
Parents: 39bca48 420c91c
Author: Stefan Podkowinski 
Authored: Mon Apr 3 20:14:57 2017 +0200
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 20:15:23 2017 +0200

--
 CHANGES.txt   | 1 +
 src/java/org/apache/cassandra/service/StorageService.java | 3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ab7aa57b/CHANGES.txt
--
diff --cc CHANGES.txt
index 42e476f,fc7a2bb..3632903
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -69,6 -19,8 +69,7 @@@
   * NoReplicationTokenAllocator should work with zero replication factor 
(CASSANDRA-12983)
   * Address message coalescing regression (CASSANDRA-12676)
  Merged from 3.0:
+  * Fix hint delivery when using ext+internal IPs with prefer_local enabled 
(CASSANDRA-13020)
 - * Fix possible NPE on upgrade to 3.0/3.X in case of IO errors 
(CASSANDRA-13389)
   * Legacy deserializer can create empty range tombstones (CASSANDRA-13341)
   * Legacy caching options can prevent 3.0 upgrade (CASSANDRA-13384)
   * Use the Kernel32 library to retrieve the PID on Windows and fix startup 
checks (CASSANDRA-1)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ab7aa57b/src/java/org/apache/cassandra/service/StorageService.java
--

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

[spod]

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

Branch: refs/heads/cassandra-3.11
Commit: 420c91c9ab5702305886ce0c06dda97d4c382fe6
Parents: 05a0658 2e36eb6
Author: Stefan Podkowinski 
Authored: Mon Apr 3 20:12:34 2017 +0200
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 20:13:35 2017 +0200

--
 CHANGES.txt   | 1 +
 src/java/org/apache/cassandra/service/StorageService.java | 3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/420c91c9/CHANGES.txt
--
diff --cc CHANGES.txt
index 2408b8a,41489c1..fc7a2bb
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,27 -1,7 +1,28 @@@
 -3.0.13
 +3.11.0
 + * Fix testLimitSSTables flake caused by concurrent flush (CASSANDRA-12820)
 + * cdc column addition strikes again (CASSANDRA-13382)
 + * Fix static column indexes (CASSANDRA-13277) 
 + * DataOutputBuffer.asNewBuffer broken (CASSANDRA-13298)
 + * unittest CipherFactoryTest failed on MacOS (CASSANDRA-13370)
 + * Forbid SELECT restrictions and CREATE INDEX over non-frozen UDT columns 
(CASSANDRA-13247)
 + * Default logging we ship will incorrectly print "?:?" for "%F:%L" pattern 
(CASSANDRA-13317)
 + * Possible AssertionError in UnfilteredRowIteratorWithLowerBound 
(CASSANDRA-13366)
 + * Support unaligned memory access for AArch64 (CASSANDRA-13326)
 + * Improve SASI range iterator efficiency on intersection with an empty range 
(CASSANDRA-12915).
 + * Fix equality comparisons of columns using the duration type 
(CASSANDRA-13174)
 + * Obfuscate password in stress-graphs (CASSANDRA-12233)
 + * Move to FastThreadLocalThread and FastThreadLocal (CASSANDRA-13034)
 + * nodetool stopdaemon errors out (CASSANDRA-13030)
 + * Tables in system_distributed should not use gcgs of 0 (CASSANDRA-12954)
 + * Fix primary index calculation for SASI (CASSANDRA-12910)
 + * More fixes to the TokenAllocator (CASSANDRA-12990)
 + * NoReplicationTokenAllocator should work with zero replication factor 
(CASSANDRA-12983)
 + * Address message coalescing regression (CASSANDRA-12676)
 +Merged from 3.0:
+  * Fix hint delivery when using ext+internal IPs with prefer_local enabled 
(CASSANDRA-13020)
   * Fix possible NPE on upgrade to 3.0/3.X in case of IO errors 
(CASSANDRA-13389)
   * Legacy deserializer can create empty range tombstones (CASSANDRA-13341)
 + * Legacy caching options can prevent 3.0 upgrade (CASSANDRA-13384)
   * Use the Kernel32 library to retrieve the PID on Windows and fix startup 
checks (CASSANDRA-1)
   * Fix code to not exchange schema across major versions (CASSANDRA-13274)
   * Dropping column results in "corrupt" SSTable (CASSANDRA-13337)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/420c91c9/src/java/org/apache/cassandra/service/StorageService.java
--

[jira] [Updated] (CASSANDRA-13103) incorrect jvm metric names

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13103:
---
   Resolution: Fixed
Fix Version/s: (was: 3.11.x)
   (was: 3.9)
   4.0
   3.11.0
   3.0.13
   2.2.10
   Status: Resolved  (was: Ready to Commit)

Merged as a79cc9840d8c5a400e9838e0a366bb371ff5d918

> incorrect jvm metric names
> --
>
> Key: CASSANDRA-13103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13103
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability
>Reporter: Alain Rastoul
>Assignee: Alain Rastoul
>Priority: Minor
>  Labels: lhf
> Fix For: 2.2.10, 3.0.13, 3.11.0, 4.0
>
> Attachments: Fix-incorrect-jvm-metric-names-CASSANDRA-13103.patch
>
>
> Some jvm metrics have a double dot in name like:
> jvm.memory..total.max , jvm.memory..total.init (etc).
> it seems that an extra dot is added at the end of the name in 
> CassandraDaemon.java, around line 367 (in 3.0.10):
> ...
> // enable metrics provided by metrics-jvm.jar
> CassandraMetricsRegistry.Metrics.register("jvm.buffers.", new 
> BufferPoolMetricSet(ManagementFactory.getPlatformMBeanServer()));
> CassandraMetricsRegistry.Metrics.register("jvm.gc.", new 
> GarbageCollectorMetricSet());
> CassandraMetricsRegistry.Metrics.register("jvm.memory.", new 
> MemoryUsageGaugeSet());
> and also added in append method of MetricRegistry.
> Call stack is:
> MetricRegistry>>registerAll(String prefix, MetricSet metrics)
> MetricRegistry>>static String name(String name, String... names)
> MetricRegistry>>static void append(StringBuilder builder, String part)
> and in append the dot is also added:
> ...
> if(builder.length() > 0) {
> builder.append('.');
> }
> builder.append(part);
> ...
> The codahale MetricRegistry class seems to have no recent modification of 
> name or append methods, so it look like a small bug.
> May be the fix could be to simply not to add  the final dot in the metric 
> name, ie  "jvm.buffers"  instead of "jvm.buffers."



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

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

[spod]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/trunk
Commit: 13e6699da52ea68f49e04dcfe9d42db85c6701db
Parents: f45f55b a79cc98
Author: Stefan Podkowinski 
Authored: Mon Apr 3 19:58:56 2017 +0200
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 19:59:21 2017 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/service/CassandraDaemon.java | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/13e6699d/src/java/org/apache/cassandra/service/CassandraDaemon.java
--

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

[spod]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.0
Commit: 13e6699da52ea68f49e04dcfe9d42db85c6701db
Parents: f45f55b a79cc98
Author: Stefan Podkowinski 
Authored: Mon Apr 3 19:58:56 2017 +0200
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 19:59:21 2017 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/service/CassandraDaemon.java | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/13e6699d/src/java/org/apache/cassandra/service/CassandraDaemon.java
--

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

[spod]

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

Branch: refs/heads/trunk
Commit: 05a0658d7645d36b7414d44f11cda1dbee86e5f0
Parents: 5b77e04 13e6699
Author: Stefan Podkowinski 
Authored: Mon Apr 3 20:00:56 2017 +0200
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 20:01:09 2017 +0200

--
 CHANGES.txt |  1 +
 .../cassandra/service/CassandraDaemon.java  |  6 +--
 .../metrics/CassandraMetricsRegistryTest.java   | 47 +---
 3 files changed, 45 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/05a0658d/CHANGES.txt
--
diff --cc CHANGES.txt
index 3ead1d1,371abed..2408b8a
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -52,145 -57,6 +52,146 @@@ Merged from 3.0
 live rows in sstabledump (CASSANDRA-13177)
   * Provide user workaround when system_schema.columns does not contain entries
 for a table that's in system_schema.tables (CASSANDRA-13180)
 +Merged from 2.2:
++ * Fix JVM metric names (CASSANDRA-13103)
 + * Honor truststore-password parameter in cassandra-stress (CASSANDRA-12773)
 + * Discard in-flight shadow round responses (CASSANDRA-12653)
 + * Don't anti-compact repaired data to avoid inconsistencies (CASSANDRA-13153)
 + * Wrong logger name in AnticompactionTask (CASSANDRA-13343)
 + * Commitlog replay may fail if last mutation is within 4 bytes of end of 
segment (CASSANDRA-13282)
 + * Fix queries updating multiple time the same list (CASSANDRA-13130)
 + * Fix GRANT/REVOKE when keyspace isn't specified (CASSANDRA-13053)
 + * Fix flaky LongLeveledCompactionStrategyTest (CASSANDRA-12202)
 + * Fix failing COPY TO STDOUT (CASSANDRA-12497)
 + * Fix ColumnCounter::countAll behaviour for reverse queries (CASSANDRA-13222)
 + * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
 + * Fix negative mean latency metric (CASSANDRA-12876)
 + * Use only one file pointer when creating commitlog segments 
(CASSANDRA-12539)
 +Merged from 2.1:
 + * Remove unused repositories (CASSANDRA-13278)
 + * Log stacktrace of uncaught exceptions (CASSANDRA-13108)
 + * Use portable stderr for java error in startup (CASSANDRA-13211)
 + * Fix Thread Leak in OutboundTcpConnection (CASSANDRA-13204)
 + * Coalescing strategy can enter infinite loop (CASSANDRA-13159)
 +
 +
 +3.10
 + * Fix secondary index queries regression (CASSANDRA-13013)
 + * Add duration type to the protocol V5 (CASSANDRA-12850)
 + * Fix duration type validation (CASSANDRA-13143)
 + * Fix flaky GcCompactionTest (CASSANDRA-12664)
 + * Fix TestHintedHandoff.hintedhandoff_decom_test (CASSANDRA-13058)
 + * Fixed query monitoring for range queries (CASSANDRA-13050)
 + * Remove outboundBindAny configuration property (CASSANDRA-12673)
 + * Use correct bounds for all-data range when filtering (CASSANDRA-12666)
 + * Remove timing window in test case (CASSANDRA-12875)
 + * Resolve unit testing without JCE security libraries installed 
(CASSANDRA-12945)
 + * Fix inconsistencies in cassandra-stress load balancing policy 
(CASSANDRA-12919)
 + * Fix validation of non-frozen UDT cells (CASSANDRA-12916)
 + * Don't shut down socket input/output on StreamSession (CASSANDRA-12903)
 + * Fix Murmur3PartitionerTest (CASSANDRA-12858)
 + * Move cqlsh syntax rules into separate module and allow easier 
customization (CASSANDRA-12897)
 + * Fix CommitLogSegmentManagerTest (CASSANDRA-12283)
 + * Fix cassandra-stress truncate option (CASSANDRA-12695)
 + * Fix crossNode value when receiving messages (CASSANDRA-12791)
 + * Don't load MX4J beans twice (CASSANDRA-12869)
 + * Extend native protocol request flags, add versions to SUPPORTED, and 
introduce ProtocolVersion enum (CASSANDRA-12838)
 + * Set JOINING mode when running pre-join tasks (CASSANDRA-12836)
 + * remove net.mintern.primitive library due to license issue (CASSANDRA-12845)
 + * Properly format IPv6 addresses when logging JMX service URL 
(CASSANDRA-12454)
 + * Optimize the vnode allocation for single replica per DC (CASSANDRA-12777)
 + * Use non-token restrictions for bounds when token restrictions are 
overridden (CASSANDRA-12419)
 + * Fix CQLSH auto completion for PER PARTITION LIMIT (CASSANDRA-12803)
 + * Use different build directories for Eclipse and Ant (CASSANDRA-12466)
 + * Avoid potential AttributeError in cqlsh due to no table metadata 
(CASSANDRA-12815)
 + * Fix RandomReplicationAwareTokenAllocatorTest.testExistingCluster 
(CASSANDRA-12812)
 + * Upgrade commons-codec to 1.9 

[02/10] cassandra git commit: Fix incorrect jvm metric names

[spod]

Fix incorrect jvm metric names

patch by Alain Rastoul; reviewed by Stefan Podkowinski for CASSANDRA-13103


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

Branch: refs/heads/cassandra-3.0
Commit: a79cc9840d8c5a400e9838e0a366bb371ff5d918
Parents: e5a5fb9
Author: Alain Rastoul 
Authored: Sun Jan 8 00:46:39 2017 +0100
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 19:57:21 2017 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/service/CassandraDaemon.java | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a79cc984/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a415395..c77576b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.10
+ * Fix JVM metric paths (CASSANDRA-13103)
  * Honor truststore-password parameter in cassandra-stress (CASSANDRA-12773)
  * Discard in-flight shadow round responses (CASSANDRA-12653)
  * Don't anti-compact repaired data to avoid inconsistencies (CASSANDRA-13153)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a79cc984/src/java/org/apache/cassandra/service/CassandraDaemon.java
--
diff --git a/src/java/org/apache/cassandra/service/CassandraDaemon.java 
b/src/java/org/apache/cassandra/service/CassandraDaemon.java
index e342389..18b568d 100644
--- a/src/java/org/apache/cassandra/service/CassandraDaemon.java
+++ b/src/java/org/apache/cassandra/service/CassandraDaemon.java
@@ -325,9 +325,9 @@ public class CassandraDaemon
 try
 {
 // enable metrics provided by metrics-jvm.jar
-CassandraMetricsRegistry.Metrics.register("jvm.buffers.", new 
BufferPoolMetricSet(ManagementFactory.getPlatformMBeanServer()));
-CassandraMetricsRegistry.Metrics.register("jvm.gc.", new 
GarbageCollectorMetricSet());
-CassandraMetricsRegistry.Metrics.register("jvm.memory.", new 
MemoryUsageGaugeSet());
+CassandraMetricsRegistry.Metrics.register("jvm.buffers", new 
BufferPoolMetricSet(ManagementFactory.getPlatformMBeanServer()));
+CassandraMetricsRegistry.Metrics.register("jvm.gc", new 
GarbageCollectorMetricSet());
+CassandraMetricsRegistry.Metrics.register("jvm.memory", new 
MemoryUsageGaugeSet());
 CassandraMetricsRegistry.Metrics.register("jvm.fd.usage", new 
FileDescriptorRatioGauge());
 // initialize metrics-reporter-config from yaml file
 String reportFileLocation = 
CassandraDaemon.class.getClassLoader().getResource(metricsReporterConfigFile).getFile();

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

[spod]

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

Branch: refs/heads/trunk
Commit: 39bca48134e6ccc9f60ae0b0846bd9c47b672080
Parents: c824165 05a0658
Author: Stefan Podkowinski 
Authored: Mon Apr 3 20:02:11 2017 +0200
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 20:02:30 2017 +0200

--
 CHANGES.txt |  1 +
 .../cassandra/service/CassandraDaemon.java  |  6 +--
 .../metrics/CassandraMetricsRegistryTest.java   | 47 +---
 3 files changed, 45 insertions(+), 9 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/39bca481/src/java/org/apache/cassandra/service/CassandraDaemon.java
--

[04/10] cassandra git commit: Fix incorrect jvm metric names

[spod]

Fix incorrect jvm metric names

patch by Alain Rastoul; reviewed by Stefan Podkowinski for CASSANDRA-13103


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

Branch: refs/heads/trunk
Commit: a79cc9840d8c5a400e9838e0a366bb371ff5d918
Parents: e5a5fb9
Author: Alain Rastoul 
Authored: Sun Jan 8 00:46:39 2017 +0100
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 19:57:21 2017 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/service/CassandraDaemon.java | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a79cc984/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a415395..c77576b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.10
+ * Fix JVM metric paths (CASSANDRA-13103)
  * Honor truststore-password parameter in cassandra-stress (CASSANDRA-12773)
  * Discard in-flight shadow round responses (CASSANDRA-12653)
  * Don't anti-compact repaired data to avoid inconsistencies (CASSANDRA-13153)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a79cc984/src/java/org/apache/cassandra/service/CassandraDaemon.java
--
diff --git a/src/java/org/apache/cassandra/service/CassandraDaemon.java 
b/src/java/org/apache/cassandra/service/CassandraDaemon.java
index e342389..18b568d 100644
--- a/src/java/org/apache/cassandra/service/CassandraDaemon.java
+++ b/src/java/org/apache/cassandra/service/CassandraDaemon.java
@@ -325,9 +325,9 @@ public class CassandraDaemon
 try
 {
 // enable metrics provided by metrics-jvm.jar
-CassandraMetricsRegistry.Metrics.register("jvm.buffers.", new 
BufferPoolMetricSet(ManagementFactory.getPlatformMBeanServer()));
-CassandraMetricsRegistry.Metrics.register("jvm.gc.", new 
GarbageCollectorMetricSet());
-CassandraMetricsRegistry.Metrics.register("jvm.memory.", new 
MemoryUsageGaugeSet());
+CassandraMetricsRegistry.Metrics.register("jvm.buffers", new 
BufferPoolMetricSet(ManagementFactory.getPlatformMBeanServer()));
+CassandraMetricsRegistry.Metrics.register("jvm.gc", new 
GarbageCollectorMetricSet());
+CassandraMetricsRegistry.Metrics.register("jvm.memory", new 
MemoryUsageGaugeSet());
 CassandraMetricsRegistry.Metrics.register("jvm.fd.usage", new 
FileDescriptorRatioGauge());
 // initialize metrics-reporter-config from yaml file
 String reportFileLocation = 
CassandraDaemon.class.getClassLoader().getResource(metricsReporterConfigFile).getFile();

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

[spod]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.11
Commit: 13e6699da52ea68f49e04dcfe9d42db85c6701db
Parents: f45f55b a79cc98
Author: Stefan Podkowinski 
Authored: Mon Apr 3 19:58:56 2017 +0200
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 19:59:21 2017 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/service/CassandraDaemon.java | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/13e6699d/src/java/org/apache/cassandra/service/CassandraDaemon.java
--

[03/10] cassandra git commit: Fix incorrect jvm metric names

[spod]

Fix incorrect jvm metric names

patch by Alain Rastoul; reviewed by Stefan Podkowinski for CASSANDRA-13103


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

Branch: refs/heads/cassandra-3.11
Commit: a79cc9840d8c5a400e9838e0a366bb371ff5d918
Parents: e5a5fb9
Author: Alain Rastoul 
Authored: Sun Jan 8 00:46:39 2017 +0100
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 19:57:21 2017 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/service/CassandraDaemon.java | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a79cc984/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a415395..c77576b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.10
+ * Fix JVM metric paths (CASSANDRA-13103)
  * Honor truststore-password parameter in cassandra-stress (CASSANDRA-12773)
  * Discard in-flight shadow round responses (CASSANDRA-12653)
  * Don't anti-compact repaired data to avoid inconsistencies (CASSANDRA-13153)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a79cc984/src/java/org/apache/cassandra/service/CassandraDaemon.java
--
diff --git a/src/java/org/apache/cassandra/service/CassandraDaemon.java 
b/src/java/org/apache/cassandra/service/CassandraDaemon.java
index e342389..18b568d 100644
--- a/src/java/org/apache/cassandra/service/CassandraDaemon.java
+++ b/src/java/org/apache/cassandra/service/CassandraDaemon.java
@@ -325,9 +325,9 @@ public class CassandraDaemon
 try
 {
 // enable metrics provided by metrics-jvm.jar
-CassandraMetricsRegistry.Metrics.register("jvm.buffers.", new 
BufferPoolMetricSet(ManagementFactory.getPlatformMBeanServer()));
-CassandraMetricsRegistry.Metrics.register("jvm.gc.", new 
GarbageCollectorMetricSet());
-CassandraMetricsRegistry.Metrics.register("jvm.memory.", new 
MemoryUsageGaugeSet());
+CassandraMetricsRegistry.Metrics.register("jvm.buffers", new 
BufferPoolMetricSet(ManagementFactory.getPlatformMBeanServer()));
+CassandraMetricsRegistry.Metrics.register("jvm.gc", new 
GarbageCollectorMetricSet());
+CassandraMetricsRegistry.Metrics.register("jvm.memory", new 
MemoryUsageGaugeSet());
 CassandraMetricsRegistry.Metrics.register("jvm.fd.usage", new 
FileDescriptorRatioGauge());
 // initialize metrics-reporter-config from yaml file
 String reportFileLocation = 
CassandraDaemon.class.getClassLoader().getResource(metricsReporterConfigFile).getFile();

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

[spod]

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

Branch: refs/heads/cassandra-3.11
Commit: 05a0658d7645d36b7414d44f11cda1dbee86e5f0
Parents: 5b77e04 13e6699
Author: Stefan Podkowinski 
Authored: Mon Apr 3 20:00:56 2017 +0200
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 20:01:09 2017 +0200

--
 CHANGES.txt |  1 +
 .../cassandra/service/CassandraDaemon.java  |  6 +--
 .../metrics/CassandraMetricsRegistryTest.java   | 47 +---
 3 files changed, 45 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/05a0658d/CHANGES.txt
--
diff --cc CHANGES.txt
index 3ead1d1,371abed..2408b8a
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -52,145 -57,6 +52,146 @@@ Merged from 3.0
 live rows in sstabledump (CASSANDRA-13177)
   * Provide user workaround when system_schema.columns does not contain entries
 for a table that's in system_schema.tables (CASSANDRA-13180)
 +Merged from 2.2:
++ * Fix JVM metric names (CASSANDRA-13103)
 + * Honor truststore-password parameter in cassandra-stress (CASSANDRA-12773)
 + * Discard in-flight shadow round responses (CASSANDRA-12653)
 + * Don't anti-compact repaired data to avoid inconsistencies (CASSANDRA-13153)
 + * Wrong logger name in AnticompactionTask (CASSANDRA-13343)
 + * Commitlog replay may fail if last mutation is within 4 bytes of end of 
segment (CASSANDRA-13282)
 + * Fix queries updating multiple time the same list (CASSANDRA-13130)
 + * Fix GRANT/REVOKE when keyspace isn't specified (CASSANDRA-13053)
 + * Fix flaky LongLeveledCompactionStrategyTest (CASSANDRA-12202)
 + * Fix failing COPY TO STDOUT (CASSANDRA-12497)
 + * Fix ColumnCounter::countAll behaviour for reverse queries (CASSANDRA-13222)
 + * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
 + * Fix negative mean latency metric (CASSANDRA-12876)
 + * Use only one file pointer when creating commitlog segments 
(CASSANDRA-12539)
 +Merged from 2.1:
 + * Remove unused repositories (CASSANDRA-13278)
 + * Log stacktrace of uncaught exceptions (CASSANDRA-13108)
 + * Use portable stderr for java error in startup (CASSANDRA-13211)
 + * Fix Thread Leak in OutboundTcpConnection (CASSANDRA-13204)
 + * Coalescing strategy can enter infinite loop (CASSANDRA-13159)
 +
 +
 +3.10
 + * Fix secondary index queries regression (CASSANDRA-13013)
 + * Add duration type to the protocol V5 (CASSANDRA-12850)
 + * Fix duration type validation (CASSANDRA-13143)
 + * Fix flaky GcCompactionTest (CASSANDRA-12664)
 + * Fix TestHintedHandoff.hintedhandoff_decom_test (CASSANDRA-13058)
 + * Fixed query monitoring for range queries (CASSANDRA-13050)
 + * Remove outboundBindAny configuration property (CASSANDRA-12673)
 + * Use correct bounds for all-data range when filtering (CASSANDRA-12666)
 + * Remove timing window in test case (CASSANDRA-12875)
 + * Resolve unit testing without JCE security libraries installed 
(CASSANDRA-12945)
 + * Fix inconsistencies in cassandra-stress load balancing policy 
(CASSANDRA-12919)
 + * Fix validation of non-frozen UDT cells (CASSANDRA-12916)
 + * Don't shut down socket input/output on StreamSession (CASSANDRA-12903)
 + * Fix Murmur3PartitionerTest (CASSANDRA-12858)
 + * Move cqlsh syntax rules into separate module and allow easier 
customization (CASSANDRA-12897)
 + * Fix CommitLogSegmentManagerTest (CASSANDRA-12283)
 + * Fix cassandra-stress truncate option (CASSANDRA-12695)
 + * Fix crossNode value when receiving messages (CASSANDRA-12791)
 + * Don't load MX4J beans twice (CASSANDRA-12869)
 + * Extend native protocol request flags, add versions to SUPPORTED, and 
introduce ProtocolVersion enum (CASSANDRA-12838)
 + * Set JOINING mode when running pre-join tasks (CASSANDRA-12836)
 + * remove net.mintern.primitive library due to license issue (CASSANDRA-12845)
 + * Properly format IPv6 addresses when logging JMX service URL 
(CASSANDRA-12454)
 + * Optimize the vnode allocation for single replica per DC (CASSANDRA-12777)
 + * Use non-token restrictions for bounds when token restrictions are 
overridden (CASSANDRA-12419)
 + * Fix CQLSH auto completion for PER PARTITION LIMIT (CASSANDRA-12803)
 + * Use different build directories for Eclipse and Ant (CASSANDRA-12466)
 + * Avoid potential AttributeError in cqlsh due to no table metadata 
(CASSANDRA-12815)
 + * Fix RandomReplicationAwareTokenAllocatorTest.testExistingCluster 
(CASSANDRA-12812)
 + * Upgrade commons-codec to 1.9 

[01/10] cassandra git commit: Fix incorrect jvm metric names

[spod]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 e5a5fb96c -> a79cc9840
  refs/heads/cassandra-3.0 f45f55b55 -> 13e6699da
  refs/heads/cassandra-3.11 5b77e04a6 -> 05a0658d7
  refs/heads/trunk c8241659e -> 39bca4813


Fix incorrect jvm metric names

patch by Alain Rastoul; reviewed by Stefan Podkowinski for CASSANDRA-13103


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

Branch: refs/heads/cassandra-2.2
Commit: a79cc9840d8c5a400e9838e0a366bb371ff5d918
Parents: e5a5fb9
Author: Alain Rastoul 
Authored: Sun Jan 8 00:46:39 2017 +0100
Committer: Stefan Podkowinski 
Committed: Mon Apr 3 19:57:21 2017 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/service/CassandraDaemon.java | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a79cc984/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a415395..c77576b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.10
+ * Fix JVM metric paths (CASSANDRA-13103)
  * Honor truststore-password parameter in cassandra-stress (CASSANDRA-12773)
  * Discard in-flight shadow round responses (CASSANDRA-12653)
  * Don't anti-compact repaired data to avoid inconsistencies (CASSANDRA-13153)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a79cc984/src/java/org/apache/cassandra/service/CassandraDaemon.java
--
diff --git a/src/java/org/apache/cassandra/service/CassandraDaemon.java 
b/src/java/org/apache/cassandra/service/CassandraDaemon.java
index e342389..18b568d 100644
--- a/src/java/org/apache/cassandra/service/CassandraDaemon.java
+++ b/src/java/org/apache/cassandra/service/CassandraDaemon.java
@@ -325,9 +325,9 @@ public class CassandraDaemon
 try
 {
 // enable metrics provided by metrics-jvm.jar
-CassandraMetricsRegistry.Metrics.register("jvm.buffers.", new 
BufferPoolMetricSet(ManagementFactory.getPlatformMBeanServer()));
-CassandraMetricsRegistry.Metrics.register("jvm.gc.", new 
GarbageCollectorMetricSet());
-CassandraMetricsRegistry.Metrics.register("jvm.memory.", new 
MemoryUsageGaugeSet());
+CassandraMetricsRegistry.Metrics.register("jvm.buffers", new 
BufferPoolMetricSet(ManagementFactory.getPlatformMBeanServer()));
+CassandraMetricsRegistry.Metrics.register("jvm.gc", new 
GarbageCollectorMetricSet());
+CassandraMetricsRegistry.Metrics.register("jvm.memory", new 
MemoryUsageGaugeSet());
 CassandraMetricsRegistry.Metrics.register("jvm.fd.usage", new 
FileDescriptorRatioGauge());
 // initialize metrics-reporter-config from yaml file
 String reportFileLocation = 
CassandraDaemon.class.getClassLoader().getResource(metricsReporterConfigFile).getFile();

[jira] [Created] (CASSANDRA-13405) ViewBuilder can miss data due to sstable generation filter

[T Jake Luciani (JIRA)]

T Jake Luciani created CASSANDRA-13405:
--

 Summary: ViewBuilder can miss data due to sstable generation filter
 Key: CASSANDRA-13405
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13405
 Project: Cassandra
  Issue Type: Bug
Reporter: T Jake Luciani
Assignee: T Jake Luciani
 Fix For: 3.0.13


The view builder for one MV is restarted when other MVs are added on the same 
keyspace.  There is an issue if compaction are running between these restarts 
that can cause the view build is lost since the builder tracks the max sstable 
generation to filter by when it starts back up.

I don't see a need for this generation tracking across restarts, it only needs 
to be tracked during a builders life (to avoid adding in newly compacted data). 
 





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

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

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-11471:


Well the tests pass, but I am still not sure about whether the v5 vs v4 checks 
are correct.

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



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

[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Edward Capriolo (JIRA)]

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

Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 5:19 PM:
-

1) ninja fix 
How does meritocracy work when we spend globs of time striking down patches, 
while simultaneously 'ninja fixing' stuff? Go make a patch and get it reviewed 
like everyone else. 

2) Agreed.

3) What a backwards argument. The "critical past bugs" sited in CASSANDRA-12535 
where caused by the person attempting to drop the -1 on this patch. This 
directly translates to "No one can edit the buggy code I introduced because 
THEY might make bugs."  Consider throwing a GetOffMyLawn exception
https://github.com/apache/cassandra/commit/8f15eb1b717548816a9ee8314269d4d1e2ee7084


 


was (Author: appodictic):
1) ninja fix 
How does meritocracy work when we spend globs of time striking down patches, 
while simultaneously 'ninja fixing' stuff? Go make a patch and get it reviewed 
like everyone else. 

2) Agreed.

3) What a backwards argument. The "critical past bugs" sited in CASSANDRA-12535 
where caused by the person attempting to drop the -1 on this patch. This 
directly translates to "No one can edit the buggy code I introduced because 
THEY might make bugs." 
https://github.com/apache/cassandra/commit/8f15eb1b717548816a9ee8314269d4d1e2ee7084


 

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Edward Capriolo (JIRA)]

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

Edward Capriolo commented on CASSANDRA-13396:
-

1) ninja fix 
How does meritocracy work when we spend globs of time striking down patches, 
while simultaneously 'ninja fixing' stuff? Go make a patch and get it reviewed 
like everyone else. 

2) Agreed.

3) What a backwards argument. The "critical past bugs" sited in CASSANDRA-12535 
where caused by the person attempting to drop the -1 on this patch. This 
directly translates to "No one can edit the buggy code I introduced because 
THEY might make bugs." 
https://github.com/apache/cassandra/commit/8f15eb1b717548816a9ee8314269d4d1e2ee7084


 

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Updated] (CASSANDRA-13404) Hostname verification for client-to-node encryption

[Jan Karlsson (JIRA)]

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

Jan Karlsson updated CASSANDRA-13404:
-
Fix Version/s: 4.x
   Status: Patch Available  (was: Open)

> Hostname verification for client-to-node encryption
> ---
>
> Key: CASSANDRA-13404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13404
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Jan Karlsson
>Assignee: Jan Karlsson
> Fix For: 4.x
>
> Attachments: 13404-trunk.txt
>
>
> Similarily to CASSANDRA-9220, Cassandra should support hostname verification 
> for client-node connections.



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

[jira] [Updated] (CASSANDRA-13404) Hostname verification for client-to-node encryption

[Jan Karlsson (JIRA)]

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

Jan Karlsson updated CASSANDRA-13404:
-
Attachment: 13404-trunk.txt

Should apply cleanly to trunk

> Hostname verification for client-to-node encryption
> ---
>
> Key: CASSANDRA-13404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13404
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Jan Karlsson
>Assignee: Jan Karlsson
> Fix For: 4.x
>
> Attachments: 13404-trunk.txt
>
>
> Similarily to CASSANDRA-9220, Cassandra should support hostname verification 
> for client-node connections.



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

[jira] [Created] (CASSANDRA-13404) Hostname verification for client-to-node encryption

[Jan Karlsson (JIRA)]

Jan Karlsson created CASSANDRA-13404:


 Summary: Hostname verification for client-to-node encryption
 Key: CASSANDRA-13404
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13404
 Project: Cassandra
  Issue Type: New Feature
Reporter: Jan Karlsson
Assignee: Jan Karlsson


Similarily to CASSANDRA-9220, Cassandra should support hostname verification 
for client-node connections.



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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13396:


There are really three issues:

1) The existing comments were clearly inadequate, and that's been ninja'd into 
place. +1 on that. 

2) Throwing a ClassCastException is objectively wrong. The patch fixes that, 
and should be committed. 

3) As a side effect, the patch allows other loggers, almost all of which are 
untested. The assertion from [~snazy] is that doing so is dangerous, 
specifically citing past bugs where other loggers which may do IO and cause 
sandbox access problems. That's a valid concern, and worth a logged warning in 
my opinion.

Like [~spo...@gmail.com] (and I think [~blerer]) suggest above, I think Ed's 
patch+warning makes sense to me.

If someone wants to "officially" support another logger in order to remove the 
warning, then I think the burden is on them to open a proper ticket and 
demonstrate that it's sufficiently tested.

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Updated] (CASSANDRA-13403) nodetool repair breaks SASI index

[Igor Novgorodov (JIRA)]

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

Igor Novgorodov updated CASSANDRA-13403:

Description: 
I've got table:
{code}
CREATE TABLE cservice.bulks_recipients (
recipient text,
bulk_id uuid,
datetime_final timestamp,
datetime_sent timestamp,
request_id uuid,
status int,
PRIMARY KEY (recipient, bulk_id)
) WITH CLUSTERING ORDER BY (bulk_id ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
CREATE CUSTOM INDEX bulk_recipients_bulk_id ON cservice.bulks_recipients 
(bulk_id) USING 'org.apache.cassandra.index.sasi.SASIIndex';
{code}

There are 11 rows in it:
{code}
> select * from bulks_recipients;

...
(11 rows)
{code}

Let's query by index (all rows have the same *bulk_id*):
{code}
> select * from bulks_recipients where bulk_id = 
> baa94815-e276-4ca4-adda-5b9734e6c4a5; 
> 

...
(11 rows)
{code}
Ok, everything is fine.

Now i'm doing *nodetool repair --partitioner-range --job-threads 4 --full* on 
each node in cluster sequentially.

After it finished:
{code}
> select * from bulks_recipients where bulk_id = 
> baa94815-e276-4ca4-adda-5b9734e6c4a5;

...
(2 rows)
{code}
Only two rows.

While the rows are actually there:
{code}
> select * from bulks_recipients;

...
(11 rows)
{code}

If i issue an incremental repair on a random node, i can get like 7 rows after 
index query.

Dropping index and recreating it fixes the issue. Is it a bug or am i doing the 
repair the wrong way?

  was:
I've got table:
{code}
CREATE TABLE cservice.bulks_recipients (
recipient text,
bulk_id uuid,
datetime_final timestamp,
datetime_sent timestamp,
request_id uuid,
status int,
PRIMARY KEY (recipient, bulk_id)
) WITH CLUSTERING ORDER BY (bulk_id ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
CREATE CUSTOM INDEX bulk_recipients_bulk_id ON cservice.bulks_recipients 
(bulk_id) USING 'org.apache.cassandra.index.sasi.SASIIndex';
{code}

There are 11 rows in it:
{code}
> select * from bulks_recipients;

...
(11 rows)
{code}

Let's query by index (all rows have the same *bulk_id*):
{code}
> select * from bulks_recipients where bulk_id = 
> baa94815-e276-4ca4-adda-5b9734e6c4a5; 
> 

...
(11 rows)
{code}
Ok, everything is fine.

Now i'm doing *nodetool repair --partitioner-range --job-threads 4 --full* on 
each node in cluster sequentially.

After it finished:
{code}
> select * from bulks_recipients where bulk_id = 
> baa94815-e276-4ca4-adda-5b9734e6c4a5;

...
(2 rows)
{code}
Only two rows.

While the rows are actually there:
{code}
> select * from bulks_recipients;

...
(11 rows)
{code}

Dropping index and recreating it fixes the issue. Is it a bug or am i doing the 
repair the wrong way?


> nodetool repair breaks SASI index
> -
>
> Key: CASSANDRA-13403
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13403
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
> Environment: 3.10
>Reporter: Igor Novgorodov
>
> I've got table:
> {code}
> CREATE TABLE cservice.bulks_recipients (
> recipient text,
> bulk_id uuid,
> datetime_final timestamp,
> datetime_sent timestamp,
> request_id uuid,
> status int,
> PRIMARY KEY (recipient, bulk_id)
> ) WITH CLUSTERING ORDER BY (bulk_id ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}
> AND comment = ''
> AND compaction = 

[jira] [Created] (CASSANDRA-13403) nodetool repair breaks SASI index

[Igor Novgorodov (JIRA)]

Igor Novgorodov created CASSANDRA-13403:
---

 Summary: nodetool repair breaks SASI index
 Key: CASSANDRA-13403
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13403
 Project: Cassandra
  Issue Type: Bug
  Components: sasi
 Environment: 3.10
Reporter: Igor Novgorodov


I've got table:
{code}
CREATE TABLE cservice.bulks_recipients (
recipient text,
bulk_id uuid,
datetime_final timestamp,
datetime_sent timestamp,
request_id uuid,
status int,
PRIMARY KEY (recipient, bulk_id)
) WITH CLUSTERING ORDER BY (bulk_id ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
CREATE CUSTOM INDEX bulk_recipients_bulk_id ON cservice.bulks_recipients 
(bulk_id) USING 'org.apache.cassandra.index.sasi.SASIIndex';
{code}

There are 11 rows in it:
{code}
> select * from bulks_recipients;

...
(11 rows)
{code}

Let's query by index (all rows have the same *bulk_id*):
{code}
> select * from bulks_recipients where bulk_id = 
> baa94815-e276-4ca4-adda-5b9734e6c4a5; 
> 

...
(11 rows)
{code}
Ok, everything is fine.

Now i'm doing *nodetool repair --partitioner-range --job-threads 4 --full* on 
each node in cluster sequentially.

After it finished:
{code}
> select * from bulks_recipients where bulk_id = 
> baa94815-e276-4ca4-adda-5b9734e6c4a5;

...
(2 rows)
{code}
Only two rows.

While the rows are actually there:
{code}
> select * from bulks_recipients;

...
(11 rows)
{code}

Dropping index and recreating it fixes the issue. Is it a bug or am i doing the 
repair the wrong way?



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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-13396:


We do not run any test with another logging library and I do not think that we 
plan to do it. Which, for me means that we do not officially support any other 
library. Warning the user about it seems normal to me. As a user I would prefer 
to know. 

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Updated] (CASSANDRA-12213) dtest failure in write_failures_test.TestWriteFailures.test_paxos_any

[Aleksey Yeschenko (JIRA)]

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

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

> dtest failure in write_failures_test.TestWriteFailures.test_paxos_any
> -
>
> Key: CASSANDRA-12213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12213
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Craig Kodman
>Assignee: Stefania
>  Labels: dtest
> Fix For: 3.0.x, 3.11.x
>
> Attachments: jenkins-stef1927-12014-dtest-2_logs.001.tar.gz, 
> node1_debug.log, node1_gc.log, node1.log, node2_debug.log, node2_gc.log, 
> node2.log, node3_debug.log, node3_gc.log, node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.9_dtest/10/testReport/write_failures_test/TestWriteFailures/test_paxos_any
> and:
> http://cassci.datastax.com/job/cassandra-3.9_dtest/10/testReport/write_failures_test/TestWriteFailures/test_mutation_v3/
> Failed on CassCI build cassandra-3.9_dtest #10



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

[jira] [Comment Edited] (CASSANDRA-12213) dtest failure in write_failures_test.TestWriteFailures.test_paxos_any

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko edited comment on CASSANDRA-12213 at 4/3/17 2:58 PM:
---

Looks good to me, but I feel like we should just reorder things in {{ALL}} 
instead of creating an extra list (with a comment above {{ALL}} explaining that 
the order matters).

EDIT: and for truncate we can just reverse the list.


was (Author: iamaleksey):
Looks good to me, but I feel like we should just reorder things in {{ALL}} 
instead of creating an extra list (with a comment above {{ALL}} explaining that 
the order matters).

> dtest failure in write_failures_test.TestWriteFailures.test_paxos_any
> -
>
> Key: CASSANDRA-12213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12213
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Craig Kodman
>Assignee: Stefania
>  Labels: dtest
> Fix For: 3.0.x, 3.11.x
>
> Attachments: jenkins-stef1927-12014-dtest-2_logs.001.tar.gz, 
> node1_debug.log, node1_gc.log, node1.log, node2_debug.log, node2_gc.log, 
> node2.log, node3_debug.log, node3_gc.log, node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.9_dtest/10/testReport/write_failures_test/TestWriteFailures/test_paxos_any
> and:
> http://cassci.datastax.com/job/cassandra-3.9_dtest/10/testReport/write_failures_test/TestWriteFailures/test_mutation_v3/
> Failed on CassCI build cassandra-3.9_dtest #10



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

[jira] [Commented] (CASSANDRA-12213) dtest failure in write_failures_test.TestWriteFailures.test_paxos_any

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-12213:
---

Looks good to me, but I feel like we should just reorder things in {{ALL}} 
instead of creating an extra list (with a comment above {{ALL}} explaining that 
the order matters).

> dtest failure in write_failures_test.TestWriteFailures.test_paxos_any
> -
>
> Key: CASSANDRA-12213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12213
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Craig Kodman
>Assignee: Stefania
>  Labels: dtest
> Fix For: 3.0.x, 3.11.x
>
> Attachments: jenkins-stef1927-12014-dtest-2_logs.001.tar.gz, 
> node1_debug.log, node1_gc.log, node1.log, node2_debug.log, node2_gc.log, 
> node2.log, node3_debug.log, node3_gc.log, node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.9_dtest/10/testReport/write_failures_test/TestWriteFailures/test_paxos_any
> and:
> http://cassci.datastax.com/job/cassandra-3.9_dtest/10/testReport/write_failures_test/TestWriteFailures/test_mutation_v3/
> Failed on CassCI build cassandra-3.9_dtest #10



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

[jira] [Commented] (CASSANDRA-13020) Hint delivery fails when prefer_local enabled

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-13020:
---

You might have missed it, but this is ready to commit, [~spo...@gmail.com]

> Hint delivery fails when prefer_local enabled
> -
>
> Key: CASSANDRA-13020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13020
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: v3.0.9
>Reporter: Aleksandr Ivanov
>Assignee: Stefan Podkowinski
>  Labels: decommission, hints
>
> I tried to decommission one node.
> Node sent all data to another node and got stuck in LEAVING state.
> Log message shows Exception in HintsDispatcher thread.
> Could it be reason of stuck in LEAVING state?
> command output:
> {noformat}
> root@cas-node6:~# time nodetool decommission
> error: null
> -- StackTrace --
> java.lang.NullPointerException
> at 
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at 
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:203)
> at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3566)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at 
> org.apache.cassandra.hints.HintsDispatchExecutor$TransferHintsTask.transfer(HintsDispatchExecutor.java:168)
> at 
> org.apache.cassandra.hints.HintsDispatchExecutor$TransferHintsTask.run(HintsDispatchExecutor.java:141)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> real147m7.483s
> user0m17.388s
> sys 0m1.968s
> {noformat}
> nodetool netstats:
> {noformat}
> root@cas-node6:~# nodetool netstats
> Mode: LEAVING
> Not sending any streams.
> Read Repair Statistics:
> Attempted: 35082
> Mismatch (Blocking): 18
> Mismatch (Background): 0
> Pool NameActive   Pending  Completed   Dropped
> Large messages  n/a 1  0 0
> Small messages  n/a 0   16109860   112
> Gossip messages n/a 0 287074 0
> {noformat}
> Log:
> {noformat}
> INFO  [RMI TCP Connection(58)-127.0.0.1] 2016-12-07 12:52:59,467 
> StorageService.java:1170 - LEAVING: sleeping 3 ms for batch processing 
> and pending range setup
> INFO  [RMI TCP Connection(58)-127.0.0.1] 2016-12-07 12:53:39,455 
> StorageService.java:1170 - LEAVING: replaying batch log and streaming data to 
> other nodes
> INFO  [RMI TCP Connection(58)-127.0.0.1] 2016-12-07 12:53:39,910 
> StreamResultFuture.java:87 - [Stream #2cc874c0-bc7c-11e6-b0df-e7f1ecd3dcfb] 
> Executing streaming plan for Unbootstrap
> INFO  [StreamConnectionEstablisher:1] 2016-12-07 12:53:39,911 
> StreamSession.java:239 - [Stream #2cc874c0-bc7c-11e6-b0df-e7f1ecd3dcfb] 
> Starting streaming to /10.10.10.17
> INFO  [StreamConnectionEstablisher:2] 2016-12-07 12:53:39,911 
> StreamSession.java:232 - [Stream #2cc874c0-bc7c-11e6-b0df-e7f1ecd3dcfb] 
> Session does not have any tasks.
> INFO  [StreamConnectionEstablisher:3] 2016-12-07 12:53:39,912 
> StreamSession.java:232 - [Stream #2cc874c0-bc7c-11e6-b0df-e7f1ecd3dcfb] 
> Session does not have any tasks.
> INFO  [StreamConnectionEstablisher:4] 2016-12-07 12:53:39,912 
> StreamSession.java:232 - [Stream #2cc874c0-bc7c-11e6-b0df-e7f1ecd3dcfb] 
> Session does not have any tasks.
> INFO  [RMI TCP Connection(58)-127.0.0.1] 2016-12-07 12:53:39,912 
> StorageService.java:1170 - LEAVING: streaming hints to other nodes
> INFO  [StreamConnectionEstablisher:2] 2016-12-07 12:53:39,912 

[jira] [Updated] (CASSANDRA-13020) Hint delivery fails when prefer_local enabled

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-13020:
--
Status: Ready to Commit  (was: Patch Available)

> Hint delivery fails when prefer_local enabled
> -
>
> Key: CASSANDRA-13020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13020
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: v3.0.9
>Reporter: Aleksandr Ivanov
>Assignee: Stefan Podkowinski
>  Labels: decommission, hints
>
> I tried to decommission one node.
> Node sent all data to another node and got stuck in LEAVING state.
> Log message shows Exception in HintsDispatcher thread.
> Could it be reason of stuck in LEAVING state?
> command output:
> {noformat}
> root@cas-node6:~# time nodetool decommission
> error: null
> -- StackTrace --
> java.lang.NullPointerException
> at 
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at 
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:203)
> at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3566)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at 
> org.apache.cassandra.hints.HintsDispatchExecutor$TransferHintsTask.transfer(HintsDispatchExecutor.java:168)
> at 
> org.apache.cassandra.hints.HintsDispatchExecutor$TransferHintsTask.run(HintsDispatchExecutor.java:141)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> real147m7.483s
> user0m17.388s
> sys 0m1.968s
> {noformat}
> nodetool netstats:
> {noformat}
> root@cas-node6:~# nodetool netstats
> Mode: LEAVING
> Not sending any streams.
> Read Repair Statistics:
> Attempted: 35082
> Mismatch (Blocking): 18
> Mismatch (Background): 0
> Pool NameActive   Pending  Completed   Dropped
> Large messages  n/a 1  0 0
> Small messages  n/a 0   16109860   112
> Gossip messages n/a 0 287074 0
> {noformat}
> Log:
> {noformat}
> INFO  [RMI TCP Connection(58)-127.0.0.1] 2016-12-07 12:52:59,467 
> StorageService.java:1170 - LEAVING: sleeping 3 ms for batch processing 
> and pending range setup
> INFO  [RMI TCP Connection(58)-127.0.0.1] 2016-12-07 12:53:39,455 
> StorageService.java:1170 - LEAVING: replaying batch log and streaming data to 
> other nodes
> INFO  [RMI TCP Connection(58)-127.0.0.1] 2016-12-07 12:53:39,910 
> StreamResultFuture.java:87 - [Stream #2cc874c0-bc7c-11e6-b0df-e7f1ecd3dcfb] 
> Executing streaming plan for Unbootstrap
> INFO  [StreamConnectionEstablisher:1] 2016-12-07 12:53:39,911 
> StreamSession.java:239 - [Stream #2cc874c0-bc7c-11e6-b0df-e7f1ecd3dcfb] 
> Starting streaming to /10.10.10.17
> INFO  [StreamConnectionEstablisher:2] 2016-12-07 12:53:39,911 
> StreamSession.java:232 - [Stream #2cc874c0-bc7c-11e6-b0df-e7f1ecd3dcfb] 
> Session does not have any tasks.
> INFO  [StreamConnectionEstablisher:3] 2016-12-07 12:53:39,912 
> StreamSession.java:232 - [Stream #2cc874c0-bc7c-11e6-b0df-e7f1ecd3dcfb] 
> Session does not have any tasks.
> INFO  [StreamConnectionEstablisher:4] 2016-12-07 12:53:39,912 
> StreamSession.java:232 - [Stream #2cc874c0-bc7c-11e6-b0df-e7f1ecd3dcfb] 
> Session does not have any tasks.
> INFO  [RMI TCP Connection(58)-127.0.0.1] 2016-12-07 12:53:39,912 
> StorageService.java:1170 - LEAVING: streaming hints to other nodes
> INFO  [StreamConnectionEstablisher:2] 2016-12-07 12:53:39,912 
> StreamResultFuture.java:183 - [Stream 

[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Edward Capriolo (JIRA)]

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

Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 2:48 PM:
-

{quote}
We can as well state something like "Using any logging library not shipped with 
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of 
this discussion.
{quote}

-1 The point of this Jira is not to create some new policy to avoid committing 
things. Fake blockers like 'this might cause a bug in the future' are not a 
valid technical reason to reject something. If that is the case shutdown all 
development on everything. I appreciate the attempt to compromise, but this is 
not the right direction. "Not supported" puts this in a trigger like situation. 
It will create a policy that will stop active research. Anyone will be free to 
reject further development using the "not supported" argument regardless of how 
baseless it is. 


was (Author: appodictic):
{quote}
We can as well state something like "Using any logging library not shipped with 
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of 
this discussion.
{quote}

-1 The point of this Jira is not to create some new policy to avoid committing 
things. Fake blockers like 'this might cause a bug in the future' are not a 
valid technical reason to reject something. If that is the case shutdown all 
development on everything. I appreciate the attempt to compromise, but this is 
not the right direction. "Not supported" puts this in a trigger like situation. 
It will create a policy that stop active research. Anyone will be free to 
reject further development using the "not supported" argument regardless of how 
baseless it is. 

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Edward Capriolo (JIRA)]

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

Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 2:47 PM:
-

{quote}
We can as well state something like "Using any logging library not shipped with 
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of 
this discussion.
{quote}

-1 The point of this Jira is not to create some new policy to avoid committing 
things. Fake blockers like 'this might cause a bug in the future' are not a 
valid technical reason to reject something. If that is the case shutdown all 
development on everything. I appreciate the attempt to compromise, but this is 
not the right direction. "Not supported" puts this in a trigger like situation. 
It will create a policy that stop active research. Anyone will be free to 
reject further development using the "not supported" argument regardless of how 
baseless it is. 


was (Author: appodictic):
{quote}
We can as well state something like "Using any logging library not shipped with 
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of 
this discussion.
{quote}

-1 The point of this Jira is not to create some new policy to avoid committing 
things. Fake blockers like 'this might cause a bug in the future' are not a 
valid technical reason to reject something. If that is the case shutdown all 
development on everything. I appreciate the attempt to compromise, but this is 
not the right direction. "Not supported" puts this in a trigger like situation, 
it will create a policy that stop active research. Anyone will be free to 
reject further development using the "not supported" argument regardless of how 
baseless it is.

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Edward Capriolo (JIRA)]

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

Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 2:46 PM:
-

{quote}
We can as well state something like "Using any logging library not shipped with 
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of 
this discussion.
{quote}

-1 The point of this Jira is not to create some new policy to avoid committing 
things. Fake blockers like 'this might cause a bug in the future' are not a 
valid technical reason to reject something. If that is the case shutdown all 
development on everything. I appreciate the attempt to compromise, but this is 
not the right direction. "Not supported" puts this in a trigger like situation, 
it will create a policy that stop active research. Anyone will be free to 
reject further development using the "not supported" argument regardless of how 
baseless it is.


was (Author: appodictic):
{quote}
We can as well state something like "Using any logging library not shipped with 
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of 
this discussion.
{quote}

-1 The point of this Jira is not to create some new policy to avoid committing 
things. Fake blockers like 'this might cause a bug in the future' are not a 
valid technical reason to reject something. If that is the case shutdown all 
development on everything

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Created] (CASSANDRA-13402) testall failure in org.apache.cassandra.dht.StreamStateStoreTest.testUpdateAndQueryAvailableRanges

[Sean McCarthy (JIRA)]

Sean McCarthy created CASSANDRA-13402:
-

 Summary: testall failure in 
org.apache.cassandra.dht.StreamStateStoreTest.testUpdateAndQueryAvailableRanges
 Key: CASSANDRA-13402
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13402
 Project: Cassandra
  Issue Type: Bug
  Components: Testing
Reporter: Sean McCarthy
 Attachments: TEST-org.apache.cassandra.dht.StreamStateStoreTest.log

example failure:

http://cassci.datastax.com/job/trunk_testall/1488/testReport/org.apache.cassandra.dht/StreamStateStoreTest/testUpdateAndQueryAvailableRanges

{code}
Stacktrace

java.lang.NullPointerException
at 
org.apache.cassandra.streaming.StreamSession.isKeepAliveSupported(StreamSession.java:244)
at 
org.apache.cassandra.streaming.StreamSession.(StreamSession.java:196)
at 
org.apache.cassandra.dht.StreamStateStoreTest.testUpdateAndQueryAvailableRanges(StreamStateStoreTest.java:53)
{code}

Related failures: (13)
http://cassci.datastax.com/job/trunk_testall/1488/testReport/



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

[jira] [Updated] (CASSANDRA-13197) +=/-= shortcut syntax bugs/inconsistencies

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-13197:

Status: Ready to Commit  (was: Patch Available)

> +=/-= shortcut syntax bugs/inconsistencies
> --
>
> Key: CASSANDRA-13197
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13197
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Kishan Karunaratne
>Assignee: Alex Petrov
>
> CASSANDRA-12232 introduced (+=/-=) shortcuts for counters and collection 
> types. I ran into some bugs/consistencies.
> Given the schema:
> {noformat}
> CREATE TABLE simplex.collection_table (k int PRIMARY KEY, d_l List, d_s 
> Set, d_m Map, d_t Tuple);
> {noformat}
> 1) Using -= on a list column removes all elements that match the value, 
> instead of the first or last occurrence of it. Is this expected?
> {noformat}
> Given d_l = [0, 1, 2, 1, 1]
> UPDATE collection_table SET d_l -= [1] WHERE k=0;
> yields 
> [0, 2]
> {noformat}
> 2) I can't seem to remove a map key/value pair:
> {noformat}
> Given d_m = {0: 0, 1: 1}
> UPDATE collection_table SET d_m -= {1:1} WHERE k=0;
> yields
> Invalid map literal for d_m of type frozen
> {noformat}
> However {noformat}UPDATE collection_table SET d_m -= {1} WHERE k=0;{noformat} 
> does work.
> 3) Tuples are immutable so it make sense that +=/-= doesn't apply. However 
> the error message could be better, now that other collection types are 
> allowed:
> {noformat}
> UPDATE collection_table SET d_t += (1) WHERE k=0;
> yields
> Invalid operation (d_t = d_t + (1)) for non counter column d_t
> {noformat}



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

[jira] [Created] (CASSANDRA-13401) dtest failure in upgrade_tests.regression_test.TestForRegressionsUpgrade_current_3_0_x_To_indev_trunk.test13294

[Sean McCarthy (JIRA)]

Sean McCarthy created CASSANDRA-13401:
-

 Summary: dtest failure in 
upgrade_tests.regression_test.TestForRegressionsUpgrade_current_3_0_x_To_indev_trunk.test13294
 Key: CASSANDRA-13401
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13401
 Project: Cassandra
  Issue Type: Bug
  Components: Testing
Reporter: Sean McCarthy
 Attachments: node1_debug.log, node1_gc.log, node1.log, 
node2_debug.log, node2_gc.log, node2.log

example failure:

http://cassci.datastax.com/job/trunk_dtest_upgrade/102/testReport/upgrade_tests.regression_test/TestForRegressionsUpgrade_current_3_0_x_To_indev_trunk/test13294

{code}
Error Message

Command '('/usr/lib/jvm/jdk1.8.0_121/bin/java', '-cp', 
'/usr/lib/jvm/jdk1.8.0_121/lib/tools.jar:lib/jolokia-jvm-1.2.3-agent.jar', 
'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 'start', 
'6348')' returned non-zero exit status 1
{code}{code}
Stacktrace

  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
  File "/home/automaton/cassandra-dtest/upgrade_tests/regression_test.py", line 
110, in test13294
self.compact_sstable(node1, first_sstable)
  File "/home/automaton/cassandra-dtest/upgrade_tests/regression_test.py", line 
121, in compact_sstable
with JolokiaAgent(node) as jmx:
  File "/home/automaton/cassandra-dtest/tools/jmxutils.py", line 314, in 
__enter__
self.start()
  File "/home/automaton/cassandra-dtest/tools/jmxutils.py", line 205, in start
subprocess.check_output(args, stderr=subprocess.STDOUT)
  File "/usr/lib/python2.7/subprocess.py", line 574, in check_output
raise CalledProcessError(retcode, cmd, output=output)
{code}{code}
Standard Output

/home/automaton/cassandra/ 
local:/home/automaton/cassandra/:add855ae177d28d02f1172fb0070ef487237ead5
Failed to start jolokia agent (command was: /usr/lib/jvm/jdk1.8.0_121/bin/java 
-cp /usr/lib/jvm/jdk1.8.0_121/lib/tools.jar:lib/jolokia-jvm-1.2.3-agent.jar 
org.jolokia.jvmagent.client.AgentLauncher --host 127.0.0.1 start 6348): Command 
'('/usr/lib/jvm/jdk1.8.0_121/bin/java', '-cp', 
'/usr/lib/jvm/jdk1.8.0_121/lib/tools.jar:lib/jolokia-jvm-1.2.3-agent.jar', 
'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 'start', 
'6348')' returned non-zero exit status 1
Exit status was: 1
Output was: Illegal Argument (command: start) : Cannot attach to process-ID 
6348.
See --help for possible reasons.
{code}



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

[jira] [Updated] (CASSANDRA-13197) +=/-= shortcut syntax bugs/inconsistencies

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-13197:

Issue Type: Improvement  (was: Bug)

> +=/-= shortcut syntax bugs/inconsistencies
> --
>
> Key: CASSANDRA-13197
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13197
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Kishan Karunaratne
>Assignee: Alex Petrov
>
> CASSANDRA-12232 introduced (+=/-=) shortcuts for counters and collection 
> types. I ran into some bugs/consistencies.
> Given the schema:
> {noformat}
> CREATE TABLE simplex.collection_table (k int PRIMARY KEY, d_l List, d_s 
> Set, d_m Map, d_t Tuple);
> {noformat}
> 1) Using -= on a list column removes all elements that match the value, 
> instead of the first or last occurrence of it. Is this expected?
> {noformat}
> Given d_l = [0, 1, 2, 1, 1]
> UPDATE collection_table SET d_l -= [1] WHERE k=0;
> yields 
> [0, 2]
> {noformat}
> 2) I can't seem to remove a map key/value pair:
> {noformat}
> Given d_m = {0: 0, 1: 1}
> UPDATE collection_table SET d_m -= {1:1} WHERE k=0;
> yields
> Invalid map literal for d_m of type frozen
> {noformat}
> However {noformat}UPDATE collection_table SET d_m -= {1} WHERE k=0;{noformat} 
> does work.
> 3) Tuples are immutable so it make sense that +=/-= doesn't apply. However 
> the error message could be better, now that other collection types are 
> allowed:
> {noformat}
> UPDATE collection_table SET d_t += (1) WHERE k=0;
> yields
> Invalid operation (d_t = d_t + (1)) for non counter column d_t
> {noformat}



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

[jira] [Commented] (CASSANDRA-13197) +=/-= shortcut syntax bugs/inconsistencies

[JIRA]

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

Andrés de la Peña commented on CASSANDRA-13197:
---

+1, nice patch

> +=/-= shortcut syntax bugs/inconsistencies
> --
>
> Key: CASSANDRA-13197
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13197
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kishan Karunaratne
>Assignee: Alex Petrov
>
> CASSANDRA-12232 introduced (+=/-=) shortcuts for counters and collection 
> types. I ran into some bugs/consistencies.
> Given the schema:
> {noformat}
> CREATE TABLE simplex.collection_table (k int PRIMARY KEY, d_l List, d_s 
> Set, d_m Map, d_t Tuple);
> {noformat}
> 1) Using -= on a list column removes all elements that match the value, 
> instead of the first or last occurrence of it. Is this expected?
> {noformat}
> Given d_l = [0, 1, 2, 1, 1]
> UPDATE collection_table SET d_l -= [1] WHERE k=0;
> yields 
> [0, 2]
> {noformat}
> 2) I can't seem to remove a map key/value pair:
> {noformat}
> Given d_m = {0: 0, 1: 1}
> UPDATE collection_table SET d_m -= {1:1} WHERE k=0;
> yields
> Invalid map literal for d_m of type frozen
> {noformat}
> However {noformat}UPDATE collection_table SET d_m -= {1} WHERE k=0;{noformat} 
> does work.
> 3) Tuples are immutable so it make sense that +=/-= doesn't apply. However 
> the error message could be better, now that other collection types are 
> allowed:
> {noformat}
> UPDATE collection_table SET d_t += (1) WHERE k=0;
> yields
> Invalid operation (d_t = d_t + (1)) for non counter column d_t
> {noformat}



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

[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Edward Capriolo (JIRA)]

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

Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 2:11 PM:
-

{quote}
We can as well state something like "Using any logging library not shipped with 
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of 
this discussion.
{quote}

-1 The point of this Jira is not to create some new policy to avoid committing 
things. Fake blockers like 'this might cause a bug in the future' are not a 
valid technical reason to reject something. If that is the case shutdown all 
development on everything


was (Author: appodictic):
{quote}
We can as well state something like "Using any logging library not shipped with 
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of 
this discussion.
{quote}

-1 The point of this Jira is not to create some new policy to avoid committing 
things. Fake blockers like 'this might cause a bug in the future' are not a 
valid technical reason not to do anything. If that is the case shutdown all 
development on everything

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Edward Capriolo (JIRA)]

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

Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 2:01 PM:
-

{quote}
We can as well state something like "Using any logging library not shipped with 
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of 
this discussion.
{quote}

-1 The point of this Jira is not to create some new policy to avoid committing 
things. Fake blockers like 'this might cause a bug in the future' are not a 
valid technical reason not to do anything. If that is the case shutdown all 
development on everything


was (Author: appodictic):
{quote}
We can as well state something like "Using any logging library not shipped with 
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of 
this discussion.
{quote}

-1 The point of this Jira is not to create some new policy to avoid committing 
things you do not want to commit. 

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Commented] (CASSANDRA-13304) Add checksumming to the native protocol

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-13304:
-

Thanks much [~adutra]!

bq. Currently checksum is enforced even for STARTUP messages, is that on 
purpose? Given that compression is always disabled for this message, I was 
wondering if we shouldn't disable checksum as well.

Yes it was intentional. Compression is optional and negotiated via the STARTUP 
message, so I see the sense in disabling compression for that message. Because 
my proposal was to make checksumming mandatory for v5+ there's no particular 
reason to skip checksums for STARTUP. If the consensus we arrive it is to make 
it optional, then disabling it there would be necessary.

bq. Currently if checksum fails an IOException is thrown which is caught by 
UnexpectedChannelExceptionHandler and the connection is closed. This is not 
very user-friendly because clients have no clue about what happened

Do you think a {{ProtocolException}} is appropriate here, or do we need to 
define a new error response?

bq. Minor: ChunkCompressor.compressChunk() is always called with srcOffset = 0 
and destOffset = 0; can we simplify the signature?

We perhaps could. [~mkjellman], you expressed an intention to add more 
compression impls down the line. Do you see this change making that more 
difficult? Also, perhaps we should consider changing the {{decompress}} 
signature to accept a pre-allocated dest array? The LZ4 javadoc for the version 
of {{decompress}} we're currently using states "Warning: this method has an 
important overhead due to the fact that it needs to allocate a buffer to 
decompress into, and then needs to resize this buffer to the actual 
decompressed length." Incidentally, I guess it would be nice to be able to 
re-use the new {{LZ4Compressor}} in {{LegacyLZ4FrameCompressor}}.

bq. Nit: packages org.apache.cassandra.transport.frame and 
org.apache.cassandra.transport.frame.body should imo contain the word checksum 
because this is what they are meant for.
bq. Nit: In ChecksummedFrameCompressor and ChecksummedTransformer I would 
replace Checksummed with Checksumming.

I've pushed [a 
commit|https://github.com/beobal/cassandra/commit/f5180e1aa58e8900ed9b3612a9f1779e598a2b0a]
 with some renaming and a slight reorg of the packages, let me know what you 
think.

I've also updated the branch to make use of {{ChecksumType}} and remove the 
unnecessary threadlocal in the checksumming transformer.

[~mkjellman], [~adutra] asks if the use of {{Unpooled}} is necessary 
[here|https://github.com/beobal/cassandra/commit/5d6e46bc5b68321a98b5be6ebc44fe3a539b637e#commitcomment-21578151].
 I don't think it is but was there a reason you did it like that specifically?

> Add checksumming to the native protocol
> ---
>
> Key: CASSANDRA-13304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13304
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Michael Kjellman
>Assignee: Michael Kjellman
>  Labels: client-impacting
> Attachments: 13304_v1.diff
>
>
> The native binary transport implementation doesn't include checksums. This 
> makes it highly susceptible to silently inserting corrupted data either due 
> to hardware issues causing bit flips on the sender/client side, C*/receiver 
> side, or network in between.
> Attaching an implementation that makes checksum'ing mandatory (assuming both 
> client and server know about a protocol version that supports checksums) -- 
> and also adds checksumming to clients that request compression.
> The serialized format looks something like this:
> {noformat}
>  *  1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
>  *  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  * |  Number of Compressed Chunks  | Compressed Length (e1)/
>  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  * /  Compressed Length cont. (e1) |Uncompressed Length (e1)   /
>  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  * | Uncompressed Length cont. (e1)| CRC32 Checksum of Lengths (e1)|
>  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  * | Checksum of Lengths cont. (e1)|Compressed Bytes (e1)+//
>  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  * |  CRC32 Checksum (e1) ||
>  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  * |Compressed Length (e2) |
>  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  * |   Uncompressed Length 

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Edward Capriolo (JIRA)]

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

Edward Capriolo commented on CASSANDRA-13396:
-

{quote}
We can as well state something like "Using any logging library not shipped with 
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of 
this discussion.
{quote}

-1 The point of this Jira is not to create some new policy to avoid committing 
things you do not want to commit. 

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Edward Capriolo (JIRA)]

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

Edward Capriolo commented on CASSANDRA-13396:
-

-1 on ninja fixes. 

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



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

[jira] [Updated] (CASSANDRA-13398) Skip mutating repairedAt of already repaired sstables

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-13398:

Priority: Minor  (was: Major)

> Skip mutating repairedAt of already repaired sstables
> -
>
> Key: CASSANDRA-13398
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13398
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
>
> CASSANDRA-13153 skips anticompaction on sstables already repaired, but we are 
> not skipping mutating repairedAt when the sstable is fully contained in the 
> repaired range.



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

[jira] [Commented] (CASSANDRA-13398) Skip mutating repairedAt of already repaired sstables

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-13398:
-

Actually you're right this is a not problem per se, but it can cause 
{{repairedAt}} fields not consistent across replicas for a given range, since 
the same repair session may update {{repairedAt}} on some replicas 
(coordinator) while not on others (participants), what can cause some confusion 
if we ever start using this field for anything else other than finding out if 
an sstable is repaired or not. Not a big deal though, so I'm fine if we 
wontfixit.

> Skip mutating repairedAt of already repaired sstables
> -
>
> Key: CASSANDRA-13398
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13398
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>
> CASSANDRA-13153 skips anticompaction on sstables already repaired, but we are 
> not skipping mutating repairedAt when the sstable is fully contained in the 
> repaired range.



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

[jira] [Commented] (CASSANDRA-13197) +=/-= shortcut syntax bugs/inconsistencies

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-13197:
-

Thank you for the review [~adelapena]! I think it totally makes sense. I have 
made the changes you suggested, rebased, force-pushed and re-triggered CI.

> +=/-= shortcut syntax bugs/inconsistencies
> --
>
> Key: CASSANDRA-13197
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13197
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kishan Karunaratne
>Assignee: Alex Petrov
>
> CASSANDRA-12232 introduced (+=/-=) shortcuts for counters and collection 
> types. I ran into some bugs/consistencies.
> Given the schema:
> {noformat}
> CREATE TABLE simplex.collection_table (k int PRIMARY KEY, d_l List, d_s 
> Set, d_m Map, d_t Tuple);
> {noformat}
> 1) Using -= on a list column removes all elements that match the value, 
> instead of the first or last occurrence of it. Is this expected?
> {noformat}
> Given d_l = [0, 1, 2, 1, 1]
> UPDATE collection_table SET d_l -= [1] WHERE k=0;
> yields 
> [0, 2]
> {noformat}
> 2) I can't seem to remove a map key/value pair:
> {noformat}
> Given d_m = {0: 0, 1: 1}
> UPDATE collection_table SET d_m -= {1:1} WHERE k=0;
> yields
> Invalid map literal for d_m of type frozen
> {noformat}
> However {noformat}UPDATE collection_table SET d_m -= {1} WHERE k=0;{noformat} 
> does work.
> 3) Tuples are immutable so it make sense that +=/-= doesn't apply. However 
> the error message could be better, now that other collection types are 
> allowed:
> {noformat}
> UPDATE collection_table SET d_t += (1) WHERE k=0;
> yields
> Invalid operation (d_t = d_t + (1)) for non counter column d_t
> {noformat}



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

[jira] [Updated] (CASSANDRA-13398) Skip mutating repairedAt of already repaired sstables

[Aleksey Yeschenko (JIRA)]

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

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

> Skip mutating repairedAt of already repaired sstables
> -
>
> Key: CASSANDRA-13398
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13398
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>
> CASSANDRA-13153 skips anticompaction on sstables already repaired, but we are 
> not skipping mutating repairedAt when the sstable is fully contained in the 
> repaired range.



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

[jira] [Updated] (CASSANDRA-13391) nodetool clearsnapshot should require --all to clear all snapshots

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-13391:
--
Issue Type: Improvement  (was: Bug)

> nodetool clearsnapshot should require --all to clear all snapshots
> --
>
> Key: CASSANDRA-13391
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13391
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jon Haddad
>
> Deleting all snapshots by default is insanely dangerous.  It would be like if 
> rm's default was -rf /.



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

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

[Alex Petrov (JIRA)]

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

Alex Petrov edited comment on CASSANDRA-13216 at 4/3/17 1:23 PM:
-

CI looks good, no failures for this test in 10 builds. On trunk, 11th build 
contained 64 failures, but since there were no changes inbetween and given the 
nature of errors there I tend to believe it's an enviroment issue. 


was (Author: ifesdjeen):
CI looks good, no failures for this test in 10 builds. On trunk, 11th build 
contained 64 failures, but since there were no changes inbetween and given the 
nature of errors there I tend to believe it's an enviroment issue. 

[~mkjellman] would you like to keep yourself as a reviewer?

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



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

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

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-13216:

Reviewer:   (was: Michael Kjellman)

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



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

[jira] [Commented] (CASSANDRA-13363) java.lang.ArrayIndexOutOfBoundsException: null

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-13363:
-

You can turn off {{OmitStackTraceInFastThrow}} if it's on, my guess is that the 
stack trace might be emitted because the amount of thrown exceptions has 
reached a threshold and was optimised away.

> java.lang.ArrayIndexOutOfBoundsException: null
> --
>
> Key: CASSANDRA-13363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13363
> Project: Cassandra
>  Issue Type: Bug
> Environment: CentOS 6, Cassandra 3.10
>Reporter: Artem Rokhin
>
> Constantly see this error in the log without any additional information or a 
> stack trace.
> {code}
> Exception in thread Thread[MessagingService-Incoming-/10.0.1.26,5,main]
> {code}
> {code}
> java.lang.ArrayIndexOutOfBoundsException: null
> {code}
> Logger: org.apache.cassandra.service.CassandraDaemon
> Thrdead: MessagingService-Incoming-/10.0.1.12
> Method: uncaughtException
> File: CassandraDaemon.java
> Line: 229



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

[jira] [Commented] (CASSANDRA-13363) java.lang.ArrayIndexOutOfBoundsException: null

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-13363:
--

I really don't think we can do anything about it unless you provide a full 
stack trace.

> java.lang.ArrayIndexOutOfBoundsException: null
> --
>
> Key: CASSANDRA-13363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13363
> Project: Cassandra
>  Issue Type: Bug
> Environment: CentOS 6, Cassandra 3.10
>Reporter: Artem Rokhin
>
> Constantly see this error in the log without any additional information or a 
> stack trace.
> {code}
> Exception in thread Thread[MessagingService-Incoming-/10.0.1.26,5,main]
> {code}
> {code}
> java.lang.ArrayIndexOutOfBoundsException: null
> {code}
> Logger: org.apache.cassandra.service.CassandraDaemon
> Thrdead: MessagingService-Incoming-/10.0.1.12
> Method: uncaughtException
> File: CassandraDaemon.java
> Line: 229



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

[jira] [Commented] (CASSANDRA-13400) java.lang.ArithmeticException: / by zero when index is created on table with clustering columns only

[JIRA]

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

Andrés de la Peña commented on CASSANDRA-13400:
---

The problem is due to a typo at 
{{SecondaryIndexManager.calculateIndexingPageSize}}.

The bug only affects 3.0. It doesn't affect to 3.11 nor trunk because it was 
solved with [this direct 
commit|https://github.com/adelapena/cassandra/commit/eaced9a541d09d55973b6f88d720e16ac948a559].

This patch fixes the typo and adds a simple test:
||[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...adelapena:13400-3.0]|[utests|http://cassci.datastax.com/view/Dev/view/adelapena/job/adelapena-13400-3.0-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/adelapena/job/adelapena-13400-3.0-dtest/]|

> java.lang.ArithmeticException: / by zero when index is created on table with 
> clustering columns only
> 
>
> Key: CASSANDRA-13400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13400
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Andrés de la Peña
>Assignee: Andrés de la Peña
>  Labels: 2i, secondary_index
> Fix For: 3.0.x
>
>
> If we create an index over the clustering key of a table without regular 
> columns:
> {code}
> CREATE KEYSPACE k WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> CREATE TABLE k.t (pk text, ck text, PRIMARY KEY (pk, ck));
> INSERT INTO k.t (pk, ck) VALUES ( 'pk','ck');
> CREATE INDEX idx ON k.t(ck);
> {code}
> Then the following error index creation erros is logged:
> {code}
> INFO  10:19:34 Submitting index build of idx for data in 
> BigTableReader(path='/Users/adelapena/datastax/cassandra/data/data/k/t-ed3d6f90185611e7949f55d18a2e5858/mc-1-big-Data.db')
> ERROR 10:19:34 Exception in thread Thread[SecondaryIndexManagement:2,5,main]
> java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
> java.lang.ArithmeticException: / by zero
>   at 
> org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:402) 
> ~[main/:na]
>   at 
> org.apache.cassandra.index.internal.CassandraIndex.buildBlocking(CassandraIndex.java:723)
>  ~[main/:na]
>   at 
> org.apache.cassandra.index.internal.CassandraIndex.lambda$getBuildIndexTask$5(CassandraIndex.java:693)
>  ~[main/:na]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_112]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_112]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_112]
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
>  [main/:na]
>   at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_112]
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.ArithmeticException: / by zero
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> ~[na:1.8.0_112]
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192) 
> ~[na:1.8.0_112]
>   at 
> org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:398) 
> ~[main/:na]
>   ... 7 common frames omitted
> Caused by: java.lang.ArithmeticException: / by zero
>   at 
> org.apache.cassandra.index.SecondaryIndexManager.calculateIndexingPageSize(SecondaryIndexManager.java:629)
>  ~[main/:na]
>   at 
> org.apache.cassandra.index.SecondaryIndexBuilder.build(SecondaryIndexBuilder.java:62)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$11.run(CompactionManager.java:1347)
>  ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_112]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_112]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_112]
>   ... 5 common frames omitted
> {code}
> Any further queries using the index will fail:
> {code}
> SELECT * FROM k.t where ck = 'ck';
> ReadFailure: Error from server: code=1300 [Replica(s) failed to execute read] 
> message="Operation failed - received 0 responses and 1 failures" 
> info={'failures': 1, 'received_responses': 0, 'required_responses': 1, 
> 'consistency': 'ONE'}
> {code}



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

[jira] [Assigned] (CASSANDRA-9778) CQL support for time series aggregation

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer reassigned CASSANDRA-9778:
-

Assignee: (was: Benjamin Lerer)

> CQL support for time series aggregation
> ---
>
> Key: CASSANDRA-9778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9778
> Project: Cassandra
>  Issue Type: New Feature
>  Components: CQL
>Reporter: Jonathan Ellis
>
> Along with MV (CASSANDRA-6477), time series aggregation or "rollups" are a 
> common design pattern in cassandra applications.  I'd like to add CQL support 
> for this along these lines:
> {code}
> CREATE MATERIALIZED VIEW stocks_by_hour AS
> SELECT exchange, day, day_time(1h) AS hour, symbol, avg(price), sum(volume)
> FROM stocks
> GROUP BY exchange, day, symbol, hour
> PRIMARY KEY  ((exchange, day), hour, symbol);
> {code}



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