[jira] [Commented] (CASSANDRA-15861) Mutating sstable component may race with entire-sstable-streaming(ZCS) causing checksum validation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-15861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189795#comment-17189795
]
Caleb Rackliffe commented on CASSANDRA-15861:
-
bq. Benjamin Lerer not merging as I have not seen your review yet
We do have 2 committer +1's (from [~bdeggleston] and [~dcapwell]) and one
non-committer +1 (me). Do we strictly need [~blerer]'s +1? (To be clear, I'm
fine if he wants to look...)
> Mutating sstable component may race with entire-sstable-streaming(ZCS)
> causing checksum validation failure
> --
>
> Key: CASSANDRA-15861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15861
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming,
> Local/Compaction
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Flaky dtest: [test_dead_sync_initiator -
> repair_tests.repair_test.TestRepair|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-dtest/143/testReport/junit/dtest.repair_tests.repair_test/TestRepair/test_dead_sync_initiator/]
> {code:java|title=stacktrace}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [Stream-Deserializer-127.0.0.1:7000-570871f3] 2020-06-03 04:05:19,081
> CassandraEntireSSTableStreamReader.java:145 - [Stream
> 6f1c3360-a54f-11ea-a808-2f23710fdc90] Error while reading sstable from stream
> for table = keyspace1.standard1
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.maybeValidateChecksum(MetadataSerializer.java:219)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:198)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:129)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.mutate(MetadataSerializer.java:226)
> at
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:140)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:78)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:49)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:181)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: Checksums do not match for
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> {code}
>
> In the above test, it executes "nodetool repair" on node1 and kills node2
> during repair. At the end, node3 reports checksum validation failure on
> sstable transferred from node1.
> {code:java|title=what happened}
> 1. When repair started on node1, it performs anti-compaction which modifies
> sstable's repairAt to 0 and pending repair id to session-id.
> 2. Then node1 creates {{ComponentManifest}} which contains file lengths to be
> transferred to node3.
> 3. Before node1 actually sends the files to node3, node2 is killed and node1
> starts to broadcast repair-failure-message to all participants in
> {{CoordinatorSession#fail}}
> 4. Node1 receives its own repair-failure-message and fails its local repair
> sessions at {{LocalSessions#failSession}} which triggers async background
> compaction.
> 5. Node1's background compaction will mutate sstable's repairAt to 0 and
> pending repair id to null via
> {{PendingRepairManager#getNextRepairFinishedTask}}, as there is no more
> in-progress repair.
> 6. Node1 actually sends the sstable to node3 where the sstable's STATS
> component size is different from the original size recorded in the manifest.
> 7. At the end, node3 reports checksum validation failure when it tries to
> mutate sstable level and "isTransient" attribute in
> {{CassandraEntireSSTableStreamReader#read}}.
> {code}
> Currently, entire-sstable-streaming requires sstable components to be
> immutable, because
[jira] [Comment Edited] (CASSANDRA-15406) Show the progress of data streaming and index build
[ https://issues.apache.org/jira/browse/CASSANDRA-15406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189777#comment-17189777 ] David Capwell edited comment on CASSANDRA-15406 at 9/3/20, 1:12 AM: Overall LGTM, left 2 comments in the PR (should keep header the same as CASSANDRA-15861 and for now lets keep the instanceOf check). Going to start testing this patch CI build: https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=CASSANDRA-15406 Plan to deploy to a cluster to monitor the netstat changes was (Author: dcapwell): Overall LGTM, left 2 comments in the PR (should keep header the same as CASSANDRA-15861 and for now lets keep the instanceOf check). Going to start testing this patch > Show the progress of data streaming and index build > > > Key: CASSANDRA-15406 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15406 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Streaming, Legacy/Streaming and Messaging, > Tool/nodetool >Reporter: maxwellguo >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0, 4.x > > Time Spent: 3h 20m > Remaining Estimate: 0h > > I found that we should supply a command to show the progress of streaming > when we do the operation of bootstrap/move/decommission/removenode. For when > do data streaming , noboday knows which steps there program are in , so I > think a command to show the joing/leaving node's is needed . > > PR [https://github.com/apache/cassandra/pull/558] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15406) Show the progress of data streaming and index build
[ https://issues.apache.org/jira/browse/CASSANDRA-15406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189777#comment-17189777 ] David Capwell commented on CASSANDRA-15406: --- Overall LGTM, left 2 comments in the PR (should keep header the same as CASSANDRA-15861 and for now lets keep the instanceOf check). Going to start testing this patch > Show the progress of data streaming and index build > > > Key: CASSANDRA-15406 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15406 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Streaming, Legacy/Streaming and Messaging, > Tool/nodetool >Reporter: maxwellguo >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0, 4.x > > Time Spent: 3h 20m > Remaining Estimate: 0h > > I found that we should supply a command to show the progress of streaming > when we do the operation of bootstrap/move/decommission/removenode. For when > do data streaming , noboday knows which steps there program are in , so I > think a command to show the joing/leaving node's is needed . > > PR [https://github.com/apache/cassandra/pull/558] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15861) Mutating sstable component may race with entire-sstable-streaming(ZCS) causing checksum validation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-15861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189770#comment-17189770
]
David Capwell commented on CASSANDRA-15861:
---
Overall LGTM +1.
I also took this branch and deployed to a 6 node cluster and rebuilt the nodes
in a loop to constantly run streaming, everything looked fine on this front.
[~blerer] not merging as I have not seen your review yet
> Mutating sstable component may race with entire-sstable-streaming(ZCS)
> causing checksum validation failure
> --
>
> Key: CASSANDRA-15861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15861
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming,
> Local/Compaction
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Flaky dtest: [test_dead_sync_initiator -
> repair_tests.repair_test.TestRepair|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-dtest/143/testReport/junit/dtest.repair_tests.repair_test/TestRepair/test_dead_sync_initiator/]
> {code:java|title=stacktrace}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [Stream-Deserializer-127.0.0.1:7000-570871f3] 2020-06-03 04:05:19,081
> CassandraEntireSSTableStreamReader.java:145 - [Stream
> 6f1c3360-a54f-11ea-a808-2f23710fdc90] Error while reading sstable from stream
> for table = keyspace1.standard1
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.maybeValidateChecksum(MetadataSerializer.java:219)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:198)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:129)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.mutate(MetadataSerializer.java:226)
> at
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:140)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:78)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:49)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:181)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: Checksums do not match for
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> {code}
>
> In the above test, it executes "nodetool repair" on node1 and kills node2
> during repair. At the end, node3 reports checksum validation failure on
> sstable transferred from node1.
> {code:java|title=what happened}
> 1. When repair started on node1, it performs anti-compaction which modifies
> sstable's repairAt to 0 and pending repair id to session-id.
> 2. Then node1 creates {{ComponentManifest}} which contains file lengths to be
> transferred to node3.
> 3. Before node1 actually sends the files to node3, node2 is killed and node1
> starts to broadcast repair-failure-message to all participants in
> {{CoordinatorSession#fail}}
> 4. Node1 receives its own repair-failure-message and fails its local repair
> sessions at {{LocalSessions#failSession}} which triggers async background
> compaction.
> 5. Node1's background compaction will mutate sstable's repairAt to 0 and
> pending repair id to null via
> {{PendingRepairManager#getNextRepairFinishedTask}}, as there is no more
> in-progress repair.
> 6. Node1 actually sends the sstable to node3 where the sstable's STATS
> component size is different from the original size recorded in the manifest.
> 7. At the end, node3 reports checksum validation failure when it tries to
> mutate sstable level and "isTransient" attribute in
> {{CassandraEntireSSTableStreamReader#read}}.
> {code}
> Currently, entire-sstable-streaming requires sstable components to be
> immutable, because \{{ComponentManifest}}
> with component
[jira] [Updated] (CASSANDRA-15861) Mutating sstable component may race with entire-sstable-streaming(ZCS) causing checksum validation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-15861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15861:
--
Reviewers: Benjamin Lerer, Blake Eggleston, Caleb Rackliffe, David Capwell
(was: Benjamin Lerer, Blake Eggleston, Caleb Rackliffe)
> Mutating sstable component may race with entire-sstable-streaming(ZCS)
> causing checksum validation failure
> --
>
> Key: CASSANDRA-15861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15861
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming,
> Local/Compaction
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Flaky dtest: [test_dead_sync_initiator -
> repair_tests.repair_test.TestRepair|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-dtest/143/testReport/junit/dtest.repair_tests.repair_test/TestRepair/test_dead_sync_initiator/]
> {code:java|title=stacktrace}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [Stream-Deserializer-127.0.0.1:7000-570871f3] 2020-06-03 04:05:19,081
> CassandraEntireSSTableStreamReader.java:145 - [Stream
> 6f1c3360-a54f-11ea-a808-2f23710fdc90] Error while reading sstable from stream
> for table = keyspace1.standard1
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.maybeValidateChecksum(MetadataSerializer.java:219)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:198)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:129)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.mutate(MetadataSerializer.java:226)
> at
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:140)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:78)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:49)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:181)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: Checksums do not match for
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> {code}
>
> In the above test, it executes "nodetool repair" on node1 and kills node2
> during repair. At the end, node3 reports checksum validation failure on
> sstable transferred from node1.
> {code:java|title=what happened}
> 1. When repair started on node1, it performs anti-compaction which modifies
> sstable's repairAt to 0 and pending repair id to session-id.
> 2. Then node1 creates {{ComponentManifest}} which contains file lengths to be
> transferred to node3.
> 3. Before node1 actually sends the files to node3, node2 is killed and node1
> starts to broadcast repair-failure-message to all participants in
> {{CoordinatorSession#fail}}
> 4. Node1 receives its own repair-failure-message and fails its local repair
> sessions at {{LocalSessions#failSession}} which triggers async background
> compaction.
> 5. Node1's background compaction will mutate sstable's repairAt to 0 and
> pending repair id to null via
> {{PendingRepairManager#getNextRepairFinishedTask}}, as there is no more
> in-progress repair.
> 6. Node1 actually sends the sstable to node3 where the sstable's STATS
> component size is different from the original size recorded in the manifest.
> 7. At the end, node3 reports checksum validation failure when it tries to
> mutate sstable level and "isTransient" attribute in
> {{CassandraEntireSSTableStreamReader#read}}.
> {code}
> Currently, entire-sstable-streaming requires sstable components to be
> immutable, because \{{ComponentManifest}}
> with component sizes are sent before sending actual files. This isn't a
> problem in legacy streaming as STATS file length didn't matter.
>
> Ideally
[jira] [Created] (CASSANDRA-16097) DigestResolver.getData throws AssertionError since dataResponse is null
David Capwell created CASSANDRA-16097:
-
Summary: DigestResolver.getData throws AssertionError since
dataResponse is null
Key: CASSANDRA-16097
URL: https://issues.apache.org/jira/browse/CASSANDRA-16097
Project: Cassandra
Issue Type: Bug
Components: Consistency/Coordination
Reporter: David Capwell
Was running a benchmark at LOCAL_ONE and eventually saw the below exception
{code}
2020-09-02 21:08:59,872 ERROR [Native-Transport-Requests-35]
org.apache.cassandra.transport.Message - Unexpected exception during request;
channel = [id: 0x13bb89d4, L:/10.14.92.74:9042 - R:/10.14.89.248:47112]
java.lang.AssertionError
at
org.apache.cassandra.service.reads.DigestResolver.getData(DigestResolver.java:77)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:390)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1821)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1711)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1628)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1097)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:294)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:246)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:498)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:476)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:138)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
[?:?]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[netty-all-4.1.50.Final.jar:4.1.50.Final]
at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
{code}
This exception was not frequent, out of the whole run (3h) only saw this twice.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16097) DigestResolver.getData throws AssertionError since dataResponse is null
[
https://issues.apache.org/jira/browse/CASSANDRA-16097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16097:
--
Bug Category: Parent values: Availability(12983)Level 1 values: Response
Crash(12991)
Complexity: Normal
Discovered By: Performance Regression Test
Fix Version/s: 4.0-beta
Severity: Normal
Status: Open (was: Triage Needed)
> DigestResolver.getData throws AssertionError since dataResponse is null
> ---
>
> Key: CASSANDRA-16097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16097
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Was running a benchmark at LOCAL_ONE and eventually saw the below exception
> {code}
> 2020-09-02 21:08:59,872 ERROR [Native-Transport-Requests-35]
> org.apache.cassandra.transport.Message - Unexpected exception during request;
> channel = [id: 0x13bb89d4, L:/10.14.92.74:9042 - R:/10.14.89.248:47112]
> java.lang.AssertionError
>at
> org.apache.cassandra.service.reads.DigestResolver.getData(DigestResolver.java:77)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:390)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1821)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1711)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1628)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1097)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:294)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:246)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:498)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:476)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:138)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
>at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> {code}
> This exception was not frequent, out of the whole run (3h) only saw this
> twice.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16091) rpc server gets wrongly initialized with rpc_enabled:false
[
https://issues.apache.org/jira/browse/CASSANDRA-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-16091:
Assignee: Brandon Williams
> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tom van der Woerdt
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.9
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception
> is thrown:
> {code:java}
> java.lang.RuntimeException: Client SSL is not supported for non-blocking
> sockets (hsha). Please remove client ssl from the configuration.
> at
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
> at
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
> at
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
> at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
> at
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
> at
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does
> resolve the issue, as expected, but this does seem like a regression, hence
> the Jira issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15992) Fix flaky python dtest test_13595 - consistency_test.TestConsistency
[
https://issues.apache.org/jira/browse/CASSANDRA-15992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189709#comment-17189709
]
Brandon Williams commented on CASSANDRA-15992:
--
Any thoughts on this analysis, [~aleksey]?
> Fix flaky python dtest test_13595 - consistency_test.TestConsistency
>
>
> Key: CASSANDRA-15992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15992
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/355/workflows/7b8df61d-706f-4094-a206-7cdc6b4e0451/jobs/1818
> {code}
> > assert 9 == jmx.read_attribute(srp, 'Count')
> E AssertionError: assert 9 == 5
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11402) Alignment wrong in tpstats output for PerDiskMemtableFlushWriter and format to YAML is broken
[ https://issues.apache.org/jira/browse/CASSANDRA-11402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-11402: - Fix Version/s: (was: 4.0-beta) 4.0-beta3 Since Version: 4.0-alpha1 Source Control Link: https://github.com/apache/cassandra/commit/2dbba13fdb555b3a297a7677896091cc880b5da5 Resolution: Fixed Status: Resolved (was: Ready to Commit) Fair enough, it can't get any more broken than it was. I think we could still do an 'improper' test in a unit test, but we'll leave it for now. > Alignment wrong in tpstats output for PerDiskMemtableFlushWriter and format > to YAML is broken > - > > Key: CASSANDRA-11402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11402 > Project: Cassandra > Issue Type: Bug >Reporter: Joel Knighton >Assignee: Stefan Miklosovic >Priority: Low > Labels: lhf > Fix For: 4.0-beta3 > > Attachments: 11402-3_5_patch1.patch, 11402-trunk.txt > > > With the accompanying designation of which memtableflushwriter it is, this > threadpool name is too long for the hardcoded padding in tpstats output. > We should dynamically calculate padding so that we don't need to check this > every time we add a threadpool. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11402) Alignment wrong in tpstats output for PerDiskMemtableFlushWriter and format to YAML is broken
[ https://issues.apache.org/jira/browse/CASSANDRA-11402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-11402: - Status: Ready to Commit (was: Review In Progress) > Alignment wrong in tpstats output for PerDiskMemtableFlushWriter and format > to YAML is broken > - > > Key: CASSANDRA-11402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11402 > Project: Cassandra > Issue Type: Bug >Reporter: Joel Knighton >Assignee: Stefan Miklosovic >Priority: Low > Labels: lhf > Fix For: 4.0-beta > > Attachments: 11402-3_5_patch1.patch, 11402-trunk.txt > > > With the accompanying designation of which memtableflushwriter it is, this > threadpool name is too long for the hardcoded padding in tpstats output. > We should dynamically calculate padding so that we don't need to check this > every time we add a threadpool. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Fix yaml format and alignment in tpstats
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 2dbba13 Fix yaml format and alignment in tpstats
2dbba13 is described below
commit 2dbba13fdb555b3a297a7677896091cc880b5da5
Author: Stefan Miklosovic
AuthorDate: Fri Aug 21 20:01:30 2020 +0200
Fix yaml format and alignment in tpstats
Patch by Stefan Miklosovic, reviewed by brandonwilliams for
CASSANDRA-11402
---
CHANGES.txt| 1 +
src/java/org/apache/cassandra/tools/NodeProbe.java | 40 +--
.../cassandra/tools/nodetool/ProxyHistograms.java | 12 ++--
.../cassandra/tools/nodetool/TableHistograms.java | 6 +-
.../apache/cassandra/tools/nodetool/TpStats.java | 2 -
.../tools/nodetool/stats/TpStatsHolder.java| 3 +-
.../tools/nodetool/stats/TpStatsPrinter.java | 78 +++---
7 files changed, 85 insertions(+), 57 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 14df925..92c6b87 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
4.0-beta3
* Add nodetool getfullquerylog (CASSANDRA-15988)
+ * Fix yaml format and alignment in tpstats (CASSANDRA-11402)
4.0-beta2
* Add addition incremental repair visibility to nodetool repair_admin
(CASSANDRA-14939)
diff --git a/src/java/org/apache/cassandra/tools/NodeProbe.java
b/src/java/org/apache/cassandra/tools/NodeProbe.java
index 685c153..3020fec 100644
--- a/src/java/org/apache/cassandra/tools/NodeProbe.java
+++ b/src/java/org/apache/cassandra/tools/NodeProbe.java
@@ -1634,26 +1634,26 @@ public class NodeProbe implements AutoCloseable
}
}
-public double[]
metricPercentilesAsArray(CassandraMetricsRegistry.JmxHistogramMBean metric)
-{
-return new double[]{ metric.get50thPercentile(),
-metric.get75thPercentile(),
-metric.get95thPercentile(),
-metric.get98thPercentile(),
-metric.get99thPercentile(),
-metric.getMin(),
-metric.getMax()};
-}
-
-public double[]
metricPercentilesAsArray(CassandraMetricsRegistry.JmxTimerMBean metric)
-{
-return new double[]{ metric.get50thPercentile(),
-metric.get75thPercentile(),
-metric.get95thPercentile(),
-metric.get98thPercentile(),
-metric.get99thPercentile(),
-metric.getMin(),
-metric.getMax()};
+public Double[]
metricPercentilesAsArray(CassandraMetricsRegistry.JmxHistogramMBean metric)
+{
+return new Double[]{ metric.get50thPercentile(),
+Double.valueOf(metric.get75thPercentile()),
+Double.valueOf(metric.get95thPercentile()),
+Double.valueOf(metric.get98thPercentile()),
+Double.valueOf(metric.get99thPercentile()),
+Double.valueOf(metric.getMin()),
+Double.valueOf(metric.getMax())};
+}
+
+public Double[]
metricPercentilesAsArray(CassandraMetricsRegistry.JmxTimerMBean metric)
+{
+return new Double[]{ Double.valueOf(metric.get50thPercentile()),
+ Double.valueOf(metric.get75thPercentile()),
+ Double.valueOf(metric.get95thPercentile()),
+ Double.valueOf(metric.get98thPercentile()),
+ Double.valueOf(metric.get99thPercentile()),
+ Double.valueOf(metric.getMin()),
+ Double.valueOf(metric.getMax())};
}
public TabularData getCompactionHistory()
diff --git a/src/java/org/apache/cassandra/tools/nodetool/ProxyHistograms.java
b/src/java/org/apache/cassandra/tools/nodetool/ProxyHistograms.java
index 620d75a..1bf31d5 100644
--- a/src/java/org/apache/cassandra/tools/nodetool/ProxyHistograms.java
+++ b/src/java/org/apache/cassandra/tools/nodetool/ProxyHistograms.java
@@ -30,12 +30,12 @@ public class ProxyHistograms extends NodeToolCmd
public void execute(NodeProbe probe)
{
String[] percentiles = {"50%", "75%", "95%", "98%", "99%", "Min",
"Max"};
-double[] readLatency =
probe.metricPercentilesAsArray(probe.getProxyMetric("Read"));
-double[] writeLatency =
probe.metricPercentilesAsArray(probe.getProxyMetric("Write"));
-double[] rangeLatency =
probe.metricPercentilesAsArray(probe.getProxyMetric("RangeSlice"));
-double[] casReadLatency =
probe.metricPercentilesAsArray(probe.getProxyMetric("CASRead"));
-double[] casWriteLatency =
probe.metricPercentilesAsArray(probe.getProxyMetric("CASWrite"));
-double[] viewWriteLatency =
probe.metricPercentilesAsArray(probe.getProxyMetric("ViewWrite"));
+Double[] readLatency =
[jira] [Updated] (CASSANDRA-15992) Fix flaky python dtest test_13595 - consistency_test.TestConsistency
[
https://issues.apache.org/jira/browse/CASSANDRA-15992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-15992:
--
Test and Documentation Plan: Modify existing test to be more relaxed on the
metric validation.
Status: Patch Available (was: In Progress)
> Fix flaky python dtest test_13595 - consistency_test.TestConsistency
>
>
> Key: CASSANDRA-15992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15992
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/355/workflows/7b8df61d-706f-4094-a206-7cdc6b4e0451/jobs/1818
> {code}
> > assert 9 == jmx.read_attribute(srp, 'Count')
> E AssertionError: assert 9 == 5
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15992) Fix flaky python dtest test_13595 - consistency_test.TestConsistency
[
https://issues.apache.org/jira/browse/CASSANDRA-15992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189647#comment-17189647
]
Adam Holmberg commented on CASSANDRA-15992:
---
I have an environment that produced the error every 100 runs or so, but it is
not deterministic. The assertion is failing because we're sometimes not
arriving in
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/reads/ShortReadPartitionsProtection.java#L151]
for one of two SRP iterators created for this query (one per node). The only
way I can see for this to happen is for results iteration to stop before
exhausting both.
My current working theory is that this is possible, and okay due to
[concurrency|https://github.com/apache/cassandra/blob/614d7d06f4964f03681e9e90d98ddf3562c47598/src/java/org/apache/cassandra/service/StorageProxy.java#L2126-L2141],
[potential
variation|https://github.com/apache/cassandra/blob/614d7d06f4964f03681e9e90d98ddf3562c47598/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L616-L635]
in replica iteration, and the potential to
[stop|https://github.com/apache/cassandra/blob/614d7d06f4964f03681e9e90d98ddf3562c47598/src/java/org/apache/cassandra/db/transform/BasePartitions.java#L93]
inner iteration early when [limits are in
play|https://github.com/apache/cassandra-dtest/blob/b00d0c310ff61d3f39c116daeccdf43aa63f2b25/consistency_test.py#L1281].
Sadly I have not once been able to reproduce this with any instrumentation in
the code whatsoever.
Having stalled progress on empirical observation, I wanted to float this static
analysis for some discussion. If it holds water, the change would be to simply
update the test to only require that SRP counter be at least the value of one
of the node ranges (4 or 5).
> Fix flaky python dtest test_13595 - consistency_test.TestConsistency
>
>
> Key: CASSANDRA-15992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15992
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/355/workflows/7b8df61d-706f-4094-a206-7cdc6b4e0451/jobs/1818
> {code}
> > assert 9 == jmx.read_attribute(srp, 'Count')
> E AssertionError: assert 9 == 5
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15158) Wait for schema agreement rather than in flight schema requests when bootstrapping
[ https://issues.apache.org/jira/browse/CASSANDRA-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189642#comment-17189642 ] Blake Eggleston edited comment on CASSANDRA-15158 at 9/2/20, 7:18 PM: -- Possibly, you still need to check in the submission task in case the node has died in the meantime. There would still be an intersection of node flapping rate and unfortunate scheduling where the lockup could occur though. The queue, while a little awkward, also makes us a bit more resilient against other unanticipated states and/or bugs. was (Author: bdeggleston): Possibly, you still need to check in the submission task in case the node has died in the meantime. There would still be an intersection of node flapping rate and unfortunate scheduling where the lockup could occur though > Wait for schema agreement rather than in flight schema requests when > bootstrapping > -- > > Key: CASSANDRA-15158 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15158 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip, Cluster/Schema >Reporter: Vincent White >Assignee: Blake Eggleston >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently when a node is bootstrapping we use a set of latches > (org.apache.cassandra.service.MigrationTask#inflightTasks) to keep track of > in-flight schema pull requests, and we don't proceed with > bootstrapping/stream until all the latches are released (or we timeout > waiting for each one). One issue with this is that if we have a large schema, > or the retrieval of the schema from the other nodes was unexpectedly slow > then we have no explicit check in place to ensure we have actually received a > schema before we proceed. > While it's possible to increase "migration_task_wait_in_seconds" to force the > node to wait on each latche longer, there are cases where this doesn't help > because the callbacks for the schema pull requests have expired off the > messaging service's callback map > (org.apache.cassandra.net.MessagingService#callbacks) after > request_timeout_in_ms (default 10 seconds) before the other nodes were able > to respond to the new node. > This patch checks for schema agreement between the bootstrapping node and the > rest of the live nodes before proceeding with bootstrapping. It also adds a > check to prevent the new node from flooding existing nodes with simultaneous > schema pull requests as can happen in large clusters. > Removing the latch system should also prevent new nodes in large clusters > getting stuck for extended amounts of time as they wait > `migration_task_wait_in_seconds` on each of the latches left orphaned by the > timed out callbacks. > > ||3.11|| > |[PoC|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:check_for_schema]| > |[dtest|https://github.com/apache/cassandra-dtest/compare/master...vincewhite:wait_for_schema_agreement]| > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15158) Wait for schema agreement rather than in flight schema requests when bootstrapping
[ https://issues.apache.org/jira/browse/CASSANDRA-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189642#comment-17189642 ] Blake Eggleston commented on CASSANDRA-15158: - Possibly, you still need to check in the submission task in case the node has died in the meantime. There would still be an intersection of node flapping rate and unfortunate scheduling where the lockup could occur though > Wait for schema agreement rather than in flight schema requests when > bootstrapping > -- > > Key: CASSANDRA-15158 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15158 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip, Cluster/Schema >Reporter: Vincent White >Assignee: Blake Eggleston >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently when a node is bootstrapping we use a set of latches > (org.apache.cassandra.service.MigrationTask#inflightTasks) to keep track of > in-flight schema pull requests, and we don't proceed with > bootstrapping/stream until all the latches are released (or we timeout > waiting for each one). One issue with this is that if we have a large schema, > or the retrieval of the schema from the other nodes was unexpectedly slow > then we have no explicit check in place to ensure we have actually received a > schema before we proceed. > While it's possible to increase "migration_task_wait_in_seconds" to force the > node to wait on each latche longer, there are cases where this doesn't help > because the callbacks for the schema pull requests have expired off the > messaging service's callback map > (org.apache.cassandra.net.MessagingService#callbacks) after > request_timeout_in_ms (default 10 seconds) before the other nodes were able > to respond to the new node. > This patch checks for schema agreement between the bootstrapping node and the > rest of the live nodes before proceeding with bootstrapping. It also adds a > check to prevent the new node from flooding existing nodes with simultaneous > schema pull requests as can happen in large clusters. > Removing the latch system should also prevent new nodes in large clusters > getting stuck for extended amounts of time as they wait > `migration_task_wait_in_seconds` on each of the latches left orphaned by the > timed out callbacks. > > ||3.11|| > |[PoC|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:check_for_schema]| > |[dtest|https://github.com/apache/cassandra-dtest/compare/master...vincewhite:wait_for_schema_agreement]| > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16096) Change style guide to include @Override
[ https://issues.apache.org/jira/browse/CASSANDRA-16096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16096: -- Source Control Link: https://github.com/apache/cassandra/commit/614d7d06f4964f03681e9e90d98ddf3562c47598 (was: https://github.com/apache/cassandra/commit/377fc78320117fda1f56ae992f23b72c6f80532a) > Change style guide to include @Override > --- > > Key: CASSANDRA-16096 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16096 > Project: Cassandra > Issue Type: Improvement > Components: Build, Documentation/Website >Reporter: David Capwell >Assignee: David Capwell >Priority: Low > Fix For: 4.0-beta3 > > > @Override is used by javac to enforce that a method is in fact overriding > from an abstract class or an interface and if this stops being true (such as > a refactor happens) then a compiler error is thrown; when we default to > excluding, it makes it harder to detect that a refactor catches all > implementations and can lead to subtle and hard to track down bugs. > This ticket removes the comment in the docs that @Override should be avoided > and updated the style guide to include them by default. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16096) Change style guide to include @Override
[ https://issues.apache.org/jira/browse/CASSANDRA-16096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16096: -- Fix Version/s: (was: 4.0-beta) 4.0-beta3 Source Control Link: https://github.com/apache/cassandra/commit/377fc78320117fda1f56ae992f23b72c6f80532a Resolution: Fixed Status: Resolved (was: Ready to Commit) > Change style guide to include @Override > --- > > Key: CASSANDRA-16096 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16096 > Project: Cassandra > Issue Type: Improvement > Components: Build, Documentation/Website >Reporter: David Capwell >Assignee: David Capwell >Priority: Low > Fix For: 4.0-beta3 > > > @Override is used by javac to enforce that a method is in fact overriding > from an abstract class or an interface and if this stops being true (such as > a refactor happens) then a compiler error is thrown; when we default to > excluding, it makes it harder to detect that a refactor catches all > implementations and can lead to subtle and hard to track down bugs. > This ticket removes the comment in the docs that @Override should be avoided > and updated the style guide to include them by default. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Change style guide to include @Override
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 614d7d0 Change style guide to include @Override 614d7d0 is described below commit 614d7d06f4964f03681e9e90d98ddf3562c47598 Author: David Capwell AuthorDate: Wed Sep 2 11:34:28 2020 -0700 Change style guide to include @Override patch by David Capwell for CASSANDRA-16096 --- doc/source/development/code_style.rst | 1 - ide/idea/codeStyleSettings.xml| 4 ++-- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/doc/source/development/code_style.rst b/doc/source/development/code_style.rst index 5a486a4..85287ed 100644 --- a/doc/source/development/code_style.rst +++ b/doc/source/development/code_style.rst @@ -35,7 +35,6 @@ Exception handling Boilerplate --- - - Avoid redundant ``@Override`` annotations when implementing abstract or interface methods. - Do not implement equals or hashcode methods unless they are actually needed. - Prefer public final fields to private fields with getters. (But prefer encapsulating behavior in "real" methods to either.) - Prefer requiring initialization in the constructor to setters. diff --git a/ide/idea/codeStyleSettings.xml b/ide/idea/codeStyleSettings.xml index d9190a7..a104924 100644 --- a/ide/idea/codeStyleSettings.xml +++ b/ide/idea/codeStyleSettings.xml @@ -3,7 +3,7 @@ - + @@ -272,4 +272,4 @@ - \ No newline at end of file + - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16096) Change style guide to include @Override
[ https://issues.apache.org/jira/browse/CASSANDRA-16096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16096: -- Reviewers: David Capwell, David Capwell (was: David Capwell) David Capwell, David Capwell Status: Review In Progress (was: Patch Available) > Change style guide to include @Override > --- > > Key: CASSANDRA-16096 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16096 > Project: Cassandra > Issue Type: Improvement > Components: Build, Documentation/Website >Reporter: David Capwell >Assignee: David Capwell >Priority: Low > Fix For: 4.0-beta > > > @Override is used by javac to enforce that a method is in fact overriding > from an abstract class or an interface and if this stops being true (such as > a refactor happens) then a compiler error is thrown; when we default to > excluding, it makes it harder to detect that a refactor catches all > implementations and can lead to subtle and hard to track down bugs. > This ticket removes the comment in the docs that @Override should be avoided > and updated the style guide to include them by default. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16096) Change style guide to include @Override
[ https://issues.apache.org/jira/browse/CASSANDRA-16096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16096: -- Status: Ready to Commit (was: Review In Progress) This was brought up in the thread https://lists.apache.org/thread.html/rb70667623b042feed0cdd37957a71f586bf8a0a25df86696630d3ed0%40%3Cdev.cassandra.apache.org%3E with positive feedback. > Change style guide to include @Override > --- > > Key: CASSANDRA-16096 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16096 > Project: Cassandra > Issue Type: Improvement > Components: Build, Documentation/Website >Reporter: David Capwell >Assignee: David Capwell >Priority: Low > Fix For: 4.0-beta > > > @Override is used by javac to enforce that a method is in fact overriding > from an abstract class or an interface and if this stops being true (such as > a refactor happens) then a compiler error is thrown; when we default to > excluding, it makes it harder to detect that a refactor catches all > implementations and can lead to subtle and hard to track down bugs. > This ticket removes the comment in the docs that @Override should be avoided > and updated the style guide to include them by default. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14801) calculatePendingRanges no longer safe for multiple adjacent range movements
[
https://issues.apache.org/jira/browse/CASSANDRA-14801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-14801:
Status: Changes Suggested (was: Review In Progress)
Thanks [~Ge], this looks pretty good to me, with a few caveats regarding
the QT test.
* Move operations are not permitted when nodes have multiple tokens, so I
think we can split the test into:
** multiple tokens per node with leave and bootstrap operations.
** single token nodes with leave, bootstrap and move operations.
* Any node should be moved at most once per {{Cluster}}
* The rf for each cluster was being hardcoded to 2, we ought to use
{{Input.rf}} when constructing {{Cluster}}
I've pushed a commit with those suggestions
[here|https://github.com/beobal/cassandra/tree/14801-trunk] and kicked off CI
[here|https://app.circleci.com/pipelines/github/beobal/cassandra?branch=14801-trunk].
Would you mind taking a look at the suggestions?
> calculatePendingRanges no longer safe for multiple adjacent range movements
> ---
>
> Key: CASSANDRA-14801
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14801
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Distributed Metadata
>Reporter: Benedict Elliott Smith
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0, 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Correctness depended upon the narrowing to a {{Set}},
> which we no longer do - we maintain a collection of all {{Replica}}. Our
> {{RangesAtEndpoint}} collection built by {{getPendingRanges}} can as a result
> contain the same endpoint multiple times; and our {{EndpointsForToken}}
> obtained by {{TokenMetadata.pendingEndpointsFor}} may fail to be constructed,
> resulting in cluster-wide failures for writes to the affected token ranges
> for the duration of the range movement.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13935) Indexes and UDTs creation should have IF NOT EXISTS on its String representation
[
https://issues.apache.org/jira/browse/CASSANDRA-13935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189621#comment-17189621
]
Stefan Miklosovic commented on CASSANDRA-13935:
---
[~blerer] would you mind to review please? I need 2 reviewers so one more would
be awesome!
> Indexes and UDTs creation should have IF NOT EXISTS on its String
> representation
>
>
> Key: CASSANDRA-13935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13935
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index, Legacy/CQL
> Environment: Ubuntu 16.04.2 LTS
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Javier Canillas
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 4.0-beta
>
> Attachments: 13935-3.0.txt, 13935-3.11.txt, 13935-trunk.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I came across something that bothers me a lot. I'm using snapshots to backup
> data from my Cassandra cluster in case something really bad happens (like
> dropping a table or a keyspace).
> Exercising the recovery actions from those backups, I discover that the
> schema put on the file "schema.cql" as a result of the snapshot has the
> "CREATE IF NOT EXISTS" for the table, but not for the indexes.
> When restoring from snapshots, and relying on the execution of these schemas
> to build up the table structure, everything seems fine for tables without
> secondary indexes, but for the ones that make use of them, the execution of
> these statements fail miserably.
> Here I paste a generated schema.cql content for a table with indexes:
> CREATE TABLE IF NOT EXISTS keyspace1.table1 (
> id text PRIMARY KEY,
> content text,
> last_update_date date,
> last_update_date_time timestamp)
> WITH ID = f1045fc0-2f59-11e7-95ec-295c3c064920
> AND bloom_filter_fp_chance = 0.01
> AND dclocal_read_repair_chance = 0.1
> AND crc_check_chance = 1.0
> AND default_time_to_live = 864
> AND gc_grace_seconds = 864000
> AND min_index_interval = 128
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE'
> AND caching = { 'keys': 'NONE', 'rows_per_partition': 'NONE' }
> AND compaction = { 'max_threshold': '32', 'min_threshold': '4',
> 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' }
> AND compression = { 'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor' }
> AND cdc = false
> AND extensions = { };
> CREATE INDEX table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> I think the last part should be:
> CREATE INDEX IF NOT EXISTS table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> // edit by Stefan Miklosovic
> PR: https://github.com/apache/cassandra/pull/731
> I have added UDTs as part of this patch as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15158) Wait for schema agreement rather than in flight schema requests when bootstrapping
[
https://issues.apache.org/jira/browse/CASSANDRA-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189611#comment-17189611
]
Aleksey Yeschenko commented on CASSANDRA-15158:
---
Oh, I brainfarted that node liveness check was a part of
{{shouldPullFromEndpoint()}}. Could just extend that condition then to add the
liveness check in addition to {{shouldPullFromEndpoint()}}?
> Wait for schema agreement rather than in flight schema requests when
> bootstrapping
> --
>
> Key: CASSANDRA-15158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15158
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Cluster/Schema
>Reporter: Vincent White
>Assignee: Blake Eggleston
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a node is bootstrapping we use a set of latches
> (org.apache.cassandra.service.MigrationTask#inflightTasks) to keep track of
> in-flight schema pull requests, and we don't proceed with
> bootstrapping/stream until all the latches are released (or we timeout
> waiting for each one). One issue with this is that if we have a large schema,
> or the retrieval of the schema from the other nodes was unexpectedly slow
> then we have no explicit check in place to ensure we have actually received a
> schema before we proceed.
> While it's possible to increase "migration_task_wait_in_seconds" to force the
> node to wait on each latche longer, there are cases where this doesn't help
> because the callbacks for the schema pull requests have expired off the
> messaging service's callback map
> (org.apache.cassandra.net.MessagingService#callbacks) after
> request_timeout_in_ms (default 10 seconds) before the other nodes were able
> to respond to the new node.
> This patch checks for schema agreement between the bootstrapping node and the
> rest of the live nodes before proceeding with bootstrapping. It also adds a
> check to prevent the new node from flooding existing nodes with simultaneous
> schema pull requests as can happen in large clusters.
> Removing the latch system should also prevent new nodes in large clusters
> getting stuck for extended amounts of time as they wait
> `migration_task_wait_in_seconds` on each of the latches left orphaned by the
> timed out callbacks.
>
> ||3.11||
> |[PoC|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:check_for_schema]|
> |[dtest|https://github.com/apache/cassandra-dtest/compare/master...vincewhite:wait_for_schema_agreement]|
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-11402) Alignment wrong in tpstats output for PerDiskMemtableFlushWriter and format to YAML is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-11402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189607#comment-17189607
]
Stefan Miklosovic edited comment on CASSANDRA-11402 at 9/2/20, 6:09 PM:
[~brandon.williams] I realized that I can not test that. I wanted to use
distributed test where I just start a node and call nodetool against that but
we are not registering any thread pools there.
InternalNodeProbe#getThreadPools() overrides NodeProbe#getThreadPools() with
UnsupportedOperationException().
InternalNodeProbe has this in its connect method:
{code:java}
protected void connect()
{
// note that we are not connecting via JMX for testing
mbeanServerConn = null;
...
}
{code}
Would you mind to go over this manually? It is just too much of a work to spend
on something so trivial like this changing a lot of things, not even sure if it
is possible.
was (Author: stefan.miklosovic):
[~brandon.williams] I realized that I can not test that. I wanted to use
distributed test where I just start a node and call nodetool against that but
we are not registering any thread pools there.
InternalNodeProbe#getThreadPools() overrides NodeProbe#getThreadPools() with
UnsupportedOperationException().
InternalNodeProbe has this in its connect method:
{code:java}
protected void connect()
{
// note that we are not connecting via JMX for testing
mbeanServerConn = null;
...
}
{code}
> Alignment wrong in tpstats output for PerDiskMemtableFlushWriter and format
> to YAML is broken
> -
>
> Key: CASSANDRA-11402
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11402
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: lhf
> Fix For: 4.0-beta
>
> Attachments: 11402-3_5_patch1.patch, 11402-trunk.txt
>
>
> With the accompanying designation of which memtableflushwriter it is, this
> threadpool name is too long for the hardcoded padding in tpstats output.
> We should dynamically calculate padding so that we don't need to check this
> every time we add a threadpool.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11402) Alignment wrong in tpstats output for PerDiskMemtableFlushWriter and format to YAML is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-11402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189607#comment-17189607
]
Stefan Miklosovic commented on CASSANDRA-11402:
---
[~brandon.williams] I realized that I can not test that. I wanted to use
distributed test where I just start a node and call nodetool against that but
we are not registering any thread pools there.
InternalNodeProbe#getThreadPools() overrides NodeProbe#getThreadPools() with
UnsupportedOperationException().
InternalNodeProbe has this in its connect method:
{code:java}
protected void connect()
{
// note that we are not connecting via JMX for testing
mbeanServerConn = null;
...
}
{code}
> Alignment wrong in tpstats output for PerDiskMemtableFlushWriter and format
> to YAML is broken
> -
>
> Key: CASSANDRA-11402
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11402
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: lhf
> Fix For: 4.0-beta
>
> Attachments: 11402-3_5_patch1.patch, 11402-trunk.txt
>
>
> With the accompanying designation of which memtableflushwriter it is, this
> threadpool name is too long for the hardcoded padding in tpstats output.
> We should dynamically calculate padding so that we don't need to check this
> every time we add a threadpool.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15861) Mutating sstable component may race with entire-sstable-streaming(ZCS) causing checksum validation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-15861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189590#comment-17189590
]
David Capwell commented on CASSANDRA-15861:
---
Thanks. FYI I am testing this patch out by constantly rebuilding (though have
to truncate the available range table) while generating load on a cluster,
early results looked good but will let you know (streaming doesn't seem to be
the easiest thing to monitor atm).
> Mutating sstable component may race with entire-sstable-streaming(ZCS)
> causing checksum validation failure
> --
>
> Key: CASSANDRA-15861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15861
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming,
> Local/Compaction
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Flaky dtest: [test_dead_sync_initiator -
> repair_tests.repair_test.TestRepair|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-dtest/143/testReport/junit/dtest.repair_tests.repair_test/TestRepair/test_dead_sync_initiator/]
> {code:java|title=stacktrace}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [Stream-Deserializer-127.0.0.1:7000-570871f3] 2020-06-03 04:05:19,081
> CassandraEntireSSTableStreamReader.java:145 - [Stream
> 6f1c3360-a54f-11ea-a808-2f23710fdc90] Error while reading sstable from stream
> for table = keyspace1.standard1
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.maybeValidateChecksum(MetadataSerializer.java:219)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:198)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:129)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.mutate(MetadataSerializer.java:226)
> at
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:140)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:78)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:49)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:181)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: Checksums do not match for
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> {code}
>
> In the above test, it executes "nodetool repair" on node1 and kills node2
> during repair. At the end, node3 reports checksum validation failure on
> sstable transferred from node1.
> {code:java|title=what happened}
> 1. When repair started on node1, it performs anti-compaction which modifies
> sstable's repairAt to 0 and pending repair id to session-id.
> 2. Then node1 creates {{ComponentManifest}} which contains file lengths to be
> transferred to node3.
> 3. Before node1 actually sends the files to node3, node2 is killed and node1
> starts to broadcast repair-failure-message to all participants in
> {{CoordinatorSession#fail}}
> 4. Node1 receives its own repair-failure-message and fails its local repair
> sessions at {{LocalSessions#failSession}} which triggers async background
> compaction.
> 5. Node1's background compaction will mutate sstable's repairAt to 0 and
> pending repair id to null via
> {{PendingRepairManager#getNextRepairFinishedTask}}, as there is no more
> in-progress repair.
> 6. Node1 actually sends the sstable to node3 where the sstable's STATS
> component size is different from the original size recorded in the manifest.
> 7. At the end, node3 reports checksum validation failure when it tries to
> mutate sstable level and "isTransient" attribute in
> {{CassandraEntireSSTableStreamReader#read}}.
> {code}
> Currently, entire-sstable-streaming requires sstable components to be
> immutable, because
[jira] [Updated] (CASSANDRA-16096) Change style guide to include @Override
[ https://issues.apache.org/jira/browse/CASSANDRA-16096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16096: -- Test and Documentation Plan: deleted project in IntelliJ, ran ant realclean && ant && ant generate-idea-files, then created class based off interface and saw autogenerated methods included @Override Status: Patch Available (was: Open) > Change style guide to include @Override > --- > > Key: CASSANDRA-16096 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16096 > Project: Cassandra > Issue Type: Improvement > Components: Build, Documentation/Website >Reporter: David Capwell >Assignee: David Capwell >Priority: Low > Fix For: 4.0-beta > > > @Override is used by javac to enforce that a method is in fact overriding > from an abstract class or an interface and if this stops being true (such as > a refactor happens) then a compiler error is thrown; when we default to > excluding, it makes it harder to detect that a refactor catches all > implementations and can lead to subtle and hard to track down bugs. > This ticket removes the comment in the docs that @Override should be avoided > and updated the style guide to include them by default. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16096) Change style guide to include @Override
[ https://issues.apache.org/jira/browse/CASSANDRA-16096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16096: -- Change Category: Code Clarity Complexity: Low Hanging Fruit Fix Version/s: 4.0-beta Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Change style guide to include @Override > --- > > Key: CASSANDRA-16096 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16096 > Project: Cassandra > Issue Type: Improvement > Components: Build, Documentation/Website >Reporter: David Capwell >Assignee: David Capwell >Priority: Low > Fix For: 4.0-beta > > > @Override is used by javac to enforce that a method is in fact overriding > from an abstract class or an interface and if this stops being true (such as > a refactor happens) then a compiler error is thrown; when we default to > excluding, it makes it harder to detect that a refactor catches all > implementations and can lead to subtle and hard to track down bugs. > This ticket removes the comment in the docs that @Override should be avoided > and updated the style guide to include them by default. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16096) Change style guide to include @Override
David Capwell created CASSANDRA-16096: - Summary: Change style guide to include @Override Key: CASSANDRA-16096 URL: https://issues.apache.org/jira/browse/CASSANDRA-16096 Project: Cassandra Issue Type: Improvement Components: Build, Documentation/Website Reporter: David Capwell Assignee: David Capwell @Override is used by javac to enforce that a method is in fact overriding from an abstract class or an interface and if this stops being true (such as a refactor happens) then a compiler error is thrown; when we default to excluding, it makes it harder to detect that a refactor catches all implementations and can lead to subtle and hard to track down bugs. This ticket removes the comment in the docs that @Override should be avoided and updated the style guide to include them by default. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15158) Wait for schema agreement rather than in flight schema requests when bootstrapping
[ https://issues.apache.org/jira/browse/CASSANDRA-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189362#comment-17189362 ] Blake Eggleston commented on CASSANDRA-15158: - Thanks Aleksey. Removing requestQueue is going to cause some problems, We need to have some way of cycling requests through the entire set of endpoints reporting a given version. Without one, if the first few endpoints to come out of the iterator are down, we'll get stuck in a loop as we schedule pulls which will immediately fail causing new pulls to be scheduled for the same node. I've updated my branch with your changes and added the request queue back. Since the storage service doesn't really need to fire off migration requests, I also added a commit making the MigrationCoordinator an endpoint change subscriber. So StorageService is responsible for a little less. > Wait for schema agreement rather than in flight schema requests when > bootstrapping > -- > > Key: CASSANDRA-15158 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15158 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip, Cluster/Schema >Reporter: Vincent White >Assignee: Blake Eggleston >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently when a node is bootstrapping we use a set of latches > (org.apache.cassandra.service.MigrationTask#inflightTasks) to keep track of > in-flight schema pull requests, and we don't proceed with > bootstrapping/stream until all the latches are released (or we timeout > waiting for each one). One issue with this is that if we have a large schema, > or the retrieval of the schema from the other nodes was unexpectedly slow > then we have no explicit check in place to ensure we have actually received a > schema before we proceed. > While it's possible to increase "migration_task_wait_in_seconds" to force the > node to wait on each latche longer, there are cases where this doesn't help > because the callbacks for the schema pull requests have expired off the > messaging service's callback map > (org.apache.cassandra.net.MessagingService#callbacks) after > request_timeout_in_ms (default 10 seconds) before the other nodes were able > to respond to the new node. > This patch checks for schema agreement between the bootstrapping node and the > rest of the live nodes before proceeding with bootstrapping. It also adds a > check to prevent the new node from flooding existing nodes with simultaneous > schema pull requests as can happen in large clusters. > Removing the latch system should also prevent new nodes in large clusters > getting stuck for extended amounts of time as they wait > `migration_task_wait_in_seconds` on each of the latches left orphaned by the > timed out callbacks. > > ||3.11|| > |[PoC|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:check_for_schema]| > |[dtest|https://github.com/apache/cassandra-dtest/compare/master...vincewhite:wait_for_schema_agreement]| > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16093) Cassandra website is building/including the wrong versioned nodetool docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16093: --- Status: Patch Available (was: In Progress) In-tree patch at [here|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_16093] (one-liner). > Cassandra website is building/including the wrong versioned nodetool docs > - > > Key: CASSANDRA-16093 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16093 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 3.11.9, 4.0-beta3 > > > For example > https://cassandra.apache.org/doc/3.11/tools/nodetool/enablefullquerylog.html > shouldn't be under the 3.11 documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15988) Add nodetool getfullquerylog
[ https://issues.apache.org/jira/browse/CASSANDRA-15988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15988: - Status: Ready to Commit (was: Review In Progress) > Add nodetool getfullquerylog > - > > Key: CASSANDRA-15988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15988 > Project: Cassandra > Issue Type: Improvement > Components: Tool/fql >Reporter: Ekaterina Dimitrova >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 1h 20m > Remaining Estimate: 0h > > This ticket is raised based on CASSANDRA-15791 and valuable feedback provided > by [~jshook]. > There are two outstanding questions: > * forming the exact shape of such a command and how it can benefit the > users; to be discussed in detail in this ticket > * Is this a thing we as a project can add to 4.0 beta or it should be > considered in 4.1 for example > PR: https://github.com/apache/cassandra/pull/721 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15988) Add nodetool getfullquerylog
[ https://issues.apache.org/jira/browse/CASSANDRA-15988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15988: - Fix Version/s: (was: 4.0-rc) 4.0-beta3 Source Control Link: https://github.com/apache/cassandra/commit/419099c92b1cecb7d22fba99ae8ac2cce4f39638 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed, thanks. > Add nodetool getfullquerylog > - > > Key: CASSANDRA-15988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15988 > Project: Cassandra > Issue Type: Improvement > Components: Tool/fql >Reporter: Ekaterina Dimitrova >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-beta3 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > This ticket is raised based on CASSANDRA-15791 and valuable feedback provided > by [~jshook]. > There are two outstanding questions: > * forming the exact shape of such a command and how it can benefit the > users; to be discussed in detail in this ticket > * Is this a thing we as a project can add to 4.0 beta or it should be > considered in 4.1 for example > PR: https://github.com/apache/cassandra/pull/721 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15988) Add nodetool getfullquerylog
[ https://issues.apache.org/jira/browse/CASSANDRA-15988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15988: - Reviewers: Berenguer Blasi, Brandon Williams, David Capwell (was: Berenguer Blasi, David Capwell) > Add nodetool getfullquerylog > - > > Key: CASSANDRA-15988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15988 > Project: Cassandra > Issue Type: Improvement > Components: Tool/fql >Reporter: Ekaterina Dimitrova >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-beta3 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > This ticket is raised based on CASSANDRA-15791 and valuable feedback provided > by [~jshook]. > There are two outstanding questions: > * forming the exact shape of such a command and how it can benefit the > users; to be discussed in detail in this ticket > * Is this a thing we as a project can add to 4.0 beta or it should be > considered in 4.1 for example > PR: https://github.com/apache/cassandra/pull/721 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: add nodetool getfullquerylog command
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 419099c add nodetool getfullquerylog command
419099c is described below
commit 419099c92b1cecb7d22fba99ae8ac2cce4f39638
Author: Stefan Miklosovic
AuthorDate: Fri Aug 28 12:44:48 2020 +0200
add nodetool getfullquerylog command
Patch by Stefan Miklosovic; reviewed by Berenguer Blasi, brandonwilliams,
and dcapwell for
CASSANDRA-15988
---
CHANGES.txt| 1 +
doc/source/new/fqllogging.rst | 19 +++
.../org/apache/cassandra/fql/FullQueryLogger.java | 27
.../fql/FullQueryLoggerOptionsCompositeData.java | 115 +
.../apache/cassandra/service/StorageService.java | 13 ++
.../cassandra/service/StorageServiceMBean.java | 8 +-
src/java/org/apache/cassandra/tools/NodeProbe.java | 7 +
src/java/org/apache/cassandra/tools/NodeTool.java | 1 +
.../cassandra/tools/nodetool/GetFullQueryLog.java | 48 +++
.../org/apache/cassandra/utils/binlog/BinLog.java | 41 --
.../cassandra/tools/GetFullQueryLogTest.java | 141 +
11 files changed, 407 insertions(+), 14 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index a7ed819..14df925 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-beta3
+ * Add nodetool getfullquerylog (CASSANDRA-15988)
4.0-beta2
* Add addition incremental repair visibility to nodetool repair_admin
(CASSANDRA-14939)
diff --git a/doc/source/new/fqllogging.rst b/doc/source/new/fqllogging.rst
index 5a78931..daead9c 100644
--- a/doc/source/new/fqllogging.rst
+++ b/doc/source/new/fqllogging.rst
@@ -171,6 +171,25 @@ For example: ``max_archive_retries: 10``
FQL can also be configured using ``nodetool`` when enabling the feature, and
will override any values set in the `cassandra.yaml` file, as discussed in the
next section.
+Querying the state of FQL
+-
+
+In order to know what state FQL is in, you may use nodetool command
``getfullquerylog``. It will print out whether FQL is enabled
+and with what configuration options; if you reset or stop FQL, the
configuration displayed will be taken from
+configuration in ``cassandra.yaml``.
+
+::
+
+ $ nodetool getfullquerylog
+ enabled true
+ log_dir /path/to/fql/log/dir
+ archive_command /usr/local/bin/archiveit.sh %path
+ roll_cycle HOURLY
+ block true
+ max_log_size17179869184
+ max_queue_weight268435456
+ max_archive_retries 10
+
Enabling FQL
diff --git a/src/java/org/apache/cassandra/fql/FullQueryLogger.java
b/src/java/org/apache/cassandra/fql/FullQueryLogger.java
index 6c38166..4b40635 100644
--- a/src/java/org/apache/cassandra/fql/FullQueryLogger.java
+++ b/src/java/org/apache/cassandra/fql/FullQueryLogger.java
@@ -20,6 +20,7 @@ package org.apache.cassandra.fql;
import java.io.File;
import java.nio.ByteBuffer;
import java.nio.file.Path;
+import java.nio.file.Paths;
import java.util.ArrayList;
import java.util.List;
import java.util.Set;
@@ -37,6 +38,7 @@ import io.netty.buffer.ByteBuf;
import net.openhft.chronicle.bytes.BytesStore;
import net.openhft.chronicle.wire.ValueOut;
import net.openhft.chronicle.wire.WireOut;
+import org.apache.cassandra.config.DatabaseDescriptor;
import org.apache.cassandra.cql3.CQLStatement;
import org.apache.cassandra.cql3.QueryEvents;
import org.apache.cassandra.cql3.QueryOptions;
@@ -46,6 +48,7 @@ import org.apache.cassandra.transport.CBUtil;
import org.apache.cassandra.transport.Message;
import org.apache.cassandra.utils.ObjectSizes;
import org.apache.cassandra.utils.binlog.BinLog;
+import org.apache.cassandra.utils.binlog.BinLogOptions;
import org.apache.cassandra.utils.concurrent.WeightedQueue;
import org.github.jamm.MemoryLayoutSpecification;
@@ -117,6 +120,30 @@ public class FullQueryLogger implements
QueryEvents.Listener
}
}
+public FullQueryLoggerOptions getFullQueryLoggerOptions()
+{
+if (isEnabled())
+{
+final FullQueryLoggerOptions options = new
FullQueryLoggerOptions();
+final BinLogOptions binLogOptions = binLog.getBinLogOptions();
+
+options.archive_command = binLogOptions.archive_command;
+options.roll_cycle = binLogOptions.roll_cycle;
+options.block = binLogOptions.block;
+options.max_archive_retries = binLogOptions.max_archive_retries;
+options.max_queue_weight = binLogOptions.max_queue_weight;
+options.max_log_size = binLogOptions.max_log_size;
+options.log_dir = binLog.path.toString();
+
+return options;
+}
+else
+{
+// otherwise get what database is configured with
[jira] [Updated] (CASSANDRA-15326) Unable to compute ceiling for max when histogram overflowed
[ https://issues.apache.org/jira/browse/CASSANDRA-15326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-15326: - Resolution: Fixed Status: Resolved (was: Triage Needed) > Unable to compute ceiling for max when histogram overflowed > --- > > Key: CASSANDRA-15326 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15326 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Batch Log >Reporter: HsuML >Priority: Normal > > I have 9 cassandra nodes. When I create a keyspace that has 15 tables and the > record count of all table are about 8.2 billion. I imported data through my > java loaders, and I found out the system.log has error message. What happened > and how can I solve the error? > Exception in thread Thread[CompactionExecutor:113041,1,main] > java.lang.IllegalStateException: Unable to compute ceiling for max when > histogram overflowed > at > org.apache.cassandra.utils.EstimatedHistogram.rawMean(EstimatedHistogram.java:231) > ~[apache-cassandra-3.11.4.jar:3.11.4] > at > org.apache.cassandra.utils.EstimatedHistogram.mean(EstimatedHistogram.java:220) > ~[apache-cassandra-3.11.4.jar:3.11.4] > at > org.apache.cassandra.io.sstable.metadata.StatsMetadata.getEstimatedDroppableTombstoneRatio(StatsMetadata.java:115) > ~[apache-cassandra-3.11.4.jar:3.11.4] > at > org.apache.cassandra.io.sstable.format.SSTableReader.getEstimatedDroppableTombstoneRatio(SSTableReader.java:1926) > ~[apache-cassandra-3.11.4.jar:3.11.4] > at > org.apache.cassandra.db.compaction.AbstractCompactionStrategy.worthDroppingTombstones(AbstractCompactionStrategy.java:424) > ~[apache-cassandra-3.11.4.jar:3.11.4] > at > org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundSSTables(SizeTieredCompactionStrategy.java:99) > ~[apache-cassandra-3.11.4.jar:3.11.4] > at > org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundTask(SizeTieredCompactionStrategy.java:183) > ~[apache-cassandra-3.11.4.jar:3.11.4] > at > org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:153) > ~[apache-cassandra-3.11.4.jar:3.11.4] > at > org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:260) > ~[apache-cassandra-3.11.4.jar:3.11.4] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > ~[na:1.8.0_191] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > ~[na:1.8.0_191] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > ~[na:1.8.0_191] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > [na:1.8.0_191] > at > org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81) > [apache-cassandra-3.11.4.jar:3.11.4] > at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_191] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15325) Unable to compute ceiling for max when histogram overflowed
[ https://issues.apache.org/jira/browse/CASSANDRA-15325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-15325: - Resolution: Fixed Status: Resolved (was: Triage Needed) > Unable to compute ceiling for max when histogram overflowed > --- > > Key: CASSANDRA-15325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15325 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Batch Log, CQL/Interpreter >Reporter: HsuML >Priority: Normal > Attachments: log.txt > > > I have 9 cassandra nodes. When I create a keyspace that has 15 tables and the > record count of all table are about 8.2 billion. I imported data through my > java loaders, and I found out the system.log has error message. What happened > and how can I solve the error? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16093) Cassandra website is building/including the wrong versioned nodetool docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16093: --- Status: Open (was: Resolved) Re-opened. This need a patch in-tree for the proper cleanup. > Cassandra website is building/including the wrong versioned nodetool docs > - > > Key: CASSANDRA-16093 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16093 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 3.11.9, 4.0-beta3 > > > For example > https://cassandra.apache.org/doc/3.11/tools/nodetool/enablefullquerylog.html > shouldn't be under the 3.11 documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16093) Cassandra website is building/including the wrong versioned nodetool docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16093: --- Reviewers: Anthony Grasso (was: Anthony Grasso, Michael Semb Wever) > Cassandra website is building/including the wrong versioned nodetool docs > - > > Key: CASSANDRA-16093 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16093 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 3.11.9, 4.0-beta3 > > > For example > https://cassandra.apache.org/doc/3.11/tools/nodetool/enablefullquerylog.html > shouldn't be under the 3.11 documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16093) Cassandra website is building/including the wrong versioned nodetool docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16093: --- Fix Version/s: 4.0-beta3 3.11.9 Since Version: 3.11.3 Source Control Link: https://github.com/apache/cassandra-website/commit/6ac702768d90421c4b8b1eb0762a4f3cca65bb1e Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as [6ac702768d90421c4b8b1eb0762a4f3cca65bb1e|https://github.com/apache/cassandra-website/commit/6ac702768d90421c4b8b1eb0762a4f3cca65bb1e]. > Cassandra website is building/including the wrong versioned nodetool docs > - > > Key: CASSANDRA-16093 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16093 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 3.11.9, 4.0-beta3 > > > For example > https://cassandra.apache.org/doc/3.11/tools/nodetool/enablefullquerylog.html > shouldn't be under the 3.11 documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch master updated (85519e8 -> 1e70042)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
from 85519e8 add generated docs for 3.11.9 and 4.0-beta2
add 6ac7027 Cassandra website is building/including the wrong versioned
nodetool docs
add 1e70042 regenerate versioned docs in master after CASSANDRA-16093 fix
No new revisions were added by this update.
Summary of changes:
Dockerfile | 3 +-
docker-entrypoint.sh | 36 ++--
src/Makefile | 8 +
.../_sources/tools/nodetool/clientstats.rst.txt| 11 -
.../tools/nodetool/disableauditlog.rst.txt | 11 -
.../tools/nodetool/disablefullquerylog.rst.txt | 11 -
.../nodetool/disableoldprotocolversions.rst.txt| 11 -
.../_sources/tools/nodetool/disablethrift.rst.txt | 11 +
.../_sources/tools/nodetool/enableauditlog.rst.txt | 11 -
.../tools/nodetool/enablefullquerylog.rst.txt | 11 -
.../nodetool/enableoldprotocolversions.rst.txt | 11 -
.../_sources/tools/nodetool/enablethrift.rst.txt | 11 +
.../nodetool/getbatchlogreplaythrottle.rst.txt | 11 -
.../_sources/tools/nodetool/getconcurrency.rst.txt | 11 -
.../nodetool/getconcurrentviewbuilders.rst.txt | 11 -
.../tools/nodetool/getmaxhintwindow.rst.txt| 11 -
.../_sources/tools/nodetool/getreplicas.rst.txt| 11 -
.../_sources/tools/nodetool/getseeds.rst.txt | 11 -
.../_sources/tools/nodetool/handoffwindow.rst.txt | 11 -
.../3.11.5/_sources/tools/nodetool/import.rst.txt | 11 -
.../_sources/tools/nodetool/nodetool.rst.txt | 71 +--
.../_sources/tools/nodetool/profileload.rst.txt| 11 -
.../_sources/tools/nodetool/reloadseeds.rst.txt| 11 -
.../_sources/tools/nodetool/reloadssl.rst.txt | 11 -
.../_sources/tools/nodetool/repair_admin.rst.txt | 11 -
.../tools/nodetool/resetfullquerylog.rst.txt | 11 -
.../nodetool/setbatchlogreplaythrottle.rst.txt | 11 -
.../_sources/tools/nodetool/setconcurrency.rst.txt | 11 -
.../nodetool/setconcurrentviewbuilders.rst.txt | 11 -
.../tools/nodetool/setmaxhintwindow.rst.txt| 11 -
src/doc/3.11.5/_sources/tools/nodetool/sjk.rst.txt | 11 -
.../tools/nodetool/statusautocompaction.rst.txt| 11 -
.../_sources/tools/nodetool/statusthrift.rst.txt | 11 +
src/doc/3.11.5/objects.inv | Bin 8167 -> 7538 bytes
src/doc/3.11.5/searchindex.js | 2 +-
src/doc/3.11.5/tools/nodetool/assassinate.html | 5 +-
src/doc/3.11.5/tools/nodetool/bootstrap.html | 11 +-
src/doc/3.11.5/tools/nodetool/cleanup.html | 5 +-
src/doc/3.11.5/tools/nodetool/clearsnapshot.html | 10 +-
src/doc/3.11.5/tools/nodetool/clientstats.html | 133 -
src/doc/3.11.5/tools/nodetool/compact.html | 5 +-
.../3.11.5/tools/nodetool/compactionhistory.html | 5 +-
src/doc/3.11.5/tools/nodetool/compactionstats.html | 5 +-
src/doc/3.11.5/tools/nodetool/decommission.html| 11 +-
src/doc/3.11.5/tools/nodetool/describecluster.html | 5 +-
src/doc/3.11.5/tools/nodetool/describering.html| 5 +-
src/doc/3.11.5/tools/nodetool/disableauditlog.html | 123
.../tools/nodetool/disableautocompaction.html | 5 +-
src/doc/3.11.5/tools/nodetool/disablebackup.html | 5 +-
src/doc/3.11.5/tools/nodetool/disablebinary.html | 5 +-
.../3.11.5/tools/nodetool/disablefullquerylog.html | 123
src/doc/3.11.5/tools/nodetool/disablegossip.html | 5 +-
src/doc/3.11.5/tools/nodetool/disablehandoff.html | 5 +-
.../3.11.5/tools/nodetool/disablehintsfordc.html | 5 +-
.../tools/nodetool/disableoldprotocolversions.html | 123
.../nodetool/{join.html => disablethrift.html} | 15 +-
src/doc/3.11.5/tools/nodetool/drain.html | 5 +-
src/doc/3.11.5/tools/nodetool/enableauditlog.html | 157 ---
.../tools/nodetool/enableautocompaction.html | 5 +-
src/doc/3.11.5/tools/nodetool/enablebackup.html| 5 +-
src/doc/3.11.5/tools/nodetool/enablebinary.html| 5 +-
.../3.11.5/tools/nodetool/enablefullquerylog.html | 154 --
src/doc/3.11.5/tools/nodetool/enablegossip.html| 5 +-
src/doc/3.11.5/tools/nodetool/enablehandoff.html | 5 +-
.../3.11.5/tools/nodetool/enablehintsfordc.html| 5 +-
.../tools/nodetool/enableoldprotocolversions.html | 123
.../nodetool/{join.html => enablethrift.html} | 15 +-
src/doc/3.11.5/tools/nodetool/failuredetector.html | 5 +-
src/doc/3.11.5/tools/nodetool/flush.html | 5 +-
src/doc/3.11.5/tools/nodetool/garbagecollect.html | 5 +-
src/doc/3.11.5/tools/nodetool/gcstats.html | 5 +-
.../tools/nodetool/getbatchlogreplaythrottle.html | 125
[jira] [Updated] (CASSANDRA-16093) Cassandra website is building/including the wrong versioned nodetool docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16093: --- Reviewers: Anthony Grasso, Michael Semb Wever Status: Review In Progress (was: Patch Available) > Cassandra website is building/including the wrong versioned nodetool docs > - > > Key: CASSANDRA-16093 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16093 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > For example > https://cassandra.apache.org/doc/3.11/tools/nodetool/enablefullquerylog.html > shouldn't be under the 3.11 documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16093) Cassandra website is building/including the wrong versioned nodetool docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16093: --- Status: Ready to Commit (was: Review In Progress) Suggestions addressed/applied. Thanks [~Anthony Grasso]. > Cassandra website is building/including the wrong versioned nodetool docs > - > > Key: CASSANDRA-16093 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16093 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > For example > https://cassandra.apache.org/doc/3.11/tools/nodetool/enablefullquerylog.html > shouldn't be under the 3.11 documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15949) NPE thrown while updating speculative execution time if table is removed during task execution
[ https://issues.apache.org/jira/browse/CASSANDRA-15949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe reassigned CASSANDRA-15949: --- Assignee: Caleb Rackliffe > NPE thrown while updating speculative execution time if table is removed > during task execution > -- > > Key: CASSANDRA-15949 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15949 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Jon Meredith >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-beta > > > CASSANDRA-14338 fixed the scheduling the speculation retry threshold > calculation, but if the task happens to be scheduled while a table is being > dropped, it triggers an NPE. > ERROR 2020-07-14T11:34:55,762 [OptionalTasks:1] > org.apache.cassandra.service.CassandraDaemon:446 - Exception in thread > Thread[OptionalTasks:1,5,main] > java.lang.NullPointerException: null > at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:444) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.(Keyspace.java:346) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:139) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:116) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:102) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:99) > ~[cassandra-4.0.0.jar:4.0.0] > at > com.google.common.collect.Iterables$5.lambda$forEach$0(Iterables.java:704) > ~[guava-27.0-jre.jar:?] > at > com.google.common.collect.IndexedImmutableSet.forEach(IndexedImmutableSet.java:45) > ~[guava-27.0-jre.jar:?] > at com.google.common.collect.Iterables$5.forEach(Iterables.java:704) > ~[guava-27.0-jre.jar:?] > at > org.apache.cassandra.service.CassandraDaemon.lambda$setup$2(CassandraDaemon.java:412) > ~[cassandra-4.0.0.jar:4.0.0] > at > org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118) > [cassandra-4.0.0.jar:4.0.0] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > [?:?] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > [?:?] > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > [netty-all-4.1.37.Final.jar:4.1.37.Final] > at java.lang.Thread.run(Thread.java:834) [?:?] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15393) Add byte array backed cells
[
https://issues.apache.org/jira/browse/CASSANDRA-15393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189237#comment-17189237
]
Marcus Eriksson edited comment on CASSANDRA-15393 at 9/2/20, 2:10 PM:
--
First pass done, LGTM in general, I'll try to get a second pass done this week.
*Issues*
{{CounterContext.java}}
* {{hasLegacyShards(..)}} {{totalCount}} looks wrong, should probably be {{int
totalCount = (accessor.size(context) - headerLength(context, accessor)) /
STEP_LENGTH;}}
{{ByteBufferAccessor.java}}
* {{digest(..)}} needs to add {{value.position}} to {{offset}} edit: maybe
not, guess value.position should always be 0 now
{{DynamicCompositeType.java}}
* in {{validateComparator(..)}}, adds {{1}} to {{offset}} after reading a
{{short}}
*Nits*
General stuff
* Slightly inconsistent use of {{TypeSizes.INT_SIZE}} /
{{TypeSize.sizeof(int)}} / hard coded {{4}}, I'd probably prefer being explicit
and use X_SIZE, mostly since we represent shorts etc in ints
* A few places added the {{left}} / {{right}} / {{accessorL}} / {{accessorR}}
parameters, but then have {{offset1/offset2/size1/size2}} - maybe rename these
to {{offsetL/offsetR}} etc
{{CQL3Type.java}}
* {{generateXCQLLiteral}}: no need to return the offset
* unused import ByteBufferUtil
{{AbstractClusteringPrefix.java}}
* maybe bring up {{size()}} and {{get(i)}} here (as {{getRawValues().length}}
and {{getRawValues()[i]}}), and only leave them overridden in
{{NativeClustering}}
{{ClusteringPrefix.java}}
* {{isBottom}} & {{isTop}} can use {{size()}} instead of
{{getRawValues().length}}
{{ArrayClusteringBound.java}} + {{ArrayClusteringBoundary.java}} +
{{BufferClusteringBound.java}} + {{BufferClusteringBoundary.java}}
* unsharedHeapSizeExcludingData unused
{{AbstractType.java}}
* {{readArray}} unused
{{ByteBufferAccessor.java}}
* in {{compare(..)}} - instead of casting to a {{ByteBuffer}} maybe use
{{accessor.toBuffer(right)}} (same in {{ByteArrayAccessor}})
{{DynamicCompositeType.java}}
* no need to {{getComparatorSize}} in {{getComparator(int i, VL left,
ValueAccessor accessorL, VR right, ValueAccessor accessorR, int
offset1, int offset2)}}
{{MapType.java}}
* don't use {{V}} as the type parameter in {{referencesUserType}} - quite
confusing as it clashes with the {{MapType}} type param
{{ValueAccessor.java}}
* why have {{compare}} / {{compareUnsigned}} with the same parameters?
was (Author: krummas):
First pass done, LGTM in general, I'll try to get a second pass done this week.
*Issues*
{{CounterContext.java}}
* {{hasLegacyShards(..)}} {{totalCount}} looks wrong, should probably be {{int
totalCount = (accessor.size(context) - headerLength(context, accessor)) /
STEP_LENGTH;}}
{{ByteBufferAccessor.java}}
* {{digest(..)}} needs to add {{value.position}} to {{offset}}
{{DynamicCompositeType.java}}
* in {{validateComparator(..)}}, adds {{1}} to {{offset}} after reading a
{{short}}
*Nits*
General stuff
* Slightly inconsistent use of {{TypeSizes.INT_SIZE}} /
{{TypeSize.sizeof(int)}} / hard coded {{4}}, I'd probably prefer being explicit
and use X_SIZE, mostly since we represent shorts etc in ints
* A few places added the {{left}} / {{right}} / {{accessorL}} / {{accessorR}}
parameters, but then have {{offset1/offset2/size1/size2}} - maybe rename these
to {{offsetL/offsetR}} etc
{{CQL3Type.java}}
* {{generateXCQLLiteral}}: no need to return the offset
* unused import ByteBufferUtil
{{AbstractClusteringPrefix.java}}
* maybe bring up {{size()}} and {{get(i)}} here (as {{getRawValues().length}}
and {{getRawValues()[i]}}), and only leave them overridden in
{{NativeClustering}}
{{ClusteringPrefix.java}}
* {{isBottom}} & {{isTop}} can use {{size()}} instead of
{{getRawValues().length}}
{{ArrayClusteringBound.java}} + {{ArrayClusteringBoundary.java}} +
{{BufferClusteringBound.java}} + {{BufferClusteringBoundary.java}}
* unsharedHeapSizeExcludingData unused
{{AbstractType.java}}
* {{readArray}} unused
{{ByteBufferAccessor.java}}
* in {{compare(..)}} - instead of casting to a {{ByteBuffer}} maybe use
{{accessor.toBuffer(right)}} (same in {{ByteArrayAccessor}})
{{DynamicCompositeType.java}}
* no need to {{getComparatorSize}} in {{getComparator(int i, VL left,
ValueAccessor accessorL, VR right, ValueAccessor accessorR, int
offset1, int offset2)}}
{{MapType.java}}
* don't use {{V}} as the type parameter in {{referencesUserType}} - quite
confusing as it clashes with the {{MapType}} type param
{{ValueAccessor.java}}
* why have {{compare}} / {{compareUnsigned}} with the same parameters?
> Add byte array backed cells
> ---
>
> Key: CASSANDRA-15393
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15393
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Compaction
>
[jira] [Commented] (CASSANDRA-15393) Add byte array backed cells
[
https://issues.apache.org/jira/browse/CASSANDRA-15393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189237#comment-17189237
]
Marcus Eriksson commented on CASSANDRA-15393:
-
First pass done, LGTM in general, I'll try to get a second pass done this week.
*Issues*
{{CounterContext.java}}
* {{hasLegacyShards(..)}} {{totalCount}} looks wrong, should probably be {{int
totalCount = (accessor.size(context) - headerLength(context, accessor)) /
STEP_LENGTH;}}
{{ByteBufferAccessor.java}}
* {{digest(..)}} needs to add {{value.position}} to {{offset}}
{{DynamicCompositeType.java}}
* in {{validateComparator(..)}}, adds {{1}} to {{offset}} after reading a
{{short}}
*Nits*
General stuff
* Slightly inconsistent use of {{TypeSizes.INT_SIZE}} /
{{TypeSize.sizeof(int)}} / hard coded {{4}}, I'd probably prefer being explicit
and use X_SIZE, mostly since we represent shorts etc in ints
* A few places added the {{left}} / {{right}} / {{accessorL}} / {{accessorR}}
parameters, but then have {{offset1/offset2/size1/size2}} - maybe rename these
to {{offsetL/offsetR}} etc
{{CQL3Type.java}}
* {{generateXCQLLiteral}}: no need to return the offset
* unused import ByteBufferUtil
{{AbstractClusteringPrefix.java}}
* maybe bring up {{size()}} and {{get(i)}} here (as {{getRawValues().length}}
and {{getRawValues()[i]}}), and only leave them overridden in
{{NativeClustering}}
{{ClusteringPrefix.java}}
* {{isBottom}} & {{isTop}} can use {{size()}} instead of
{{getRawValues().length}}
{{ArrayClusteringBound.java}} + {{ArrayClusteringBoundary.java}} +
{{BufferClusteringBound.java}} + {{BufferClusteringBoundary.java}}
* unsharedHeapSizeExcludingData unused
{{AbstractType.java}}
* {{readArray}} unused
{{ByteBufferAccessor.java}}
* in {{compare(..)}} - instead of casting to a {{ByteBuffer}} maybe use
{{accessor.toBuffer(right)}} (same in {{ByteArrayAccessor}})
{{DynamicCompositeType.java}}
* no need to {{getComparatorSize}} in {{getComparator(int i, VL left,
ValueAccessor accessorL, VR right, ValueAccessor accessorR, int
offset1, int offset2)}}
{{MapType.java}}
* don't use {{V}} as the type parameter in {{referencesUserType}} - quite
confusing as it clashes with the {{MapType}} type param
{{ValueAccessor.java}}
* why have {{compare}} / {{compareUnsigned}} with the same parameters?
> Add byte array backed cells
> ---
>
> Key: CASSANDRA-15393
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15393
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Compaction
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We currently materialize all values as on heap byte buffers. Byte buffers
> have a fairly high overhead given how frequently they’re used, and on the
> compaction and local read path we don’t do anything that needs them. Use of
> byte buffer methods only happens on the coordinator. Using cells that are
> backed by byte arrays instead in these situations reduces compaction and read
> garbage up to 22% in many cases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16093) Cassandra website is building/including the wrong versioned nodetool docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189188#comment-17189188 ] Anthony Grasso commented on CASSANDRA-16093: Pull request [#17|https://github.com/apache/cassandra-website/pull/17] reviewed. Left a few minor comments, however they are non-blocking. > Cassandra website is building/including the wrong versioned nodetool docs > - > > Key: CASSANDRA-16093 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16093 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > For example > https://cassandra.apache.org/doc/3.11/tools/nodetool/enablefullquerylog.html > shouldn't be under the 3.11 documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16091) rpc server gets wrongly initialized with rpc_enabled:false
[
https://issues.apache.org/jira/browse/CASSANDRA-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189163#comment-17189163
]
Tibor Repasi commented on CASSANDRA-16091:
--
As far as I see, thrift was used to be startet at
[CassandraDaemon.java#L546|https://github.com/apache/cassandra/blob/ca37de06ef9760e6dec26e7d443625bc6a9bbc7b/src/java/org/apache/cassandra/service/CassandraDaemon.java#L546]
which is guarded by config property {{cassandra.start_rpc}}.
In the current release,
[CassandraDaemon.java#L713|https://github.com/apache/cassandra/blob/ca37de06ef9760e6dec26e7d443625bc6a9bbc7b/src/java/org/apache/cassandra/service/CassandraDaemon.java#L713]
is also starting the thrift server if native transport is enabled.
> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tom van der Woerdt
>Priority: Normal
> Fix For: 3.11.9
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception
> is thrown:
> {code:java}
> java.lang.RuntimeException: Client SSL is not supported for non-blocking
> sockets (hsha). Please remove client ssl from the configuration.
> at
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
> at
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
> at
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
> at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
> at
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
> at
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does
> resolve the issue, as expected, but this does seem like a regression, hence
> the Jira issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16093) Cassandra website is building/including the wrong versioned nodetool docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16093: --- Test and Documentation Plan: CI and cassandra.staged.a.o Status: Patch Available (was: In Progress) > Cassandra website is building/including the wrong versioned nodetool docs > - > > Key: CASSANDRA-16093 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16093 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > For example > https://cassandra.apache.org/doc/3.11/tools/nodetool/enablefullquerylog.html > shouldn't be under the 3.11 documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16093) Cassandra website is building/including the wrong versioned nodetool docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189142#comment-17189142 ] Michael Semb Wever commented on CASSANDRA-16093: Fix in https://github.com/apache/cassandra-website/pull/17 specifically the fix is the first commit, while the second commit regenerates the in-tree docs correctly. > Cassandra website is building/including the wrong versioned nodetool docs > - > > Key: CASSANDRA-16093 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16093 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > For example > https://cassandra.apache.org/doc/3.11/tools/nodetool/enablefullquerylog.html > shouldn't be under the 3.11 documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16091) rpc server gets wrongly initialized with rpc_enabled:false
[
https://issues.apache.org/jira/browse/CASSANDRA-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189132#comment-17189132
]
Tibor Repasi edited comment on CASSANDRA-16091 at 9/2/20, 10:28 AM:
We also have a similar, strange behaviour, however without exceptions, after
upgrading to 3.11.8, with enabled thrift while having start_rpc disabled in
config:
{code:java}
INFO [main] 2020-09-02 11:59:17,892 YamlConfigurationLoader.java:89 -
Configuration location: file:/etc/cassandra/cassandra.yaml
INFO [main] 2020-09-02 11:59:18,182 Config.java:536 - Node configuration:[...
rpc_address=0.0.0.0; rpc_interface=null; rpc_interface_prefer_ipv6=false;
rpc_keepalive=true; rpc_listen_backlog=50; rpc_max_threads=2147483647;
rpc_min_threads=16; rpc_port=9160; rpc_recv_buff_size_in_bytes=null;
rpc_send_buff_size_in_bytes=null; rpc_server_type=sync;
start_native_transport=true; start_rpc=false; ...
thrift_framed_transport_size_in_mb=15; thrift_max_message_length_in_mb=16;
thrift_prepared_statements_cache_size_mb=null; ...]
...
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:663 - Cassandra
version: 3.11.8
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:664 - Thrift API
version: 20.1.0
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:665 - CQL supported
versions: 3.4.4 (default: 3.4.4)
...
INFO [main] 2020-09-02 11:59:33,491 Server.java:159 - Starting listening for
CQL clients on /0.0.0.0:9042 (unencrypted)...
INFO [main] 2020-09-02 11:59:33,543 ThriftServer.java:116 - Binding thrift
service to /0.0.0.0:9160
INFO [Thread-8] 2020-09-02 11:59:33,549 ThriftServer.java:133 - Listening for
thrift clients...
INFO [main] 2020-09-02 11:59:33,553 CassandraDaemon.java:548 - Not starting
RPC server as requested. Use JMX (StorageService->startRPCServer()) or nodetool
(enablethrift) to start it
{code}
{code:java}
$ nodetool info
ID : 232f4fe3-051a-4488-97c1-062b733b63e4
Gossip active : true
Thrift active : true
Native Transport active: true
...
{code}
Especially, the last two log entries seem inconsistent.
was (Author: rtib):
We also have a similar, strange behaviour after upgrading to 3.11.8, with
enabled thrift while having start_rpc disabled in config:
{code}
INFO [main] 2020-09-02 11:59:17,892 YamlConfigurationLoader.java:89 -
Configuration location: file:/etc/cassandra/cassandra.yaml
INFO [main] 2020-09-02 11:59:18,182 Config.java:536 - Node configuration:[...
rpc_address=0.0.0.0; rpc_interface=null; rpc_interface_prefer_ipv6=false;
rpc_keepalive=true; rpc_listen_backlog=50; rpc_max_threads=2147483647;
rpc_min_threads=16; rpc_port=9160; rpc_recv_buff_size_in_bytes=null;
rpc_send_buff_size_in_bytes=null; rpc_server_type=sync;
start_native_transport=true; start_rpc=false; ...
thrift_framed_transport_size_in_mb=15; thrift_max_message_length_in_mb=16;
thrift_prepared_statements_cache_size_mb=null; ...]
...
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:663 - Cassandra
version: 3.11.8
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:664 - Thrift API
version: 20.1.0
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:665 - CQL supported
versions: 3.4.4 (default: 3.4.4)
...
INFO [main] 2020-09-02 11:59:33,491 Server.java:159 - Starting listening for
CQL clients on /0.0.0.0:9042 (unencrypted)...
INFO [main] 2020-09-02 11:59:33,543 ThriftServer.java:116 - Binding thrift
service to /0.0.0.0:9160
INFO [Thread-8] 2020-09-02 11:59:33,549 ThriftServer.java:133 - Listening for
thrift clients...
INFO [main] 2020-09-02 11:59:33,553 CassandraDaemon.java:548 - Not starting
RPC server as requested. Use JMX (StorageService->startRPCServer()) or nodetool
(enablethrift) to start it
{code}
{code}
$ nodetool info
ID : 232f4fe3-051a-4488-97c1-062b733b63e4
Gossip active : true
Thrift active : true
Native Transport active: true
...
{code}
Especially, the last two log entries seem inconsistent.
> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tom van der Woerdt
>Priority: Normal
> Fix For: 3.11.9
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception
> is thrown:
> {code:java}
> java.lang.RuntimeException: Client SSL is not supported for non-blocking
> sockets (hsha). Please remove client ssl from the configuration.
> at
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
> at
>
[jira] [Commented] (CASSANDRA-16091) rpc server gets wrongly initialized with rpc_enabled:false
[
https://issues.apache.org/jira/browse/CASSANDRA-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189132#comment-17189132
]
Tibor Repasi commented on CASSANDRA-16091:
--
We also have a similar, strange behaviour after upgrading to 3.11.8, with
enabled thrift while having start_rpc disabled in config:
{code}
INFO [main] 2020-09-02 11:59:17,892 YamlConfigurationLoader.java:89 -
Configuration location: file:/etc/cassandra/cassandra.yaml
INFO [main] 2020-09-02 11:59:18,182 Config.java:536 - Node configuration:[...
rpc_address=0.0.0.0; rpc_interface=null; rpc_interface_prefer_ipv6=false;
rpc_keepalive=true; rpc_listen_backlog=50; rpc_max_threads=2147483647;
rpc_min_threads=16; rpc_port=9160; rpc_recv_buff_size_in_bytes=null;
rpc_send_buff_size_in_bytes=null; rpc_server_type=sync;
start_native_transport=true; start_rpc=false; ...
thrift_framed_transport_size_in_mb=15; thrift_max_message_length_in_mb=16;
thrift_prepared_statements_cache_size_mb=null; ...]
...
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:663 - Cassandra
version: 3.11.8
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:664 - Thrift API
version: 20.1.0
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:665 - CQL supported
versions: 3.4.4 (default: 3.4.4)
...
INFO [main] 2020-09-02 11:59:33,491 Server.java:159 - Starting listening for
CQL clients on /0.0.0.0:9042 (unencrypted)...
INFO [main] 2020-09-02 11:59:33,543 ThriftServer.java:116 - Binding thrift
service to /0.0.0.0:9160
INFO [Thread-8] 2020-09-02 11:59:33,549 ThriftServer.java:133 - Listening for
thrift clients...
INFO [main] 2020-09-02 11:59:33,553 CassandraDaemon.java:548 - Not starting
RPC server as requested. Use JMX (StorageService->startRPCServer()) or nodetool
(enablethrift) to start it
{code}
{code}
$ nodetool info
ID : 232f4fe3-051a-4488-97c1-062b733b63e4
Gossip active : true
Thrift active : true
Native Transport active: true
...
{code}
Especially, the last two log entries seem inconsistent.
> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tom van der Woerdt
>Priority: Normal
> Fix For: 3.11.9
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception
> is thrown:
> {code:java}
> java.lang.RuntimeException: Client SSL is not supported for non-blocking
> sockets (hsha). Please remove client ssl from the configuration.
> at
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
> at
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
> at
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
> at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
> at
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
> at
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does
> resolve the issue, as expected, but this does seem like a regression, hence
> the Jira issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16093) Cassandra website is building/including the wrong versioned nodetool docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189109#comment-17189109 ] Michael Semb Wever commented on CASSANDRA-16093: CASSANDRA-14955 is also missing from the cassandra-3.11 branch and tags. > Cassandra website is building/including the wrong versioned nodetool docs > - > > Key: CASSANDRA-16093 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16093 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > For example > https://cassandra.apache.org/doc/3.11/tools/nodetool/enablefullquerylog.html > shouldn't be under the 3.11 documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15988) Add nodetool getfullquerylog
[ https://issues.apache.org/jira/browse/CASSANDRA-15988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189100#comment-17189100 ] Stefan Miklosovic commented on CASSANDRA-15988: --- [~dcapwell] I ve got 2 +1's, I guess we are ready to ship it. https://github.com/apache/cassandra/pull/721#issuecomment-685473360 > Add nodetool getfullquerylog > - > > Key: CASSANDRA-15988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15988 > Project: Cassandra > Issue Type: Improvement > Components: Tool/fql >Reporter: Ekaterina Dimitrova >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 1h 20m > Remaining Estimate: 0h > > This ticket is raised based on CASSANDRA-15791 and valuable feedback provided > by [~jshook]. > There are two outstanding questions: > * forming the exact shape of such a command and how it can benefit the > users; to be discussed in detail in this ticket > * Is this a thing we as a project can add to 4.0 beta or it should be > considered in 4.1 for example > PR: https://github.com/apache/cassandra/pull/721 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15988) Add nodetool getfullquerylog
[ https://issues.apache.org/jira/browse/CASSANDRA-15988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15988: Reviewers: Berenguer Blasi, David Capwell (was: David Capwell) > Add nodetool getfullquerylog > - > > Key: CASSANDRA-15988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15988 > Project: Cassandra > Issue Type: Improvement > Components: Tool/fql >Reporter: Ekaterina Dimitrova >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 1h 10m > Remaining Estimate: 0h > > This ticket is raised based on CASSANDRA-15791 and valuable feedback provided > by [~jshook]. > There are two outstanding questions: > * forming the exact shape of such a command and how it can benefit the > users; to be discussed in detail in this ticket > * Is this a thing we as a project can add to 4.0 beta or it should be > considered in 4.1 for example > PR: https://github.com/apache/cassandra/pull/721 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16061) transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189074#comment-17189074
]
Berenguer Blasi commented on CASSANDRA-16061:
-
This is the failure for reference as ci-cass logs are gone now:
{noformat}
===Flaky Test Report===
test_move_forwards_and_cleanup failed; it passed 0 out of the required 1 times.
02 Sep 2020 07:18:39 [node4] Missing: ['Starting listening for CQL
clients']:
INFO [main] 2020-09-02 09:17:30,390 YamlConfigura.
See system.log for remainder
[,
,
,
,
,
]
===End Flaky Test Report===
{noformat}
It's hard to repro. There is some exotic race where
[boostrap.get()|https://github.com/apache/cassandra/blob/23ba48aa935d3f81e66b65285fa8e7972f94dcfe/src/java/org/apache/cassandra/service/StorageService.java#L1584]
will block as a default connection never completes blocking
[here|https://github.com/apache/cassandra/blob/23ba48aa935d3f81e66b65285fa8e7972f94dcfe/src/java/org/apache/cassandra/streaming/DefaultConnectionFactory.java#L50].
That just times out the test.
That shouldn't be as the default connection has a built in timeout. Even
forcing a timeout myself when waiting on it won't do the trick. Somehow
connecting to node1 is not possible.
I have been debugging this as much as I can. The netty code needs some time to
penetrate and I don't have a full grasp of it despite what I saw made sense.
{{bootstrap.get()}} blocks on AbstractFuture
[parking|https://github.com/google/guava/blob/v27.0/guava/src/com/google/common/util/concurrent/AbstractFuture.java#L523]
the thread. If you google a bit you'll find many people getting blocked
threads around this area given guava makes some assumptions apparently.
I am taking a break here as I am not progressing so I need to go back to the
drawing board on how to approach this. If sbdy wants to try the challenge feel
free to assign it.
> transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup
>
>
> Key: CASSANDRA-16061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16061
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Failing here, also locally:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/312/workflows/da4ce69c-e778-467e-b9f3-27ab166a8321/jobs/1945]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16061) transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-16061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi reassigned CASSANDRA-16061: --- Assignee: (was: Berenguer Blasi) > transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup > > > Key: CASSANDRA-16061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16061 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-beta > > > Failing here, also locally: > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/312/workflows/da4ce69c-e778-467e-b9f3-27ab166a8321/jobs/1945] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16092) Add Index Group Interface for Storage Attached Index
[ https://issues.apache.org/jira/browse/CASSANDRA-16092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhaoYang reassigned CASSANDRA-16092: Assignee: ZhaoYang > Add Index Group Interface for Storage Attached Index > > > Key: CASSANDRA-16092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16092 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SASI >Reporter: ZhaoYang >Assignee: ZhaoYang >Priority: Normal > > [Index > group|https://github.com/datastax/cassandra/blob/storage_attached_index/src/java/org/apache/cassandra/index/Index.java#L634] > interface allows: > * indexes on the same table to receive centralized lifecycle events called > secondary index groups. Sharing of data between multiple column indexes on > the same table allows SAI disk usage to realise significant space savings > over other index implementations. > * index-group to analyze user query and provide a query plan that leverages > all available indexes within the group. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15861) Mutating sstable component may race with entire-sstable-streaming(ZCS) causing checksum validation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-15861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-15861:
-
Test and Documentation Plan:
[https://app.circleci.com/pipelines/github/jasonstack/cassandra/301/workflows/4daf1646-77d4-4b83-8df6-5caeb73f2fe8]
(was:
[https://app.circleci.com/pipelines/github/jasonstack/cassandra/300/workflows/f41f6585-cd97-4791-abdc-a2935694948e])
> Mutating sstable component may race with entire-sstable-streaming(ZCS)
> causing checksum validation failure
> --
>
> Key: CASSANDRA-15861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15861
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming,
> Local/Compaction
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Flaky dtest: [test_dead_sync_initiator -
> repair_tests.repair_test.TestRepair|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-dtest/143/testReport/junit/dtest.repair_tests.repair_test/TestRepair/test_dead_sync_initiator/]
> {code:java|title=stacktrace}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [Stream-Deserializer-127.0.0.1:7000-570871f3] 2020-06-03 04:05:19,081
> CassandraEntireSSTableStreamReader.java:145 - [Stream
> 6f1c3360-a54f-11ea-a808-2f23710fdc90] Error while reading sstable from stream
> for table = keyspace1.standard1
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.maybeValidateChecksum(MetadataSerializer.java:219)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:198)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:129)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.mutate(MetadataSerializer.java:226)
> at
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:140)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:78)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:49)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:181)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: Checksums do not match for
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> {code}
>
> In the above test, it executes "nodetool repair" on node1 and kills node2
> during repair. At the end, node3 reports checksum validation failure on
> sstable transferred from node1.
> {code:java|title=what happened}
> 1. When repair started on node1, it performs anti-compaction which modifies
> sstable's repairAt to 0 and pending repair id to session-id.
> 2. Then node1 creates {{ComponentManifest}} which contains file lengths to be
> transferred to node3.
> 3. Before node1 actually sends the files to node3, node2 is killed and node1
> starts to broadcast repair-failure-message to all participants in
> {{CoordinatorSession#fail}}
> 4. Node1 receives its own repair-failure-message and fails its local repair
> sessions at {{LocalSessions#failSession}} which triggers async background
> compaction.
> 5. Node1's background compaction will mutate sstable's repairAt to 0 and
> pending repair id to null via
> {{PendingRepairManager#getNextRepairFinishedTask}}, as there is no more
> in-progress repair.
> 6. Node1 actually sends the sstable to node3 where the sstable's STATS
> component size is different from the original size recorded in the manifest.
> 7. At the end, node3 reports checksum validation failure when it tries to
> mutate sstable level and "isTransient" attribute in
> {{CassandraEntireSSTableStreamReader#read}}.
> {code}
> Currently, entire-sstable-streaming requires sstable components to be
> immutable, because \{{ComponentManifest}}
> with component sizes are
[jira] [Commented] (CASSANDRA-12372) Remove deprecated memtable_cleanup_threshold for 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-12372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189038#comment-17189038
]
Robert Stupp commented on CASSANDRA-12372:
--
Recently came across situations where it's counter-productive to force the
default of {{mct = (1 + (1 / flush_writers))}}. Therefore I'm also against
removing {{memtable_clearnup_threshold}} and remove the deprecation warning.
> Remove deprecated memtable_cleanup_threshold for 4.0
>
>
> Key: CASSANDRA-12372
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12372
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 4.x
>
>
> This is going to be deprecated in 3.10 since it doesn't make sense to specify
> a value. It only makes sense to calculate it based on memtable_flush_writers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15988) Add nodetool getfullquerylog
[ https://issues.apache.org/jira/browse/CASSANDRA-15988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-15988: -- Description: This ticket is raised based on CASSANDRA-15791 and valuable feedback provided by [~jshook]. There are two outstanding questions: * forming the exact shape of such a command and how it can benefit the users; to be discussed in detail in this ticket * Is this a thing we as a project can add to 4.0 beta or it should be considered in 4.1 for example PR: https://github.com/apache/cassandra/pull/721 was: This ticket is raised based on CASSANDRA-15791 and valuable feedback provided by [~jshook]. There are two outstanding questions: * forming the exact shape of such a command and how it can benefit the users; to be discussed in detail in this ticket * Is this a thing we as a project can add to 4.0 beta or it should be considered in 4.1 for example > Add nodetool getfullquerylog > - > > Key: CASSANDRA-15988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15988 > Project: Cassandra > Issue Type: Improvement > Components: Tool/fql >Reporter: Ekaterina Dimitrova >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 40m > Remaining Estimate: 0h > > This ticket is raised based on CASSANDRA-15791 and valuable feedback provided > by [~jshook]. > There are two outstanding questions: > * forming the exact shape of such a command and how it can benefit the > users; to be discussed in detail in this ticket > * Is this a thing we as a project can add to 4.0 beta or it should be > considered in 4.1 for example > PR: https://github.com/apache/cassandra/pull/721 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15988) Add nodetool getfullquerylog
[ https://issues.apache.org/jira/browse/CASSANDRA-15988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189017#comment-17189017 ] Stefan Miklosovic commented on CASSANDRA-15988: --- [~brandon.williams] [~Bereng] would you mind to review please? Very easy to follow and review, matter of minutes. > Add nodetool getfullquerylog > - > > Key: CASSANDRA-15988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15988 > Project: Cassandra > Issue Type: Improvement > Components: Tool/fql >Reporter: Ekaterina Dimitrova >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 40m > Remaining Estimate: 0h > > This ticket is raised based on CASSANDRA-15791 and valuable feedback provided > by [~jshook]. > There are two outstanding questions: > * forming the exact shape of such a command and how it can benefit the > users; to be discussed in detail in this ticket > * Is this a thing we as a project can add to 4.0 beta or it should be > considered in 4.1 for example > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
