[jira] [Comment Edited] (CASSANDRA-15986) Repair tests flakiness
[ https://issues.apache.org/jira/browse/CASSANDRA-15986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197372#comment-17197372 ] Berenguer Blasi edited comment on CASSANDRA-15986 at 9/17/20, 4:42 AM: --- That's bc we lost history. I remember we had some Repair failure. I want to keep an eye longer I am not comfortable with this yet. Happy to take it back off your plate. was (Author: bereng): That's bc we lost history. I remember we had some Repair failure. I want to keep an eye longer. > Repair tests flakiness > -- > > Key: CASSANDRA-15986 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15986 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Berenguer Blasi >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-beta > > > Repair tests come up in test failure reports every now and then. I have tried > to repro the > [latest|https://ci-cassandra.apache.org/job/Cassandra-trunk/241/testReport/junit/dtest-novnode.repair_tests.repair_test/TestRepair/test_simple_sequential_repair/] > locally 100 times with no luck. > _dtest-novnode.repair_tests.repair_test/TestRepair/test_simple_sequential_repair_ > Still from experience from fixing other flaky tests I have some intuition > where the problems may lie. The proposed fix should add no harm if merged. We > can reopen the ticket if repair tests keep failing. -- 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-15986) Repair tests flakiness
[ https://issues.apache.org/jira/browse/CASSANDRA-15986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi reassigned CASSANDRA-15986: --- Assignee: Berenguer Blasi (was: Ekaterina Dimitrova) > Repair tests flakiness > -- > > Key: CASSANDRA-15986 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15986 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Repair tests come up in test failure reports every now and then. I have tried > to repro the > [latest|https://ci-cassandra.apache.org/job/Cassandra-trunk/241/testReport/junit/dtest-novnode.repair_tests.repair_test/TestRepair/test_simple_sequential_repair/] > locally 100 times with no luck. > _dtest-novnode.repair_tests.repair_test/TestRepair/test_simple_sequential_repair_ > Still from experience from fixing other flaky tests I have some intuition > where the problems may lie. The proposed fix should add no harm if merged. We > can reopen the ticket if repair tests keep failing. -- 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-15986) Repair tests flakiness
[ https://issues.apache.org/jira/browse/CASSANDRA-15986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197372#comment-17197372 ] Berenguer Blasi commented on CASSANDRA-15986: - That's bc we lost history. I remember we had some Repair failure. I want to keep an eye longer. > Repair tests flakiness > -- > > Key: CASSANDRA-15986 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15986 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Berenguer Blasi >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-beta > > > Repair tests come up in test failure reports every now and then. I have tried > to repro the > [latest|https://ci-cassandra.apache.org/job/Cassandra-trunk/241/testReport/junit/dtest-novnode.repair_tests.repair_test/TestRepair/test_simple_sequential_repair/] > locally 100 times with no luck. > _dtest-novnode.repair_tests.repair_test/TestRepair/test_simple_sequential_repair_ > Still from experience from fixing other flaky tests I have some intuition > where the problems may lie. The proposed fix should add no harm if merged. We > can reopen the ticket if repair tests keep failing. -- 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-16049) org.apache.cassandra.distributed.test.ReadRepairTest#movingTokenReadRepairTest passes because the message drop filters are not dropping the messages
[
https://issues.apache.org/jira/browse/CASSANDRA-16049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197356#comment-17197356
]
Ekaterina Dimitrova commented on CASSANDRA-16049:
-
+1 from me. Thank you both [~dcapwell] and [~samt]
> org.apache.cassandra.distributed.test.ReadRepairTest#movingTokenReadRepairTest
> passes because the message drop filters are not dropping the messages
>
>
> Key: CASSANDRA-16049
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16049
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Test/dtest/java
>Reporter: David Capwell
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The test tries to block messages from node 4 to 3 but used verb ordinal
> rather than id; this causes the verbs to sent to node 3 and allow all replies
> to happen.
> If you fix the test to use id (and actually filter), then the test fails
> Patch to show the issue
> {code}
> diff --git
> a/test/distributed/org/apache/cassandra/distributed/test/ReadRepairTest.java
> b/test/distributed/org/apache/cassandra/distributed/test/ReadRepairTest.java
> index f0c82b85e1..55d2e8f303 100644
> ---
> a/test/distributed/org/apache/cassandra/distributed/test/ReadRepairTest.java
> +++
> b/test/distributed/org/apache/cassandra/distributed/test/ReadRepairTest.java
> @@ -30,14 +30,14 @@ import org.apache.cassandra.dht.Token;
> import org.apache.cassandra.distributed.Cluster;
> import org.apache.cassandra.distributed.api.ConsistencyLevel;
> import org.apache.cassandra.distributed.api.ICluster;
> -import org.apache.cassandra.distributed.shared.NetworkTopology;
> import org.apache.cassandra.locator.InetAddressAndPort;
> import org.apache.cassandra.service.PendingRangeCalculatorService;
> import org.apache.cassandra.service.StorageService;
> +import static org.apache.cassandra.distributed.shared.AssertUtils.assertRows;
> +import static org.apache.cassandra.distributed.shared.AssertUtils.row;
> import static org.apache.cassandra.net.Verb.READ_REPAIR_REQ;
> import static org.apache.cassandra.net.Verb.READ_REQ;
> -import static org.apache.cassandra.distributed.shared.AssertUtils.*;
> public class ReadRepairTest extends TestBaseImpl
> {
> @@ -115,8 +115,8 @@ public class ReadRepairTest extends TestBaseImpl
> // prevent #4 from reading or writing to #3, so our QUORUM must
> contain #2 and #4
> // since #1 is taking over the range, this means any read-repair
> must make it to #1 as well
> -cluster.filters().verbs(READ_REQ.ordinal()).from(4).to(3).drop();
> -
> cluster.filters().verbs(READ_REPAIR_REQ.ordinal()).from(4).to(3).drop();
> +cluster.filters().verbs(READ_REQ.id).from(4).to(3).drop();
> +cluster.filters().verbs(READ_REPAIR_REQ.id).from(4).to(3).drop();
> assertRows(cluster.coordinator(4).execute("SELECT * FROM " +
> KEYSPACE + ".tbl WHERE pk = ?",
> ConsistencyLevel.ALL,
> i),
>row(i, 1, 1));
> {code}
> Exception
> {code}
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 2 responses.
> at
> org.apache.cassandra.service.reads.ReadCallback.awaitResults(ReadCallback.java:120)
> at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:373)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1823)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1713)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1630)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1123)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:294)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:246)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeInternal(Coordinator.java:100)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:62)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>
[jira] [Commented] (CASSANDRA-16127) NullPointerException when calling nodetool enablethrift
[
https://issues.apache.org/jira/browse/CASSANDRA-16127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197339#comment-17197339
]
David Capwell commented on CASSANDRA-16127:
---
added python dtest which catches the other reported issues that I couldn't test
in jvm-dtest. I need to still test this against 2.2 and trunk, but with a
version before the issue it passes, with the issue it fails.
> NullPointerException when calling nodetool enablethrift
> ---
>
> Key: CASSANDRA-16127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16127
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Thrift
>Reporter: Tibor Repasi
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> Having thrift disabled, it's impossible to enable it again without restarting
> the node:
> {code}
> $ nodetool statusthrift
> not running
> $ nodetool enablethrift
> error: null
> -- StackTrace --
> java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageService.startRPCServer(StorageService.java:392)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {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-16079) Improve dtest runtime
[ https://issues.apache.org/jira/browse/CASSANDRA-16079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197300#comment-17197300 ] Jeremy Hanna edited comment on CASSANDRA-16079 at 9/17/20, 12:22 AM: - Is it possible to implement some sort of "reset" operation in CCM so that it drops all non-system keyspaces so that the clusters that don't explicitly test cluster membership operations can just be reused as has been said? We could disable snapshotting on them as well so they wouldn't build up state over time too. In other words, it sounds like if we made the time for starting single node clusters essentially instant, that's 171 * single node startup time that we've reduced for the overall dtests. was (Author: jeromatron): Is it possible to implement some sort of "reset" operation in CCM so that it drops all non-system keyspaces so that the clusters that don't explicitly test cluster membership operations can just be reused as has been said? We could disable snapshotting on them as well so they wouldn't build up state over time too. > Improve dtest runtime > - > > Key: CASSANDRA-16079 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16079 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Adam Holmberg >Priority: Normal > Fix For: 4.0-beta > > > A recent ticket, CASSANDRA-13701, changed the way dtests run, resulting in a > [30% increase in run > time|https://www.mail-archive.com/dev@cassandra.apache.org/msg15606.html]. > While that change was accepted, we wanted to spin out a ticket to optimize > dtests in an attempt to gain back some of that runtime. > At this time we don't have concrete improvements in mind, so the first order > of this ticket will be to analyze the state of things currently, and try to > ascertain some valuable optimizations. Once the problems are understood, we > will break down subtasks to divide the work. > Some areas to consider: > * cluster reuse > * C* startup optimizations > * Tests that should be ported to in-JVM dtest or even unit tests -- 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-16079) Improve dtest runtime
[ https://issues.apache.org/jira/browse/CASSANDRA-16079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197300#comment-17197300 ] Jeremy Hanna commented on CASSANDRA-16079: -- Is it possible to implement some sort of "reset" operation in CCM so that it drops all non-system keyspaces so that the clusters that don't explicitly test cluster membership operations can just be reused as has been said? We could disable snapshotting on them as well so they wouldn't build up state over time too. > Improve dtest runtime > - > > Key: CASSANDRA-16079 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16079 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Adam Holmberg >Priority: Normal > Fix For: 4.0-beta > > > A recent ticket, CASSANDRA-13701, changed the way dtests run, resulting in a > [30% increase in run > time|https://www.mail-archive.com/dev@cassandra.apache.org/msg15606.html]. > While that change was accepted, we wanted to spin out a ticket to optimize > dtests in an attempt to gain back some of that runtime. > At this time we don't have concrete improvements in mind, so the first order > of this ticket will be to analyze the state of things currently, and try to > ascertain some valuable optimizations. Once the problems are understood, we > will break down subtasks to divide the work. > Some areas to consider: > * cluster reuse > * C* startup optimizations > * Tests that should be ported to in-JVM dtest or even unit tests -- 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=17197284#comment-17197284
]
David Capwell commented on CASSANDRA-16091:
---
should have tests ready by EOD. I also noticed that info fails in 3.11.7 in
the tests, so might have to increase the scope to get the tests passing.
> 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: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> 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-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
]
David Capwell updated CASSANDRA-16091:
--
Fix Version/s: (was: 3.11.9)
3.11.x
3.0.x
2.2.x
> 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: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> 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-16130) Nodetool support show the progress rate of index rebuild
[ https://issues.apache.org/jira/browse/CASSANDRA-16130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16130: -- Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Nodetool support show the progress rate of index rebuild > > > Key: CASSANDRA-16130 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16130 > Project: Cassandra > Issue Type: New Feature > Components: Feature/2i Index, Tool/nodetool >Reporter: maxwellguo >Priority: Normal > > After Doing 2i index rebuild we may want to seed the progress of the task , > so Adding a nodetool feature to show the progress may be usefull -- 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-16132) Additional information to be added to the Contributing to Cassandra section on Cassandra web site
[ https://issues.apache.org/jira/browse/CASSANDRA-16132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16132: Description: It would be nice to inform people about the CLA (some contributors never contributed to OSS before). Also there is no mention about the CEPs. I think it would be good to add a link to the wiki. /CC [~lor...@datastax.com] was: It would be nice to inform people about the CLA (some contributors never contributed to OSS before). Also there is no mention about the CEPs. I think it would be good to add a link to the wiki. > Additional information to be added to the Contributing to Cassandra section > on Cassandra web site > - > > Key: CASSANDRA-16132 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16132 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0-beta > > > It would be nice to inform people about the CLA (some contributors never > contributed to OSS before). > Also there is no mention about the CEPs. I think it would be good to add a > link to the wiki. > /CC [~lor...@datastax.com] -- 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-16126) Blog post on Cassandra Usage Report 2020
[
https://issues.apache.org/jira/browse/CASSANDRA-16126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197263#comment-17197263
]
Vinay Chella commented on CASSANDRA-16126:
--
I left a few comments on PR to improve the readability of it and also a few
observations in the usage of the term {{Cassandra}} and {{Apache Cassandra}}.
> Blog post on Cassandra Usage Report 2020
>
>
> Key: CASSANDRA-16126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16126
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Melissa Logan
>Assignee: Melissa Logan
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Blog post on the 2020 Cassandra Usage Report.
> ML:
> [https://lists.apache.org/thread.html/r8a91b1d63079739c8dfbdab1833c66d58326de91a659afa3fb2a41a7%40%3Cdev.cassandra.apache.org%3E]
>
> PR: [https://github.com/apache/cassandra-website/pull/21]
--
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-16132) Additional information to be added to the Contributing to Cassandra section on Cassandra web site
Ekaterina Dimitrova created CASSANDRA-16132: --- Summary: Additional information to be added to the Contributing to Cassandra section on Cassandra web site Key: CASSANDRA-16132 URL: https://issues.apache.org/jira/browse/CASSANDRA-16132 Project: Cassandra Issue Type: Improvement Components: Documentation/Website Reporter: Ekaterina Dimitrova It would be nice to inform people about the CLA (some contributors never contributed to OSS before). Also there is no mention about the CEPs. I think it would be good to add a link to the wiki. -- 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-16132) Additional information to be added to the Contributing to Cassandra section on Cassandra web site
[ https://issues.apache.org/jira/browse/CASSANDRA-16132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16132: Change Category: Semantic Complexity: Low Hanging Fruit Fix Version/s: 4.0-beta Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Additional information to be added to the Contributing to Cassandra section > on Cassandra web site > - > > Key: CASSANDRA-16132 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16132 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0-beta > > > It would be nice to inform people about the CLA (some contributors never > contributed to OSS before). > Also there is no mention about the CEPs. I think it would be good to add a > link to the wiki. -- 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-16127) NullPointerException when calling nodetool enablethrift
[
https://issues.apache.org/jira/browse/CASSANDRA-16127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197252#comment-17197252
]
Yifan Cai commented on CASSANDRA-16127:
---
Left some comments inline on GH.
> NullPointerException when calling nodetool enablethrift
> ---
>
> Key: CASSANDRA-16127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16127
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Thrift
>Reporter: Tibor Repasi
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> Having thrift disabled, it's impossible to enable it again without restarting
> the node:
> {code}
> $ nodetool statusthrift
> not running
> $ nodetool enablethrift
> error: null
> -- StackTrace --
> java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageService.startRPCServer(StorageService.java:392)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {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-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15965:
-
Fix Version/s: (was: 4.0-beta)
4.0-beta3
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15965:
-
Since Version: 3.0.0
Source Control Link:
https://github.com/apache/cassandra/commit/68aca1064be12697e5ff7f56b50e6808f5d5d020
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed the test removal.
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15965:
-
Status: Ready to Commit (was: Review In Progress)
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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-16131) NPE in StreamingMessage type lookup
[
https://issues.apache.org/jira/browse/CASSANDRA-16131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16131:
-
Since Version: 4.0-alpha1
Source Control Link:
https://github.com/apache/cassandra/commit/2958c558707e3e2252bdd38d61981ce7eb138717
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed.
> NPE in StreamingMessage type lookup
> ---
>
> Key: CASSANDRA-16131
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16131
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> Found while investigating
> https://issues.apache.org/jira/browse/CASSANDRA-15965
> {noformat}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:51)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:172)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is a null in the zero.index of the type map. We can clean this up,
> handle invalid ids in a uniform manner, and add a test.
--
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-16131) NPE in StreamingMessage type lookup
[
https://issues.apache.org/jira/browse/CASSANDRA-16131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16131:
-
Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams)
Brandon Williams, Brandon Williams (was: Brandon Williams)
Status: Review In Progress (was: Patch Available)
> NPE in StreamingMessage type lookup
> ---
>
> Key: CASSANDRA-16131
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16131
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> Found while investigating
> https://issues.apache.org/jira/browse/CASSANDRA-15965
> {noformat}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:51)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:172)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is a null in the zero.index of the type map. We can clean this up,
> handle invalid ids in a uniform manner, and add a test.
--
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-16131) NPE in StreamingMessage type lookup
[
https://issues.apache.org/jira/browse/CASSANDRA-16131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16131:
-
Status: Ready to Commit (was: Review In Progress)
> NPE in StreamingMessage type lookup
> ---
>
> Key: CASSANDRA-16131
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16131
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> Found while investigating
> https://issues.apache.org/jira/browse/CASSANDRA-15965
> {noformat}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:51)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:172)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is a null in the zero.index of the type map. We can clean this up,
> handle invalid ids in a uniform manner, and add a test.
--
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-16131) NPE in StreamingMessage type lookup
[
https://issues.apache.org/jira/browse/CASSANDRA-16131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197244#comment-17197244
]
Adam Holmberg commented on CASSANDRA-16131:
---
[patched|https://github.com/apache/cassandra/compare/trunk...aholmberg:CASSANDRA-15965]
as part of CASSANDRA-15965.
> NPE in StreamingMessage type lookup
> ---
>
> Key: CASSANDRA-16131
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16131
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> Found while investigating
> https://issues.apache.org/jira/browse/CASSANDRA-15965
> {noformat}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:51)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:172)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is a null in the zero.index of the type map. We can clean this up,
> handle invalid ids in a uniform manner, and add a test.
--
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] 02/02: Remove flaky channelRead_Normal test that wasn't doing much
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
commit 68aca1064be12697e5ff7f56b50e6808f5d5d020
Author: Adam Holmberg
AuthorDate: Tue Sep 15 15:56:39 2020 -0500
Remove flaky channelRead_Normal test that wasn't doing much
Patch by Adam Holmberg, reviewed by brandonwilliams for CASSANDRA-15965
---
.../streaming/async/StreamingInboundHandlerTest.java | 12
1 file changed, 12 deletions(-)
diff --git
a/test/unit/org/apache/cassandra/streaming/async/StreamingInboundHandlerTest.java
b/test/unit/org/apache/cassandra/streaming/async/StreamingInboundHandlerTest.java
index d573a15..a43b116 100644
---
a/test/unit/org/apache/cassandra/streaming/async/StreamingInboundHandlerTest.java
+++
b/test/unit/org/apache/cassandra/streaming/async/StreamingInboundHandlerTest.java
@@ -88,18 +88,6 @@ public class StreamingInboundHandlerTest
}
@Test
-public void channelRead_Normal()
-{
-Assert.assertEquals(0, buffers.unsafeAvailable());
-int size = 8;
-buf = channel.alloc().buffer(size);
-buf.writerIndex(size);
-channel.writeInbound(buf);
-Assert.assertEquals(size, buffers.unsafeAvailable());
-Assert.assertFalse(channel.releaseInbound());
-}
-
-@Test
public void channelRead_Closed()
{
int size = 8;
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16131) NPE in StreamingMessage type lookup
[
https://issues.apache.org/jira/browse/CASSANDRA-16131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16131:
--
Test and Documentation Plan: Unit test added.
Status: Patch Available (was: Open)
> NPE in StreamingMessage type lookup
> ---
>
> Key: CASSANDRA-16131
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16131
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> Found while investigating
> https://issues.apache.org/jira/browse/CASSANDRA-15965
> {noformat}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:51)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:172)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is a null in the zero.index of the type map. We can clean this up,
> handle invalid ids in a uniform manner, and add a test.
--
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] 01/02: Fix null type returned in StreamMessage lookup
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
commit 2958c558707e3e2252bdd38d61981ce7eb138717
Author: Adam Holmberg
AuthorDate: Tue Sep 15 15:55:01 2020 -0500
Fix null type returned in StreamMessage lookup
Patch by Adam Holmberg, reviewed by brandonwilliams for CASSANDRA-16131
---
CHANGES.txt| 1 +
.../streaming/messages/StreamMessage.java | 24 +++-
.../streaming/messages/StreamMessageTest.java | 69 ++
3 files changed, 79 insertions(+), 15 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 90f5995..4916faa 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-beta3
+ * Prevent NPE in StreamMessage in type lookup (CASSANDRA-16131)
* Avoid invalid state transition exception during incremental repair
(CASSANDRA-16067)
* Allow zero padding in timestamp serialization (CASSANDRA-16105)
* Add byte array backed cells (CASSANDRA-15393)
diff --git
a/src/java/org/apache/cassandra/streaming/messages/StreamMessage.java
b/src/java/org/apache/cassandra/streaming/messages/StreamMessage.java
index e2f08fd..e3f805e 100644
--- a/src/java/org/apache/cassandra/streaming/messages/StreamMessage.java
+++ b/src/java/org/apache/cassandra/streaming/messages/StreamMessage.java
@@ -18,6 +18,8 @@
package org.apache.cassandra.streaming.messages;
import java.io.IOException;
+import java.util.HashMap;
+import java.util.Map;
import io.netty.channel.Channel;
@@ -72,33 +74,25 @@ public abstract class StreamMessage
PREPARE_ACK(9, 5, PrepareAckMessage.serializer ),
STREAM_INIT(10, 5, StreamInitMessage.serializer );
-private static final Type[] idToTypeMap;
+private static final Map idToTypeMap;
static
{
-Type[] values = values();
-
-int max = Integer.MIN_VALUE;
-for (Type t : values)
-max = max(t.id, max);
-
-Type[] idMap = new Type[max + 1];
-for (Type t : values)
+idToTypeMap = new HashMap<>();
+for (Type t : values())
{
-if (idMap[t.id] != null)
+if (idToTypeMap.put(t.id, t) != null)
throw new RuntimeException("Two StreamMessage Types map to
the same id: " + t.id);
-idMap[t.id] = t;
}
-
-idToTypeMap = idMap;
}
public static Type lookupById(int id)
{
-if (id < 0 || id >= idToTypeMap.length)
+Type t = idToTypeMap.get(id);
+if (t == null)
throw new IllegalArgumentException("Invalid type id: " + id);
-return idToTypeMap[id];
+return t;
}
public final int id;
diff --git
a/test/unit/org/apache/cassandra/streaming/messages/StreamMessageTest.java
b/test/unit/org/apache/cassandra/streaming/messages/StreamMessageTest.java
new file mode 100644
index 000..f50965e
--- /dev/null
+++ b/test/unit/org/apache/cassandra/streaming/messages/StreamMessageTest.java
@@ -0,0 +1,69 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.cassandra.streaming.messages;
+
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.List;
+import java.util.stream.Collectors;
+
+import org.junit.Test;
+
+import static org.junit.Assert.assertThat;
+import static org.hamcrest.CoreMatchers.instanceOf;
+import static org.junit.Assert.fail;
+
+public class StreamMessageTest
+{
+@Test
+public void testTypeLookup() // CASSANDRA-15965
+{
+List ids = Arrays.stream(StreamMessage.Type.values())
+ .mapToInt(t -> t.id)
+ .boxed()
+ .collect(Collectors.toList());
+
+for (int i: ids)
+{
+assertThat(StreamMessage.Type.lookupById(i),
instanceOf(StreamMessage.Type.class));
+}
+
+int max = Collections.max(ids);
+int min = Collections.min(ids);
+int[]
[cassandra] branch trunk updated (f670db4 -> 68aca10)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from f670db4 NPE thrown while updating speculative execution time if keyspace is removed during task execution new 2958c55 Fix null type returned in StreamMessage lookup new 68aca10 Remove flaky channelRead_Normal test that wasn't doing much The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../streaming/messages/StreamMessage.java | 24 +++- .../async/StreamingInboundHandlerTest.java | 12 .../streaming/messages/StreamMessageTest.java | 69 ++ 4 files changed, 79 insertions(+), 27 deletions(-) create mode 100644 test/unit/org/apache/cassandra/streaming/messages/StreamMessageTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16131) NPE in StreamingMessage type lookup
[
https://issues.apache.org/jira/browse/CASSANDRA-16131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16131:
--
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Component/s: Consistency/Streaming
Discovered By: Unit Test
Reviewers: Brandon Williams
Severity: Low
Status: Open (was: Triage Needed)
> NPE in StreamingMessage type lookup
> ---
>
> Key: CASSANDRA-16131
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16131
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> Found while investigating
> https://issues.apache.org/jira/browse/CASSANDRA-15965
> {noformat}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:51)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:172)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is a null in the zero.index of the type map. We can clean this up,
> handle invalid ids in a uniform manner, and add a test.
--
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-16131) NPE in StreamingMessage type lookup
[
https://issues.apache.org/jira/browse/CASSANDRA-16131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg reassigned CASSANDRA-16131:
-
Assignee: Adam Holmberg
> NPE in StreamingMessage type lookup
> ---
>
> Key: CASSANDRA-16131
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16131
> Project: Cassandra
> Issue Type: Bug
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> Found while investigating
> https://issues.apache.org/jira/browse/CASSANDRA-15965
> {noformat}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:51)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:172)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is a null in the zero.index of the type map. We can clean this up,
> handle invalid ids in a uniform manner, and add a test.
--
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-16131) NPE in StreamingMessage type lookup
[
https://issues.apache.org/jira/browse/CASSANDRA-16131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16131:
--
Fix Version/s: 4.0-beta3
> NPE in StreamingMessage type lookup
> ---
>
> Key: CASSANDRA-16131
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16131
> Project: Cassandra
> Issue Type: Bug
>Reporter: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> Found while investigating
> https://issues.apache.org/jira/browse/CASSANDRA-15965
> {noformat}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:51)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:172)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is a null in the zero.index of the type map. We can clean this up,
> handle invalid ids in a uniform manner, and add a test.
--
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-16131) NPE in StreamingMessage type lookup
Adam Holmberg created CASSANDRA-16131:
-
Summary: NPE in StreamingMessage type lookup
Key: CASSANDRA-16131
URL: https://issues.apache.org/jira/browse/CASSANDRA-16131
Project: Cassandra
Issue Type: Bug
Reporter: Adam Holmberg
Found while investigating https://issues.apache.org/jira/browse/CASSANDRA-15965
{noformat}
java.lang.NullPointerException: null
at
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:51)
at
org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:172)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
{noformat}
There is a null in the zero.index of the type map. We can clean this up, handle
invalid ids in a uniform manner, and add a test.
--
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-16049) org.apache.cassandra.distributed.test.ReadRepairTest#movingTokenReadRepairTest passes because the message drop filters are not dropping the messages
[
https://issues.apache.org/jira/browse/CASSANDRA-16049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16049:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Status: Review In Progress (was: Patch Available)
> org.apache.cassandra.distributed.test.ReadRepairTest#movingTokenReadRepairTest
> passes because the message drop filters are not dropping the messages
>
>
> Key: CASSANDRA-16049
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16049
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Test/dtest/java
>Reporter: David Capwell
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The test tries to block messages from node 4 to 3 but used verb ordinal
> rather than id; this causes the verbs to sent to node 3 and allow all replies
> to happen.
> If you fix the test to use id (and actually filter), then the test fails
> Patch to show the issue
> {code}
> diff --git
> a/test/distributed/org/apache/cassandra/distributed/test/ReadRepairTest.java
> b/test/distributed/org/apache/cassandra/distributed/test/ReadRepairTest.java
> index f0c82b85e1..55d2e8f303 100644
> ---
> a/test/distributed/org/apache/cassandra/distributed/test/ReadRepairTest.java
> +++
> b/test/distributed/org/apache/cassandra/distributed/test/ReadRepairTest.java
> @@ -30,14 +30,14 @@ import org.apache.cassandra.dht.Token;
> import org.apache.cassandra.distributed.Cluster;
> import org.apache.cassandra.distributed.api.ConsistencyLevel;
> import org.apache.cassandra.distributed.api.ICluster;
> -import org.apache.cassandra.distributed.shared.NetworkTopology;
> import org.apache.cassandra.locator.InetAddressAndPort;
> import org.apache.cassandra.service.PendingRangeCalculatorService;
> import org.apache.cassandra.service.StorageService;
> +import static org.apache.cassandra.distributed.shared.AssertUtils.assertRows;
> +import static org.apache.cassandra.distributed.shared.AssertUtils.row;
> import static org.apache.cassandra.net.Verb.READ_REPAIR_REQ;
> import static org.apache.cassandra.net.Verb.READ_REQ;
> -import static org.apache.cassandra.distributed.shared.AssertUtils.*;
> public class ReadRepairTest extends TestBaseImpl
> {
> @@ -115,8 +115,8 @@ public class ReadRepairTest extends TestBaseImpl
> // prevent #4 from reading or writing to #3, so our QUORUM must
> contain #2 and #4
> // since #1 is taking over the range, this means any read-repair
> must make it to #1 as well
> -cluster.filters().verbs(READ_REQ.ordinal()).from(4).to(3).drop();
> -
> cluster.filters().verbs(READ_REPAIR_REQ.ordinal()).from(4).to(3).drop();
> +cluster.filters().verbs(READ_REQ.id).from(4).to(3).drop();
> +cluster.filters().verbs(READ_REPAIR_REQ.id).from(4).to(3).drop();
> assertRows(cluster.coordinator(4).execute("SELECT * FROM " +
> KEYSPACE + ".tbl WHERE pk = ?",
> ConsistencyLevel.ALL,
> i),
>row(i, 1, 1));
> {code}
> Exception
> {code}
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 2 responses.
> at
> org.apache.cassandra.service.reads.ReadCallback.awaitResults(ReadCallback.java:120)
> at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:373)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1823)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1713)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1630)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1123)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:294)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:246)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeInternal(Coordinator.java:100)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:62)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
>
[jira] [Commented] (CASSANDRA-15986) Repair tests flakiness
[ https://issues.apache.org/jira/browse/CASSANDRA-15986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197239#comment-17197239 ] Ekaterina Dimitrova commented on CASSANDRA-15986: - No repair failures recorded in Jenkins lately. I plan to close this ticket next week in case nothing changes > Repair tests flakiness > -- > > Key: CASSANDRA-15986 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15986 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Berenguer Blasi >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-beta > > > Repair tests come up in test failure reports every now and then. I have tried > to repro the > [latest|https://ci-cassandra.apache.org/job/Cassandra-trunk/241/testReport/junit/dtest-novnode.repair_tests.repair_test/TestRepair/test_simple_sequential_repair/] > locally 100 times with no luck. > _dtest-novnode.repair_tests.repair_test/TestRepair/test_simple_sequential_repair_ > Still from experience from fixing other flaky tests I have some intuition > where the problems may lie. The proposed fix should add no harm if merged. We > can reopen the ticket if repair tests keep failing. -- 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-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 ] David Capwell updated CASSANDRA-15949: -- Fix Version/s: (was: 4.0-beta) 4.0-beta3 Since Version: 4.0-alpha Source Control Link: https://github.com/apache/cassandra/commit/ca027c3c2262f5a6789dbf41a5656a7bcf02a5f2 Resolution: Fixed Status: Resolved (was: Ready to Commit) CI results: https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/20/ https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-15949-trunk-B03EA88E-B95B-40C8-BF76-DA566646C28C I don't have as much history with Jenkins flaky tests, so I went off Circle CI's results for review. Also, Jenkins didn't have the same commit as circle as I ninja fixed an issue that was on trunk, so jenkins was missing ea322bfaa78b662c95711e6579b480b4d0f741c6 > 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-beta3 > > Time Spent: 2h > Remaining Estimate: 0h > > 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
[cassandra] branch trunk updated: NPE thrown while updating speculative execution time if keyspace is removed during task execution
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 f670db4 NPE thrown while updating speculative execution time if
keyspace is removed during task execution
f670db4 is described below
commit f670db4a0ec6c2d76b52fa1510f585c49b4f731e
Author: Caleb Rackliffe
AuthorDate: Wed Sep 16 09:52:42 2020 -0700
NPE thrown while updating speculative execution time if keyspace is removed
during task execution
patch by Caleb Rackliffe; reviewed by Aleksey Yeschenko, David Capwell for
CASSANDRA-15949
---
CHANGES.txt| 1 +
src/java/org/apache/cassandra/db/Keyspace.java | 76 ++---
src/java/org/apache/cassandra/db/ReadCommand.java | 6 +-
src/java/org/apache/cassandra/schema/Schema.java | 11 ++-
...leMetadataProvider.java => SchemaProvider.java} | 27 ++-
.../apache/cassandra/service/CassandraDaemon.java | 25 --
.../unit/org/apache/cassandra/db/KeyspaceTest.java | 22 -
.../net/MessageSerializationPropertyTest.java | 6 +-
.../cassandra/service/OptionalTasksTest.java | 94 ++
9 files changed, 220 insertions(+), 48 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 7761d87..90f5995 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -10,6 +10,7 @@
* When compaction gets interrupted, the exception should include the
compactionId (CASSANDRA-15954)
* Make Table/Keyspace Metric Names Consistent With Each Other
(CASSANDRA-15909)
* Mutating sstable component may race with entire-sstable-streaming(ZCS)
causing checksum validation failure (CASSANDRA-15861)
+ * NPE thrown while updating speculative execution time if keyspace is removed
during task execution (CASSANDRA-15949)
Merged from 3.11:
* Use IF NOT EXISTS for index and UDT create statements in snapshot schema
files (CASSANDRA-13935)
* Make sure LCS handles duplicate sstable added/removed notifications
correctly (CASSANDRA-14103)
diff --git a/src/java/org/apache/cassandra/db/Keyspace.java
b/src/java/org/apache/cassandra/db/Keyspace.java
index fc4f56f..1b05a36 100644
--- a/src/java/org/apache/cassandra/db/Keyspace.java
+++ b/src/java/org/apache/cassandra/db/Keyspace.java
@@ -19,18 +19,29 @@ package org.apache.cassandra.db;
import java.io.File;
import java.io.IOException;
-import java.util.*;
-import java.util.concurrent.*;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Objects;
+import java.util.Set;
+import java.util.concurrent.CompletableFuture;
+import java.util.concurrent.ConcurrentHashMap;
+import java.util.concurrent.ConcurrentMap;
+import java.util.concurrent.Future;
import java.util.concurrent.atomic.AtomicLong;
import java.util.concurrent.locks.Lock;
+import java.util.stream.Stream;
-import com.google.common.base.Function;
+import com.google.common.annotations.VisibleForTesting;
import com.google.common.collect.Iterables;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.apache.cassandra.concurrent.Stage;
-import org.apache.cassandra.config.*;
+import org.apache.cassandra.config.DatabaseDescriptor;
import org.apache.cassandra.db.compaction.CompactionManager;
import org.apache.cassandra.db.lifecycle.SSTableSet;
import org.apache.cassandra.db.partitions.PartitionUpdate;
@@ -48,14 +59,18 @@ import org.apache.cassandra.schema.KeyspaceMetadata;
import org.apache.cassandra.schema.ReplicationParams;
import org.apache.cassandra.schema.Schema;
import org.apache.cassandra.schema.SchemaConstants;
+import org.apache.cassandra.schema.SchemaProvider;
import org.apache.cassandra.schema.TableId;
import org.apache.cassandra.schema.TableMetadata;
import org.apache.cassandra.schema.TableMetadataRef;
import org.apache.cassandra.tracing.Tracing;
-import org.apache.cassandra.utils.*;
+import org.apache.cassandra.utils.ByteBufferUtil;
+import org.apache.cassandra.utils.FBUtilities;
+import org.apache.cassandra.utils.JVMStabilityInspector;
import org.apache.cassandra.utils.concurrent.OpOrder;
-import static java.util.concurrent.TimeUnit.*;
+import static java.util.concurrent.TimeUnit.MILLISECONDS;
+import static java.util.concurrent.TimeUnit.NANOSECONDS;
import static org.apache.cassandra.utils.MonotonicClock.approxTime;
/**
@@ -93,14 +108,7 @@ public class Keyspace
private final KeyspaceWriteHandler writeHandler;
private volatile ReplicationParams replicationParams;
private final KeyspaceRepairManager repairManager;
-
-public static final Function keyspaceTransformer = new
Function()
-{
-public Keyspace apply(String keyspaceName)
-{
-return Keyspace.open(keyspaceName);
-}
-};
+private final
[jira] [Assigned] (CASSANDRA-16114) Fix tests CQLTester.assertLastSchemaChange causes ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-16114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cedric Nabaa reassigned CASSANDRA-16114:
Assignee: Cedric Nabaa
> Fix tests CQLTester.assertLastSchemaChange causes ClassCastException
>
>
> Key: CASSANDRA-16114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16114
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Cedric Nabaa
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/494/workflows/b3765545-7b09-48dd-85ff-830c4f348329/jobs/2681
> {code}
> java.lang.ClassCastException:
> org.apache.cassandra.transport.messages.ResultMessage$Void cannot be cast to
> org.apache.cassandra.transport.messages.ResultMessage$SchemaChange
> at
> org.apache.cassandra.cql3.CQLTester.assertLastSchemaChange(CQLTester.java:916)
> at
> org.apache.cassandra.cql3.validation.entities.UFTest.testSchemaChange(UFTest.java:94)
> {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-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=17197219#comment-17197219
]
Stefan Miklosovic commented on CASSANDRA-13935:
---
Sorry by bad. It IS there, as merge commit. That is very confusing.
Thank you very much.
> 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: 3.0.23, 3.11.9, 4.0-beta3
>
> Attachments: 13935-3.0.txt, 13935-3.11.txt, 13935-trunk.txt
>
> Time Spent: 40m
> 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] [Comment Edited] (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=17197212#comment-17197212
]
Stefan Miklosovic edited comment on CASSANDRA-13935 at 9/16/20, 8:12 PM:
-
Hi [~blerer],
there are three branches, trunk, 3.11 and 3.0, each branch does something
different. Please resolve this.
https://github.com/apache/cassandra/pull/731 this is for trunk
https://github.com/apache/cassandra/pull/739 this is for 3.11
https://github.com/apache/cassandra/pull/740 this is for 3.0
My comments from 8th September are mentioning them.
Each branch is special for each Cassandra branch.
was (Author: stefan.miklosovic):
Hi Benjamin,
there are three branches, trunk, 3.11 and 3.0, each branch does something
different. Please resolve this.
https://github.com/apache/cassandra/pull/731 this is for trunk
https://github.com/apache/cassandra/pull/739 this is for 3.11
https://github.com/apache/cassandra/pull/740 this is for 3.0
My comments from 8th September are mentioning them.
Each branch is special for each Cassandra branch.
> 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: 3.0.23, 3.11.9, 4.0-beta3
>
> Attachments: 13935-3.0.txt, 13935-3.11.txt, 13935-trunk.txt
>
> Time Spent: 40m
> 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] [Updated] (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:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-13935:
--
Status: Open (was: Resolved)
> 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: 3.0.23, 3.11.9, 4.0-beta3
>
> Attachments: 13935-3.0.txt, 13935-3.11.txt, 13935-trunk.txt
>
> Time Spent: 40m
> 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-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=17197212#comment-17197212
]
Stefan Miklosovic commented on CASSANDRA-13935:
---
Hi Benjamin,
there are three branches, trunk, 3.11 and 3.0, each branch does something
different. Please resolve this.
https://github.com/apache/cassandra/pull/731 this is for trunk
https://github.com/apache/cassandra/pull/739 this is for 3.11
https://github.com/apache/cassandra/pull/740 this is for 3.0
My comments from 8th September are mentioning them.
Each branch is special for each Cassandra branch.
> 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: 3.0.23, 3.11.9, 4.0-beta3
>
> Attachments: 13935-3.0.txt, 13935-3.11.txt, 13935-trunk.txt
>
> Time Spent: 40m
> 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
[cassandra] branch trunk updated: ninja fix. While merging up CASSANDRA-14103 the merge missed setting sstable level in MockSchema
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 ea322bf ninja fix. While merging up CASSANDRA-14103 the merge missed setting sstable level in MockSchema ea322bf is described below commit ea322bfaa78b662c95711e6579b480b4d0f741c6 Author: David Capwell AuthorDate: Wed Sep 16 12:34:52 2020 -0700 ninja fix. While merging up CASSANDRA-14103 the merge missed setting sstable level in MockSchema --- test/unit/org/apache/cassandra/schema/MockSchema.java | 1 + 1 file changed, 1 insertion(+) diff --git a/test/unit/org/apache/cassandra/schema/MockSchema.java b/test/unit/org/apache/cassandra/schema/MockSchema.java index 7d2d874..dc207ee 100644 --- a/test/unit/org/apache/cassandra/schema/MockSchema.java +++ b/test/unit/org/apache/cassandra/schema/MockSchema.java @@ -141,6 +141,7 @@ public class MockSchema } SerializationHeader header = SerializationHeader.make(cfs.metadata(), Collections.emptyList()); StatsMetadata metadata = (StatsMetadata) new MetadataCollector(cfs.metadata().comparator) + .sstableLevel(level) .finalizeMetadata(cfs.metadata().partitioner.getClass().getCanonicalName(), 0.01f, UNREPAIRED_SSTABLE, null, false, header) .get(MetadataType.STATS); SSTableReader reader = SSTableReader.internalOpen(descriptor, components, cfs.metadata, - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15963) Flaky dtest test_dead_sync_initiator - repair_tests.repair_test.TestRepair
[
https://issues.apache.org/jira/browse/CASSANDRA-15963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg reassigned CASSANDRA-15963:
-
Assignee: Adam Holmberg
> Flaky dtest test_dead_sync_initiator - repair_tests.repair_test.TestRepair
> --
>
> Key: CASSANDRA-15963
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15963
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Yifan Cai
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> CI test link.
> [https://app.circleci.com/pipelines/github/yifan-c/cassandra/78/workflows/e89b96f1-c468-484f-9764-694b64fad95b/jobs/411]
> {code:java}
> test teardown failure
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [Stream-Deserializer-127.0.0.1:7000-56da8052] 2020-07-20 19:00:33,545
> CassandraEntireSSTableStreamReader.java:145 - [Stream
> 48a43e80-cabb-11ea-a743-3578c769ed44] Error while reading sstable from stream
> for table = keyspace1.standard1
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /tmp/dtest-4ichr2ha/test/node3/data0/keyspace1/standard1-3b1f65f0cabb11eaa7433578c769ed44/na-1-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:84)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:53)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:38)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:51)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:172)
> 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
> /tmp/dtest-4ichr2ha/test/node3/data0/keyspace1/standard1-3b1f65f0cabb11eaa7433578c769ed44/na-1-big-Statistics.db
> ... 12 common frames omitted, ERROR
> [Stream-Deserializer-127.0.0.1:7000-56da8052] 2020-07-20 19:00:33,545
> CassandraEntireSSTableStreamReader.java:145 - [Stream
> 48a43e80-cabb-11ea-a743-3578c769ed44] Error while reading sstable from stream
> for table = keyspace1.standard1
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /tmp/dtest-4ichr2ha/test/node3/data0/keyspace1/standard1-3b1f65f0cabb11eaa7433578c769ed44/na-1-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:84)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:53)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:38)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:51)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:172)
> 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
> /tmp/dtest-4ichr2ha/test/node3/data0/keyspace1/standard1-3b1f65f0cabb11eaa7433578c769ed44/na-1-big-Statistics.db
> ... 12 common frames omitted]{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[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=17197199#comment-17197199
]
David Capwell commented on CASSANDRA-16091:
---
With the above configs, and CASSANDRA-16127 I get the following
{code}
$ ./bin/nodetool info | grep active
Gossip active : true
Thrift active : false
Native Transport active: true
{code}
with this I should be able to start working on the test to block this next time.
> 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: David Capwell
>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-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=17197197#comment-17197197
]
David Capwell commented on CASSANDRA-16091:
---
I was able to replicate the original exception with the following
{code}
$ git diff
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 29442f5387..d815980d56 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -730,7 +730,7 @@ rpc_keepalive: true
#
# Alternatively, can provide your own RPC server by providing the
fully-qualified class name
# of an o.a.c.t.TServerFactory that can create an instance of it.
-rpc_server_type: sync
+rpc_server_type: hsha
# Uncomment rpc_min|max_thread to set request pool size limits.
#
@@ -742,8 +742,8 @@ rpc_server_type: sync
# encouraged to set a maximum that makes sense for you in production, but do
keep in mind that
# rpc_max_threads represents the maximum number of client requests this server
may execute concurrently.
#
-# rpc_min_threads: 16
-# rpc_max_threads: 2048
+rpc_min_threads: 16
+rpc_max_threads: 2048
# uncomment to set socket buffer sizes on rpc connections
# rpc_send_buff_size_in_bytes:
@@ -1057,10 +1057,10 @@ server_encryption_options:
# enable or disable client/server encryption.
client_encryption_options:
-enabled: false
+enabled: true
# If enabled and optional is set to true encrypted and unencrypted
connections are handled.
optional: false
-keystore: conf/.keystore
+keystore: ./test/conf/keystore.jks
keystore_password: cassandra
# require_client_auth: false
# Set trustore and truststore_password if require_client_auth is true
{code}
> 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: David Capwell
>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-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=17197192#comment-17197192
]
David Capwell commented on CASSANDRA-16091:
---
working on testing to replicate the issue. My intent is to fix the issue in
CASSANDRA-16127 but need tests for this specific case.
> 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: David Capwell
>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-16124) nodetool enablebinary throws exception
[
https://issues.apache.org/jira/browse/CASSANDRA-16124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16124:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: API /
Semantic Implementation(12988)
Complexity: Low Hanging Fruit
Component/s: Tool/nodetool
Discovered By: User Report
Fix Version/s: 3.11.x
3.0.x
2.2.x
Severity: Normal
Status: Open (was: Triage Needed)
> nodetool enablebinary throws exception
> --
>
> Key: CASSANDRA-16124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16124
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Tommy Stendahl
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> I think there is a bug in 3.11.8, if you disable the Native port its not
> possible to enable it (without restarting Cassandra).
> {quote}> nodetool statusbinary
> running
> > nodetool disablebinary
> > nodetool statusbinary
> not running
> > nodetool enablebinary
> error: Error starting native transport: setup() must be called first for
> CassandraDaemon
> – StackTrace –
> java.lang.RuntimeException: Error starting native transport: setup() must be
> called first for CassandraDaemon
> at
> org.apache.cassandra.service.StorageService.startNativeTransport(StorageService.java:429)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {quote}
> I think this was introduced with CASSANDRA-15967. In
> {{CassandraDaemon.stopNativeTransport()}} {{nativeTransportService}} is set
> to {{null}} and when {{CassandraDaemon.startNativeTransport()}} is called the
> exception is thrown. By adding a call to
> {{CassandraDaemon.initializeNativeTransport()}} before calling
> {{CassandraDaemon.startNativeTransport()}} works but I'm not sure what the
> intention here
[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
]
David Capwell reassigned CASSANDRA-16091:
-
Assignee: David Capwell (was: 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: David Capwell
>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] [Assigned] (CASSANDRA-16124) nodetool enablebinary throws exception
[
https://issues.apache.org/jira/browse/CASSANDRA-16124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell reassigned CASSANDRA-16124:
-
Assignee: David Capwell
> nodetool enablebinary throws exception
> --
>
> Key: CASSANDRA-16124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16124
> Project: Cassandra
> Issue Type: Bug
>Reporter: Tommy Stendahl
>Assignee: David Capwell
>Priority: Normal
>
> I think there is a bug in 3.11.8, if you disable the Native port its not
> possible to enable it (without restarting Cassandra).
> {quote}> nodetool statusbinary
> running
> > nodetool disablebinary
> > nodetool statusbinary
> not running
> > nodetool enablebinary
> error: Error starting native transport: setup() must be called first for
> CassandraDaemon
> – StackTrace –
> java.lang.RuntimeException: Error starting native transport: setup() must be
> called first for CassandraDaemon
> at
> org.apache.cassandra.service.StorageService.startNativeTransport(StorageService.java:429)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {quote}
> I think this was introduced with CASSANDRA-15967. In
> {{CassandraDaemon.stopNativeTransport()}} {{nativeTransportService}} is set
> to {{null}} and when {{CassandraDaemon.startNativeTransport()}} is called the
> exception is thrown. By adding a call to
> {{CassandraDaemon.initializeNativeTransport()}} before calling
> {{CassandraDaemon.startNativeTransport()}} works but I'm not sure what the
> intention here is.
--
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=17197187#comment-17197187
]
David Capwell commented on CASSANDRA-16091:
---
spoke to [~brandon.williams] in slack, will take this as it looks like I broke
it.
> 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: David Capwell
>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-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197188#comment-17197188
]
Yifan Cai commented on CASSANDRA-15965:
---
bq. it gets there too late and the condition will never be true.
Thanks for the clarification. Yeah. Spin assert won't help in this case.
The fix will go into the change log. So either change both the ticket title and
description (which seems messy), or just create a new ticket and link to this
one, so the context is not lost.
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197141#comment-17197141
]
Brandon Williams edited comment on CASSANDRA-15965 at 9/16/20, 6:21 PM:
[CI|https://ci-cassandra.apache.org/job/Cassandra-devbranch/22/]
was (Author: brandon.williams):
[CI|https://ci-cassandra.apache.org/job/Cassandra-devbranch/21/]
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197170#comment-17197170
]
Brandon Williams commented on CASSANDRA-15965:
--
I don't have much preference on new ticket or not; we don't mention test fixes
in the changelog, but I'll appropriately put an entry about the NPE fix and we
can even rename the ticket. Or just make another one, whichever.
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-15965:
--
Status: Review In Progress (was: Changes Suggested)
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197165#comment-17197165
]
Adam Holmberg commented on CASSANDRA-15965:
---
> Util#spinAssertEquals could be an alternative, and the test can be kept.
It's not a matter of the test thread getting there too early -- it gets there
too late and the condition will never be true. By then the buffer has been read.
>Do we want to open a new ticket for fixing the NPE?
In the past we've included production code changes in the flaky test ticket
that discovered them. I will open a new ticket if that's needed. lmk.
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197158#comment-17197158
]
Yifan Cai commented on CASSANDRA-15965:
---
If it is a timing issue in the {{channelRead_Normal}} test,
{{Util#spinAssertEquals}} could be an alternative, and the test can be kept.
Do we want to open a new ticket for fixing the NPE? A bit of trouble, but the
new ticket can better describe the goal of the patch. This one just reports a
flaky test.
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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-16126) Blog post on Cassandra Usage Report 2020
[ https://issues.apache.org/jira/browse/CASSANDRA-16126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sankalp Kohli updated CASSANDRA-16126: -- Reviewers: Nate McCall (was: Nate McCall, Sankalp Kohli) > Blog post on Cassandra Usage Report 2020 > > > Key: CASSANDRA-16126 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16126 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Melissa Logan >Assignee: Melissa Logan >Priority: Normal > Fix For: 4.0-beta > > > Blog post on the 2020 Cassandra Usage Report. > ML: > [https://lists.apache.org/thread.html/r8a91b1d63079739c8dfbdab1833c66d58326de91a659afa3fb2a41a7%40%3Cdev.cassandra.apache.org%3E] > > PR: [https://github.com/apache/cassandra-website/pull/21] -- 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-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197141#comment-17197141
]
Brandon Williams commented on CASSANDRA-15965:
--
[CI|https://ci-cassandra.apache.org/job/Cassandra-devbranch/21/]
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197139#comment-17197139
]
Adam Holmberg commented on CASSANDRA-15965:
---
[added|https://github.com/aholmberg/cassandra/commit/4fa6db0277eee6a28b38ab61d2ac23e55756a018]
Presently trying to figure out why circleci won't create a workflow for this
commit.
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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-16125) Allow optional query retry in cassandra-diff
[ https://issues.apache.org/jira/browse/CASSANDRA-16125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16125: Reviewers: Marcus Eriksson > Allow optional query retry in cassandra-diff > > > Key: CASSANDRA-16125 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16125 > Project: Cassandra > Issue Type: Improvement > Components: Tool/diff >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > The diff job fails when seeing the first query timeout/unavailable. > We can add an optional retry policy to add the spark workers retry the failed > query for a maximum amount of duration (i.e. retry timeout). > When the retry policy is set, the job only fails after the retry timeout > exceeds. -- 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-16125) Allow optional query retry in cassandra-diff
[ https://issues.apache.org/jira/browse/CASSANDRA-16125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197137#comment-17197137 ] Yifan Cai commented on CASSANDRA-16125: --- [~marcuse], would you like to review? > Allow optional query retry in cassandra-diff > > > Key: CASSANDRA-16125 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16125 > Project: Cassandra > Issue Type: Improvement > Components: Tool/diff >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > The diff job fails when seeing the first query timeout/unavailable. > We can add an optional retry policy to add the spark workers retry the failed > query for a maximum amount of duration (i.e. retry timeout). > When the retry policy is set, the job only fails after the retry timeout > exceeds. -- 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-16125) Allow optional query retry in cassandra-diff
[
https://issues.apache.org/jira/browse/CASSANDRA-16125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-16125:
--
Test and Documentation Plan: unit test
Status: Patch Available (was: Open)
PR: [https://github.com/apache/cassandra-diff/pull/12]
* Retry at the application level.
* Added 2 strategies in the PR, {{NoRetry}} and {{ExponentialRetry}}.
* {{RetryStrategy}} is made pluggable, as long as that the custom
implementation extends the base and specify it in the config. Therefore, the
constructor takes a map that is read from config.
* {{NoRetry}} is used if no {{RetryOptions}} is supplied in the config.
The {{ExponentialRetry}} takes 2 parameters, base and total delay in
milliseconds. Each time when retry is permitted, the paused time is increased
exponentially. When the total time from the past pauses exceeds the specified
{{totalDelayMs}}, the retry strategy no longer permits more retries.
> Allow optional query retry in cassandra-diff
>
>
> Key: CASSANDRA-16125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16125
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/diff
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> The diff job fails when seeing the first query timeout/unavailable.
> We can add an optional retry policy to add the spark workers retry the failed
> query for a maximum amount of duration (i.e. retry timeout).
> When the retry policy is set, the job only fails after the retry timeout
> exceeds.
--
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-16036) Add flag to disable chunk cache and disable by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197107#comment-17197107
]
ZhaoYang commented on CASSANDRA-16036:
--
I wonder if the chunk-cache regression is related to CASSANDRA-15229, let me
run some tests from CASSANDRA-15229.
Also, I am not a committer, you may need to find one more...
> Add flag to disable chunk cache and disable by default
> --
>
> Key: CASSANDRA-16036
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16036
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: async-profile.collapsed.svg,
> clustering-in-clause_latency_selects_baseline.png,
> clustering-in-clause_latency_selects_baseline_attempt3.png,
> clustering-in-clause_latency_under90_selects_baseline.png,
> clustering-in-clause_latency_under90_selects_baseline_attempt3.png,
> clustering-slice_latency_selects_baseline.png,
> clustering-slice_latency_under90_selects_baseline.png,
> medium-blobs_latency_selects_baseline.png,
> medium-blobs_latency_under90_selects_baseline.png,
> partition-single-row-read_latency_selects_baseline.png,
> partition-single-row-read_latency_under90_selects_baseline.png
>
>
> Chunk cache is enabled by default and doesn’t have a flag to disable without
> impacting networking. In performance testing 4.0 against 3.0 I found that
> reads were slower in 4.0 and after profiling found that the ChunkCache was
> partially to blame; after disabling the chunk cache, read performance had
> improved.
> {code}
> 40_w_cc-selects.hdr
> #[Mean= 11.50063, StdDeviation = 13.44014]
> #[Max =482.41254, Total count= 316477]
> #[Buckets = 25, SubBuckets = 262144]
> 40_wo_cc-selects.hdr
> #[Mean= 9.82115, StdDeviation = 10.14270]
> #[Max =522.36493, Total count= 317444]
> #[Buckets = 25, SubBuckets = 262144]
> {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-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15965:
-
Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams)
Brandon Williams, Brandon Williams
Status: Review In Progress (was: Patch Available)
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15965:
-
Status: Changes Suggested (was: Review In Progress)
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-15965:
Assignee: Adam Holmberg
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197085#comment-17197085
]
Adam Holmberg commented on CASSANDRA-15965:
---
Yes. And frankly I'm embarrassed the first PR didn't include one. I think I had
it in my head that I was just tidying existing functionality. I'll update today.
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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-16101) Make sure we don't throw any uncaught exceptions during in-jvm dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197079#comment-17197079
]
David Capwell commented on CASSANDRA-16101:
---
One potential would be to add a method to cluster that resets the exceptions
list and throws if one is found; could make sure all tests call that (and close
would do the same)
Tested how CI would work in this model
{code}
@Test
public void happyTest()
{
System.out.println("happy");
}
@After
public void after()
{
throw new RuntimeException("YOLO");
}
{code}
{code}
[junit-timeout] Testcase:
happyTest(org.apache.cassandra.distributed.test.ClientNetworkStopStartTest):
Caused an ERROR
[junit-timeout] YOLO
[junit-timeout] java.lang.RuntimeException: YOLO
[junit-timeout] at
org.apache.cassandra.distributed.test.ClientNetworkStopStartTest.after(ClientNetworkStopStartTest.java:64)
{code}
since the after method attributes the failure to the proper test case, could
leverage this to avoid close shutting down in these types of tests?
> Make sure we don't throw any uncaught exceptions during in-jvm dtests
> -
>
> Key: CASSANDRA-16101
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16101
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
>
> We should assert that we don't throw any uncaught exceptions when running
> in-jvm dtests
--
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-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:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-15158: Fix Version/s: 4.0-beta 3.11.x 3.0.x > 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 > Fix For: 3.0.x, 3.11.x, 4.0-beta > > 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-16101) Make sure we don't throw any uncaught exceptions during in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197076#comment-17197076 ] David Capwell commented on CASSANDRA-16101: --- The test I am worried about are (only choose one permutation) * https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/test/FullRepairCoordinatorFastTest.java * https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/test/FullRepairCoordinatorTimeoutTest.java * https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/test/FullRepairCoordinatorNeighbourDownTest.java shutting down the cluster is here: https://github.com/apache/cassandra/blob/be7c9e22b085d67cf867e53ae9e9fed3d7c2e03c/test/distributed/org/apache/cassandra/distributed/test/RepairCoordinatorBase.java#L87 at this point, the AfterClass method will fail and doesn't have enough details to know if the failure is expected or not. All the tests I know which reuse a cluster have this same problem. bq. I'm thinking, if, instead of adding all exceptions as suppressed to the first Cause, should we mabye add them as suppressed to ShutdownException itself? Sounds like a good idea! Not sure it would help the reuse cluster tests though given my point above; close lacks context of what is acceptable and what isn't. > Make sure we don't throw any uncaught exceptions during in-jvm dtests > - > > Key: CASSANDRA-16101 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16101 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > > We should assert that we don't throw any uncaught exceptions when running > in-jvm dtests -- 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-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 updated CASSANDRA-15949: Status: Ready to Commit (was: Review In Progress) > 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 > > Time Spent: 2h > Remaining Estimate: 0h > > 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] [Updated] (CASSANDRA-16126) Blog post on Cassandra Usage Report 2020
[ https://issues.apache.org/jira/browse/CASSANDRA-16126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-16126: --- Reviewers: Nate McCall, Sankalp Kohli (was: Jeff Jirsa, Nate McCall, Sankalp Kohli) > Blog post on Cassandra Usage Report 2020 > > > Key: CASSANDRA-16126 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16126 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Melissa Logan >Assignee: Melissa Logan >Priority: Normal > Fix For: 4.0-beta > > > Blog post on the 2020 Cassandra Usage Report. > ML: > [https://lists.apache.org/thread.html/r8a91b1d63079739c8dfbdab1833c66d58326de91a659afa3fb2a41a7%40%3Cdev.cassandra.apache.org%3E] > > PR: [https://github.com/apache/cassandra-website/pull/21] -- 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-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:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-13935:
---
Fix Version/s: (was: 4.0-beta)
4.0-beta3
3.11.9
3.0.23
Since Version: 3.0.0
Source Control Link:
https://github.com/apache/cassandra/commit/277d83961c7332941a9339bf890dbe0c89029ae3
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Patch committed into branch cassandra-3.0 at
277d83961c7332941a9339bf890dbe0c89029ae3 and merged into cassandra-3.11 and
trunk
> 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: 3.0.23, 3.11.9, 4.0-beta3
>
> Attachments: 13935-3.0.txt, 13935-3.11.txt, 13935-trunk.txt
>
> Time Spent: 40m
> 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
[cassandra] branch cassandra-3.0 updated (bd1b84d -> 277d839)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from bd1b84d in-jvm dtests should validate Instance#serializeMessage serializeSize matches bytes written add 277d839 Use IF NOT EXISTS for index and UDT create statements in snapshot schema files No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + .../cassandra/db/ColumnFamilyStoreCQLHelper.java | 6 +++--- .../cassandra/db/ColumnFamilyStoreCQLHelperTest.java | 20 ++-- 3 files changed, 14 insertions(+), 13 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (9a30167 -> be7c9e2)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 9a30167 ninja fix build, add jmxtool to rpm and deb packaging add 277d839 Use IF NOT EXISTS for index and UDT create statements in snapshot schema files add cbb7644 Merge branch cassandra-3.0 into cassandra-3.11 new be7c9e2 Merge branch cassandra-3.11 into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../org/apache/cassandra/cql3/SchemaElement.java | 3 +- .../cassandra/cql3/functions/UDAggregate.java | 12 +++- .../cassandra/cql3/functions/UDFunction.java | 13 +++-- .../cql3/statements/DescribeStatement.java | 8 +-- .../org/apache/cassandra/db/SchemaCQLHelper.java | 17 -- .../org/apache/cassandra/db/marshal/UserType.java | 12 +++- .../org/apache/cassandra/schema/IndexMetadata.java | 28 +++--- .../apache/cassandra/schema/KeyspaceMetadata.java | 12 +++- .../org/apache/cassandra/schema/TableMetadata.java | 4 +- .../org/apache/cassandra/schema/ViewMetadata.java | 12 +--- .../cql3/validation/entities/UFJavaTest.java | 65 +- .../apache/cassandra/db/SchemaCQLHelperTest.java | 19 --- 13 files changed, 154 insertions(+), 52 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197027#comment-17197027
]
Brandon Williams commented on CASSANDRA-15965:
--
I'm fine with removing the test, but for the NPE can we add one?
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
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 cassandra-3.11 updated (f41ea9f -> cbb7644)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from f41ea9f Make sure LCS handles duplicate sstable added/removed notifications correctly. add 277d839 Use IF NOT EXISTS for index and UDT create statements in snapshot schema files add cbb7644 Merge branch cassandra-3.0 into cassandra-3.11 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/db/ColumnFamilyStoreCQLHelper.java | 6 +++--- .../db/ColumnFamilyStoreCQLHelperTest.java | 22 +++--- 3 files changed, 15 insertions(+), 14 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197025#comment-17197025 ] Jordan West commented on CASSANDRA-16048: - [~ifesdjeen] thanks! I see the extra step necessary to produce the difference (my test basically validates the row is still gone but doesn't test subsequent deletes). I'll have to think about that in the context of this change a bit more. The test in the branch and the one I linked also shows its safe (excluding this delete case I need to dig into more) to have mixed schema (during agreement). > Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and > Value Columns > -- > > Key: CASSANDRA-16048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16048 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > Some compact storage tables, specifically those where the user has defined > both at least one clustering and the value column, can be safely handled in > 4.0 because besides the DENSE flag they are not materially different post 3.0 > and there is no visible change to the user facing schema after dropping > compact storage. We can detect this case and allow these tables to silently > drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE > tables that don’t meet the criteria. -- 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-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197025#comment-17197025 ] Jordan West edited comment on CASSANDRA-16048 at 9/16/20, 2:54 PM: --- [~ifesdjeen] thanks! I see the extra step necessary to produce the difference (my test basically validates the row is still gone but doesn't test subsequent deletes). I'll have to think about that in the context of this change a bit more. The test in the branch and the one I linked also shows its safe (excluding this delete case I need to dig into more) to have mixed schema. was (Author: jrwest): [~ifesdjeen] thanks! I see the extra step necessary to produce the difference (my test basically validates the row is still gone but doesn't test subsequent deletes). I'll have to think about that in the context of this change a bit more. The test in the branch and the one I linked also shows its safe (excluding this delete case I need to dig into more) to have mixed schema (during agreement). > Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and > Value Columns > -- > > Key: CASSANDRA-16048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16048 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > Some compact storage tables, specifically those where the user has defined > both at least one clustering and the value column, can be safely handled in > 4.0 because besides the DENSE flag they are not materially different post 3.0 > and there is no visible change to the user facing schema after dropping > compact storage. We can detect this case and allow these tables to silently > drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE > tables that don’t meet the criteria. -- 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-16127) NullPointerException when calling nodetool enablethrift
[
https://issues.apache.org/jira/browse/CASSANDRA-16127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197020#comment-17197020
]
David Capwell commented on CASSANDRA-16127:
---
Thanks for taking a look and trying!
CASSANDRA-16091 is more concerning as no test guards that, so I won’t say it’s
fixed without proper testing guarding it (this patch doesn’t right now). I’ll
sync with [~brandon.williams] since he is assigned that
> NullPointerException when calling nodetool enablethrift
> ---
>
> Key: CASSANDRA-16127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16127
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Thrift
>Reporter: Tibor Repasi
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> Having thrift disabled, it's impossible to enable it again without restarting
> the node:
> {code}
> $ nodetool statusthrift
> not running
> $ nodetool enablethrift
> error: null
> -- StackTrace --
> java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageService.startRPCServer(StorageService.java:392)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {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-15241) Virtual table to expose current running queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197000#comment-17197000
]
Chris Lohfink commented on CASSANDRA-15241:
---
I wasn't sure I should put this in 4.0 but I would love to.
> Virtual table to expose current running queries
> ---
>
> Key: CASSANDRA-15241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15241
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Fix For: 4.0
>
>
> Expose current running queries and their duration.
> {code}cqlsh> select * from system_views.queries;
> thread_id| duration_micros | task
> --+-+-
> Native-Transport-Requests-17 |6325 | QUERY
> select * from system_views.queries; [pageSize = 100]
> Native-Transport-Requests-4 | 14681 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> Native-Transport-Requests-6 | 14678 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> ReadStage-10 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-13 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-14 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-19 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-20 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-22 |7279 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-23 |4716 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-5 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-7 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-8 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000{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-16078) Performance regression for queries accessing multiple rows
[ https://issues.apache.org/jira/browse/CASSANDRA-16078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16078: Attachment: image.png > Performance regression for queries accessing multiple rows > -- > > Key: CASSANDRA-16078 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16078 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination >Reporter: David Capwell >Priority: Normal > Fix For: 4.0-beta > > Attachments: image.png > > > This is spin off from CASSANDRA-16036. > In testing 4.0 relative to 3.0* I found that queries which accessed multiple > rows to have a noticeable performance decrease; two queries were used in the > test (more may be impacted, others might not): query partition (table has > clustering keys) with LIMIT, and query clustering keys using IN clause. > In the below graphs the green line is 3.0 and the other lines are 4.0 (with > and without chunk cache) > Partition with LIMIT > !https://issues.apache.org/jira/secure/attachment/13009751/clustering-slice_latency_selects_baseline.png! > !https://issues.apache.org/jira/secure/attachment/13009750/clustering-slice_latency_under90_selects_baseline.png! > Cluster with IN clause > !https://issues.apache.org/jira/secure/attachment/13009749/clustering-in-clause_latency_selects_baseline.png! > !https://issues.apache.org/jira/secure/attachment/13009748/clustering-in-clause_latency_under90_selects_baseline.png! -- 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-16121) Circleci should run cqlshlib tests as well
[ https://issues.apache.org/jira/browse/CASSANDRA-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196979#comment-17196979 ] Ekaterina Dimitrova commented on CASSANDRA-16121: - Hi [~Bereng], Thanks for the update, can you also update the patch files, please? I think at least the HIGHRES needs an update for the large resources? > Circleci should run cqlshlib tests as well > -- > > Key: CASSANDRA-16121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16121 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Currently circleci is not running cqlshlib tests. This resulted in some bugs > not being caught before committing. -- 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-16109) Don't adjust nodeCount when setting node id topology in in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196969#comment-17196969 ] Marcus Eriksson commented on CASSANDRA-16109: - merged the dtest pr, will run a full cci suite once we have a snapshot released (guessing it would make sense to wait for https://github.com/apache/cassandra-in-jvm-dtest-api/pull/16 and https://github.com/apache/cassandra-in-jvm-dtest-api/pull/17 before doing that) > Don't adjust nodeCount when setting node id topology in in-jvm dtests > - > > Key: CASSANDRA-16109 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16109 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Low > > We update the node count when setting the node id topology in in-jvm dtests, > this should only happen if node count is smaller than the node id topology, > otherwise bootstrap tests error out. -- 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-in-jvm-dtest-api] branch master updated: collect dc/rack information and validate when building (#15)
This is an automated email from the ASF dual-hosted git repository.
marcuse pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git
The following commit(s) were added to refs/heads/master by this push:
new 2720fff collect dc/rack information and validate when building (#15)
2720fff is described below
commit 2720fff0471abf807e7cbeb07048cc29c03b0c69
Author: Marcus Eriksson
AuthorDate: Wed Sep 16 15:20:29 2020 +0200
collect dc/rack information and validate when building (#15)
Patch by marcuse; reviewed by Alex Petrov for CASSANDRA-16109
---
pom.xml| 6 +
.../distributed/shared/AbstractBuilder.java| 193 +++--
.../distributed/shared/NetworkTopology.java| 4 +-
.../cassandra/distributed/api/BuilderTest.java | 104 +++
4 files changed, 255 insertions(+), 52 deletions(-)
diff --git a/pom.xml b/pom.xml
index 5e36e66..49113d7 100644
--- a/pom.xml
+++ b/pom.xml
@@ -69,6 +69,12 @@
3.15.0
test
+
+ org.mockito
+mockito-core
+3.5.10
+test
+
diff --git
a/src/main/java/org/apache/cassandra/distributed/shared/AbstractBuilder.java
b/src/main/java/org/apache/cassandra/distributed/shared/AbstractBuilder.java
index 63ceca3..47f2d48 100644
--- a/src/main/java/org/apache/cassandra/distributed/shared/AbstractBuilder.java
+++ b/src/main/java/org/apache/cassandra/distributed/shared/AbstractBuilder.java
@@ -26,7 +26,10 @@ import org.apache.cassandra.distributed.api.TokenSupplier;
import java.io.File;
import java.io.IOException;
import java.nio.file.Files;
+import java.util.ArrayList;
+import java.util.Collections;
import java.util.HashMap;
+import java.util.List;
import java.util.Map;
import java.util.Objects;
import java.util.function.BiConsumer;
@@ -55,6 +58,8 @@ public abstract class AbstractBuilder instanceInitializer = (cl, id) ->
{};
private int datadirCount = 3;
+private final List racks = new ArrayList<>();
+private boolean finalised;
public AbstractBuilder(Factory factory)
{
@@ -116,19 +121,12 @@ public abstract class AbstractBuilder
nodeId,
-nodeId ->
NetworkTopology.dcAndRack(dcName(0), rackName(0;
-
// TODO: make token allocation strategy configurable
if (tokenSupplier == null)
tokenSupplier = evenlyDistributedTokens(nodeCount);
@@ -159,72 +157,72 @@ public abstract class AbstractBuilder 0 && racksPerDC > 0 : "Both dcCount and racksPerDC
must be > 0";
-int totalRacks = dcCount * racksPerDC;
-int nodesPerRack = (nodeCount + totalRacks - 1) / totalRacks; // round
up to next integer
-return withRacks(dcCount, racksPerDC, nodesPerRack);
+for (int dc = 1; dc <= dcCount; dc++)
+for (int rack = 1; rack <= racksPerDC; rack++)
+withRack(dcName(dc), rackName(rack), -1);
+return (B) this;
}
+/**
+ * Creates a cluster with dcCount datacenters, racksPerDC racks in each dc
and nodesPerRack nodes in each rack
+ *
+ * Note that node count must be >= dcCount * datacenters * racksPerDC, if
it is smaller it will get adjusted up.
+ */
public B withRacks(int dcCount, int racksPerDC, int nodesPerRack)
{
-if (nodeIdTopology != null)
-throw new IllegalStateException("Network topology already created.
Call withDCs/withRacks once or before withDC/withRack calls");
-
-nodeIdTopology = new HashMap<>();
-int nodeId = 1;
+assert dcCount > 0 && racksPerDC > 0 && nodesPerRack > 0 : "dcCount,
racksPerDC and nodesPerRack must be > 0";
for (int dc = 1; dc <= dcCount; dc++)
-{
for (int rack = 1; rack <= racksPerDC; rack++)
-{
-for (int rackNodeIdx = 0; rackNodeIdx < nodesPerRack;
rackNodeIdx++)
-nodeIdTopology.put(nodeId++,
NetworkTopology.dcAndRack(dcName(dc), rackName(rack)));
-}
-}
-// adjust the node count to match the allocatation
-final int adjustedNodeCount = dcCount * racksPerDC * nodesPerRack;
-if (adjustedNodeCount != nodeCount)
-{
-assert adjustedNodeCount > nodeCount : "withRacks should only ever
increase the node count";
-System.out.println(String.format("Network topology of %s DCs with
%s racks per DC and %s nodes per rack required increasing total nodes to %s",
- dcCount, racksPerDC,
nodesPerRack, adjustedNodeCount));
-nodeCount = adjustedNodeCount;
-}
+withRack(dcName(dc), rackName(rack), nodesPerRack);
return (B) this;
}
+/**
+ * Add a dc with name dcName containing a single rack with nodeCount nodes
+ */
[jira] [Updated] (CASSANDRA-15880) Memory leak in CompressedChunkReader
[ https://issues.apache.org/jira/browse/CASSANDRA-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15880: Status: Patch Available (was: In Progress) > Memory leak in CompressedChunkReader > > > Key: CASSANDRA-15880 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15880 > Project: Cassandra > Issue Type: Bug > Components: Feature/Compression >Reporter: Jaroslaw Grabowski >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0, 3.11.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > > CompressedChunkReader uses java.lang.ThreadLocal to reuse ByteBuffer for > compressed data. ByteBuffers leak due to peculiar ThreadLocal quality. > ThreadLocals are stored in a map, where the key is a weak reference to a > ThreadLocal and the value is the user's object (ByteBuffer in this case). > When a last strong reference to a ThreadLocal is lost, weak reference to > ThreadLocal (key) is removed but the value (ByteBuffer) is kept until cleaned > by ThreadLocal heuristic expunge mechanism. See ThreadLocal's "stale entries" > for details. > When a number of long-living threads is high enough this results in thousands > of ByteBuffers stored as stale entries in ThreadLocals. In a not-so-lucky > scenario we get OutOfMemoryException. -- 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-16109) Don't adjust nodeCount when setting node id topology in in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-16109: Status: Ready to Commit (was: Review In Progress) > Don't adjust nodeCount when setting node id topology in in-jvm dtests > - > > Key: CASSANDRA-16109 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16109 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Low > > We update the node count when setting the node id topology in in-jvm dtests, > this should only happen if node count is smaller than the node id topology, > otherwise bootstrap tests error out. -- 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-16109) Don't adjust nodeCount when setting node id topology in in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-16109: Reviewers: Alex Petrov, Alex Petrov (was: Alex Petrov) Alex Petrov, Alex Petrov (was: Alex Petrov) Status: Review In Progress (was: Patch Available) > Don't adjust nodeCount when setting node id topology in in-jvm dtests > - > > Key: CASSANDRA-16109 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16109 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Low > > We update the node count when setting the node id topology in in-jvm dtests, > this should only happen if node count is smaller than the node id topology, > otherwise bootstrap tests error out. -- 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-16109) Don't adjust nodeCount when setting node id topology in in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196956#comment-17196956 ] Alex Petrov commented on CASSANDRA-16109: - Thank you for the update. I've added some small changes that consolidate `finalise` logic and a couple of tests, pushed it to your branch, you can consider those changes when committing. +1 > Don't adjust nodeCount when setting node id topology in in-jvm dtests > - > > Key: CASSANDRA-16109 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16109 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Low > > We update the node count when setting the node id topology in in-jvm dtests, > this should only happen if node count is smaller than the node id topology, > otherwise bootstrap tests error out. -- 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-15241) Virtual table to expose current running queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196945#comment-17196945
]
Benjamin Lerer commented on CASSANDRA-15241:
[~cnlwsu] It seems that this ticket is being blocked on your side. Do you need
some help to push it accross the finish line?
> Virtual table to expose current running queries
> ---
>
> Key: CASSANDRA-15241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15241
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Fix For: 4.0
>
>
> Expose current running queries and their duration.
> {code}cqlsh> select * from system_views.queries;
> thread_id| duration_micros | task
> --+-+-
> Native-Transport-Requests-17 |6325 | QUERY
> select * from system_views.queries; [pageSize = 100]
> Native-Transport-Requests-4 | 14681 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> Native-Transport-Requests-6 | 14678 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> ReadStage-10 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-13 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-14 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-19 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-20 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-22 |7279 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-23 |4716 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-5 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-7 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-8 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000{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-16127) NullPointerException when calling nodetool enablethrift
[
https://issues.apache.org/jira/browse/CASSANDRA-16127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196933#comment-17196933
]
Tommy Stendahl commented on CASSANDRA-16127:
I took a closer look at the patch and tested and it did solve CASSANDRA-16124.
The patch LGTM.
> NullPointerException when calling nodetool enablethrift
> ---
>
> Key: CASSANDRA-16127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16127
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Thrift
>Reporter: Tibor Repasi
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> Having thrift disabled, it's impossible to enable it again without restarting
> the node:
> {code}
> $ nodetool statusthrift
> not running
> $ nodetool enablethrift
> error: null
> -- StackTrace --
> java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageService.startRPCServer(StorageService.java:392)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {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-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:comment-tabpanel=17196918#comment-17196918 ] Aleksey Yeschenko commented on CASSANDRA-15949: --- bq. Thanks! Should I consider that a "+1"? Indeed you should (: > 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 > > Time Spent: 2h > Remaining Estimate: 0h > > 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] [Updated] (CASSANDRA-16126) Blog post on Cassandra Usage Report 2020
[ https://issues.apache.org/jira/browse/CASSANDRA-16126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16126: --- Fix Version/s: 4.0-beta > Blog post on Cassandra Usage Report 2020 > > > Key: CASSANDRA-16126 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16126 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Melissa Logan >Assignee: Melissa Logan >Priority: Normal > Fix For: 4.0-beta > > > Blog post on the 2020 Cassandra Usage Report. > ML: > [https://lists.apache.org/thread.html/r8a91b1d63079739c8dfbdab1833c66d58326de91a659afa3fb2a41a7%40%3Cdev.cassandra.apache.org%3E] > > PR: [https://github.com/apache/cassandra-website/pull/21] -- 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-16126) Blog post on Cassandra Usage Report 2020
[ https://issues.apache.org/jira/browse/CASSANDRA-16126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16126: --- Status: Open (was: Triage Needed) > Blog post on Cassandra Usage Report 2020 > > > Key: CASSANDRA-16126 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16126 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Melissa Logan >Assignee: Melissa Logan >Priority: Normal > > Blog post on the 2020 Cassandra Usage Report. > ML: > [https://lists.apache.org/thread.html/r8a91b1d63079739c8dfbdab1833c66d58326de91a659afa3fb2a41a7%40%3Cdev.cassandra.apache.org%3E] > > PR: [https://github.com/apache/cassandra-website/pull/21] -- 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-16126) Blog post on Cassandra Usage Report 2020
[ https://issues.apache.org/jira/browse/CASSANDRA-16126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16126: --- Status: Patch Available (was: Open) > Blog post on Cassandra Usage Report 2020 > > > Key: CASSANDRA-16126 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16126 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Melissa Logan >Assignee: Melissa Logan >Priority: Normal > Fix For: 4.0-beta > > > Blog post on the 2020 Cassandra Usage Report. > ML: > [https://lists.apache.org/thread.html/r8a91b1d63079739c8dfbdab1833c66d58326de91a659afa3fb2a41a7%40%3Cdev.cassandra.apache.org%3E] > > PR: [https://github.com/apache/cassandra-website/pull/21] -- 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: ninja fix build, add jmxtool to rpm and deb packaging
This is an automated email from the ASF dual-hosted git repository.
marcuse 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 9a30167 ninja fix build, add jmxtool to rpm and deb packaging
9a30167 is described below
commit 9a30167909f8a9cb06e0f8bdf04f6e7562a91a0f
Author: Marcus Eriksson
AuthorDate: Wed Sep 16 12:28:54 2020 +0200
ninja fix build, add jmxtool to rpm and deb packaging
---
debian/cassandra.install | 1 +
redhat/cassandra.spec| 2 ++
2 files changed, 3 insertions(+)
diff --git a/debian/cassandra.install b/debian/cassandra.install
index be34838..8ffbe66 100644
--- a/debian/cassandra.install
+++ b/debian/cassandra.install
@@ -23,6 +23,7 @@ bin/sstableverify usr/bin
tools/bin/cassandra-stress usr/bin
tools/bin/fqltool usr/bin
tools/bin/auditlogviewer usr/bin
+tools/bin/jmxtool usr/bin
lib/*.jar usr/share/cassandra/lib
lib/*.zip usr/share/cassandra/lib
lib/sigar-bin/* usr/share/cassandra/lib/sigar-bin
diff --git a/redhat/cassandra.spec b/redhat/cassandra.spec
index f42ab83..cbc78aa 100644
--- a/redhat/cassandra.spec
+++ b/redhat/cassandra.spec
@@ -124,6 +124,7 @@ exit 0
%defattr(0644,root,root,0755)
%doc CHANGES.txt LICENSE.txt README.asc NEWS.txt NOTICE.txt CASSANDRA-14092.txt
%attr(755,root,root) %{_bindir}/auditlogviewer
+%attr(755,root,root) %{_bindir}/jmxtool
%attr(755,root,root) %{_bindir}/cassandra-stress
%attr(755,root,root) %{_bindir}/cqlsh
%attr(755,root,root) %{_bindir}/cqlsh.py
@@ -181,6 +182,7 @@ This package contains extra tools for working with
Cassandra clusters.
%attr(755,root,root) %{_bindir}/sstablerepairedset
%attr(755,root,root) %{_bindir}/sstablesplit
%attr(755,root,root) %{_bindir}/auditlogviewer
+%attr(755,root,root) %{_bindir}/jmxtool
%attr(755,root,root) %{_bindir}/fqltool
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15348) Harry: generator library and extensible framework for fuzz testing Apache Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-15348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196849#comment-17196849 ] Michael Semb Wever commented on CASSANDRA-15348: IP Clearance at https://incubator.apache.org/ip-clearance/apache-cassandra-harry.html > Harry: generator library and extensible framework for fuzz testing Apache > Cassandra > --- > > Key: CASSANDRA-15348 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15348 > Project: Cassandra > Issue Type: New Feature >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-beta > > > h2. Description: > This ticket introduces Harry, a component for fuzz testing and verification > of the Apache Cassandra clusters at scale. > h2. Motivation: > Current testing tooling largely tests for common- and edge-cases, and most of > the tests use predefined datasets. Property-based tests can help explore a > broader range of states, but often require either a complex model or a large > state to test against. > h2. What problems Harry solves: > Harry allows to run tests that are able to validate state of both dense nodes > (to test local read-write path) and large clusters (to test distributed > read-write path), and do it efficiently. Main goals, and what sets it apart > from the other testing tools is: > * The state required for verification should remain as compact as possible. > * The verification process itself should be as performant as possible. > * Ideally, we'd want a way to verify database state while _continuing_ > running state change queries against it. > h2. What Harry does: > To achieve this, Harry defines a model that holds the state of the database, > generators that produce reproducible, pseudo-random schemas, mutations, and > queries, and a validator that asserts the correctness of the model following > execution of generated traffic. > h2. Harry consists of multiple reusable components: > * Generator library: how to create a library of invertible, order-preserving > generators for simple and composite data types. > * Model and checker: how to use the properties of generators to validate the > output of an eventually-consistent database in a linear time. > * Runner library: how to create a scheme for reproducible runs, despite the > concurrent nature of database and fuzzer itself. > h2. Short and somewhat approximate description of how Harry achieves this: > Generation and validation define strict mathematical relations between the > generated values and pseudorandom numbers they were generated from. Using > these properties, we can store minimal state and check if these properties > hold during validation. > Since Cassandra stores data in rows, we should be able to "inflate" data to > insert a row into the database from a single number we call _descriptor_. > Each value in the row read from the database can be "deflated" back to the > descriptor it was generated from. This way, to precisely verify the state of > the row, we only need to know the descriptor it was generated from and a > timestamp at which it was inserted. > Similarly, keys for the inserted row can be "inflated" from a single 64-bit > integer, and then "deflated" back to it. To efficiently search for keys, > while allowing range scans, our generation scheme preserves the order of the > original 64-bit integer. Every pair of keys generated from two 64-bit > integers would sort the same way as these integers. > This way, in order to validate a state of the range of rows queried from the > database, it is sufficient to "deflate" its key and data values, use deflated > 64-bit key representation to find all descriptors these rows were generated > from, and ensure that the given sequence of descriptors could have resulted > in the state that database has responded with. > Using this scheme, we keep a minimum possible amount of data per row, can > efficiently generate the data, and backtrack values to the numbers they were > generated from. Most of the time, we operate on 64-bit integer values and > only use "inflated" objects when running queries against database state, > minimizing the amount of required memory. > h2. Name: > Harry (verb). > According to Marriam-Webster: > * to torment by or as if by constant attack > * persistently carry out attacks on (an enemy or an enemy's territory) -- 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-14975) cqlsh dtests are not running in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-14975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196830#comment-17196830 ] Berenguer Blasi commented on CASSANDRA-14975: - Hi, I have been working on fixing tests recently and [~mck] made me notice this ticket: - CASSANDRA-16121 should make cqlshlib tests run on circle. It appears to be working ok in the pre-commit CI test runs #collaborating #justfyi - When running CI I see both [circle|https://app.circleci.com/pipelines/github/bereng/cassandra/101/workflows/5056ddf5-693d-4b2e-b08d-983253eeed6e/jobs/817] and [ci-cass|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/16/label=cassandra,split=28/testReport/dtest.cqlsh_tests.test_cqlsh/] running cqlsh dtests. Also I took a look at the PR and the latest code in trunk and there seems to be many differences since. I am wondering if we should close this ticket as any issues it fixed have already been fixed elsewhere? > cqlsh dtests are not running in CircleCI > > > Key: CASSANDRA-14975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14975 > Project: Cassandra > Issue Type: Improvement > Components: CI, Test/dtest/python >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Labels: CI > Fix For: 3.0.x, 3.11.x, 4.x > > > Right now the dtests skip these tests because most don't pass. Originally > they weren't being collected because the test files end in_tests.py instead > of _test.py, but I fixed that by adding _tests.py to the list of recognized > patterns. > Get them all running in CircleCI. Nothing special they will be part of the > existing dtest jobs. -- 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-16067) Avoid invalid state transition exception during incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-16067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16067: Fix Version/s: 4.0-beta3 Since Version: 4.0-alpha1 Source Control Link: https://github.com/apache/cassandra/commit/da3806795fe7cf8412249a0fab9934e071a7511e Resolution: Fixed Status: Resolved (was: Ready to Commit) and committed, thanks > Avoid invalid state transition exception during incremental repair > -- > > Key: CASSANDRA-16067 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16067 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta3 > > > We currently throw an invalid state transition exception if we receive a > prepare response and the repair session has already completely failed. In > this case we should just ignore the response. -- 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: Avoid invalid state transition exception during incremental repair
This is an automated email from the ASF dual-hosted git repository.
marcuse 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 da38067 Avoid invalid state transition exception during incremental
repair
da38067 is described below
commit da3806795fe7cf8412249a0fab9934e071a7511e
Author: Marcus Eriksson
AuthorDate: Fri Aug 21 09:01:51 2020 +0200
Avoid invalid state transition exception during incremental repair
Patch by marcuse; reviewed by Blake Eggleston and Jon Meredith for
CASSANDRA-16067
---
CHANGES.txt | 1 +
.../org/apache/cassandra/repair/consistent/CoordinatorSession.java | 5 +
2 files changed, 6 insertions(+)
diff --git a/CHANGES.txt b/CHANGES.txt
index 3c4a810..a0041d8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-beta3
+ * Avoid invalid state transition exception during incremental repair
(CASSANDRA-16067)
* Allow zero padding in timestamp serialization (CASSANDRA-16105)
* Add byte array backed cells (CASSANDRA-15393)
* Correctly handle pending ranges with adjacent range movements
(CASSANDRA-14801)
diff --git
a/src/java/org/apache/cassandra/repair/consistent/CoordinatorSession.java
b/src/java/org/apache/cassandra/repair/consistent/CoordinatorSession.java
index 9d440c2..d60541e 100644
--- a/src/java/org/apache/cassandra/repair/consistent/CoordinatorSession.java
+++ b/src/java/org/apache/cassandra/repair/consistent/CoordinatorSession.java
@@ -162,6 +162,11 @@ public class CoordinatorSession extends ConsistentSession
public synchronized void handlePrepareResponse(InetAddressAndPort
participant, boolean success)
{
+if (getState() == State.FAILED)
+{
+logger.trace("Incremental repair {} has failed, ignoring prepare
response from {}", sessionID, participant);
+return;
+}
if (!success)
{
logger.warn("{} failed the prepare phase for incremental repair
session {}", participant, sessionID);
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14103) Fix potential race during compaction strategy reload
[
https://issues.apache.org/jira/browse/CASSANDRA-14103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14103:
Fix Version/s: 4.0-beta3
3.11.9
Source Control Link:
https://github.com/apache/cassandra/commit/f41ea9fb14936bca4aeea0ab2bf6d55c51f37f6a
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
and committed, test runs:
[3.11|https://app.circleci.com/pipelines/github/krummas/cassandra/515/workflows/49751fc1-ef03-45d2-883f-8e8a7c5298ff]
,
[trunk|https://app.circleci.com/pipelines/github/krummas/cassandra/509/workflows/a50f71ca-b117-4cbe-b059-60f09b3987fe]
> Fix potential race during compaction strategy reload
>
>
> Key: CASSANDRA-14103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14103
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Paulo Motta
>Assignee: Marcus Eriksson
>Priority: Urgent
> Fix For: 3.11.9, 4.0-beta3
>
> Attachments: 3.11-14103-dtest.png, 3.11-14103-testall.png,
> trunk-14103-dtest.png, trunk-14103-testall.png
>
>
> When the compaction strategies are reloaded after disk boundary changes
> (CASSANDRA-13948), it's possible that a recently finished SSTable is added
> twice to the compaction strategy: once when the compaction strategies are
> reloaded due to the disk boundary change ({{maybeReloadDiskBoundarie}}), and
> another when the {{CompactionStrategyManager}} is processing the
> {{SSTableAddedNotification}}.
> This should be quite unlikely because a compaction must finish as soon as the
> disk boundary changes, and even if it happens most compaction strategies
> would not be affected by it since they deduplicate sstables internally, but
> we should protect against such scenario.
> For more context see [this
> comment|https://issues.apache.org/jira/browse/CASSANDRA-13948?focusedCommentId=16280448=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16280448]
> from Marcus.
--
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-14826) cassandra spinning forever on 1 thread while initializing keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-14826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14826:
Resolution: Duplicate
Status: Resolved (was: Open)
a variation of this patch was committed in CASSANDRA-14103
> cassandra spinning forever on 1 thread while initializing keyspace
> --
>
> Key: CASSANDRA-14826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14826
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: ingard mevåg
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: Screen Shot 2018-10-16 at 14.51.27.png
>
>
> When starting cassandra 3.0.17 it takes a long time to initialize a keyspace.
> top shows 1 thread spinning at 100% cpu. Thread dump shows:
> {code:java}
> "main" - Thread t@1
> java.lang.Thread.State: RUNNABLE
> at java.util.TimSort.mergeHi(TimSort.java:850)
> at java.util.TimSort.mergeAt(TimSort.java:516)
> at java.util.TimSort.mergeCollapse(TimSort.java:441)
> at java.util.TimSort.sort(TimSort.java:245)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1454)
> at java.util.Collections.sort(Collections.java:175)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.canAddSSTable(LeveledManifest.java:243)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.add(LeveledManifest.java:146)
> - locked (a
> org.apache.cassandra.db.compaction.LeveledManifest)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:298)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:135)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:187)
> - locked <742bfce7> (a
> org.apache.cassandra.db.compaction.CompactionStrategyManager)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.(CompactionStrategyManager.java:75)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:408)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:363)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:579)
> - locked <4e4f20d2> (a java.lang.Class)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:556)
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> - locked <5318346c> (a java.lang.Class)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:262)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> {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
