[jira] [Commented] (CASSANDRA-13403) nodetool repair breaks SASI index
[ https://issues.apache.org/jira/browse/CASSANDRA-13403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954641#comment-15954641 ] Alex Petrov commented on CASSANDRA-13403: - [~blind_oracle] I'm trying to understand what exactly is broken here, a question: if you rebuild the index, does it cause the same result? Also, does the problem persist or if you wait for some time, it goes away? Could you also find log entries where it says the index got opened when you were rebuilding it and an {{ls}} output on {{data}} directory? > 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-13065) Consistent range movements to not require MV updates to go through write paths
[ https://issues.apache.org/jira/browse/CASSANDRA-13065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/CASSANDRA-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/CASSANDRA-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 org.apache.cassandra.db
[jira] [Commented] (CASSANDRA-13346) Failed unregistering mbean during drop keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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.
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 metric.speculativeInsufficientReplicas.getCount(); +
[jira] [Updated] (CASSANDRA-13216) testall failure in org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages
[ 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
[ 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
[ https://issues.apache.org/jira/browse/CASSANDRA-13216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/CASSANDRA-11483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/CASSANDRA-13405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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] 2
[1/6] cassandra git commit: Fix hint delivery when prefer_local enabled
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
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
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
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
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
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
[ 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
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
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
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 (CASSANDRA-12790) + * Make the fanout size for LeveledCompactio
[02/10] cassandra git commit: Fix incorrect jvm metric names
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
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
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
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
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
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 (CASSANDRA-12790) + * Make the fanout size for Leveled
[01/10] cassandra git commit: Fix incorrect jvm metric names
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 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
[ https://issues.apache.org/jira/browse/CASSANDRA-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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 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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/CASSANDRA-12213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-12213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Updated] (CASSANDRA-13020) Hint delivery fails when prefer_local enabled
[ 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 #2cc874c0-bc7c-11e6-b0d
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ 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 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
[ 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
[ https://issues.apache.org/jira/browse/CASSANDRA-13197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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) | > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | Uncomp
[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/CASSANDRA-13398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/CASSANDRA-13216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/CASSANDRA-13363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-13400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)