[jira] [Updated] (CASSANDRA-16611) WEBSITE - Publish agenda on World Party landing page
[ https://issues.apache.org/jira/browse/CASSANDRA-16611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16611: -- Test and Documentation Plan: Preview updates in staging Status: Patch Available (was: In Progress) PR #51 submitted – https://github.com/apache/cassandra-website/pull/51 > WEBSITE - Publish agenda on World Party landing page > > > Key: CASSANDRA-16611 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16611 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Melissa Logan >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0 > > > To announce World Party speakers per C* dev Slack: > [https://the-asf.slack.com/archives/C01RY1LUPD5/p1618601199086500]. Please > have it go live on Monday, April 19. > From https://hopin.com/events/apache-cassandra-4-0-world-party: > h1. Agenda > Join us to hear from the following lineups at the following times: > h4. 5:00 - 6:00am UTC | Moderated by [Jeremy > Hanna|https://github.com/jeromatron] + [Erick > Ramirez|https://twitter.com/ErickRamirezAU] > * Introduction to Apache Cassandra™ 4.0 > * Downside of Incremental Repairs by Payal Kumari > * Apache Cassandra™ with Quarkus by Ravindra Kulkarni > * Cassandra: Now and For The Future by Nirmal KPS Singh > * Understanding Cassandra by Pradeep Gopal > * Fun and Games > h4. 1:00 - 2:00pm UTC | Moderated by [Ekaterina > Dimitrova|https://twitter.com/EkaterinaDimit9] + [Patrick > McFadin|https://github.com/pmcfadin] > * Introduction to Apache Cassandra™ 4.0 > * Cassandra Robustness: Errors I Made and You Cannot Anymore! by Carlos Rolo > * Raising the Bar on QAMick by Semb Wever > * Cassandra in Adobe Audience Manager by Serban Teodorescu > * 11 Years of Cassandra by John Schulz > * Fun and Games > h4. 9:00 - 10:00pm UTC | Moderated by [Melissa > Logan|https://twitter.com/Melissa_B2B] + [Ben > Bromhead|https://twitter.com/BenBromhead] > * Introduction to Apache Cassandra™ 4.0 > * How Apache Cassandra™ Skills Help Women on a Path to Reentry in Tech by > Autumn Capasso > * Making Cassandra Easy by Rahul Xavier Singh > * Optimizing Cassandra for Cloud Native Architecture by Subrata Ashe > * Moving from Elastic to Cassandra by Charles Herring -- 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-16611) WEBSITE - Publish agenda on World Party landing page
[ https://issues.apache.org/jira/browse/CASSANDRA-16611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16611: -- Description: To announce World Party speakers per C* dev Slack: [https://the-asf.slack.com/archives/C01RY1LUPD5/p1618601199086500]. Please have it go live on Monday, April 19. From https://hopin.com/events/apache-cassandra-4-0-world-party: h1. Agenda Join us to hear from the following lineups at the following times: h4. 5:00 - 6:00am UTC | Moderated by [Jeremy Hanna|https://github.com/jeromatron] + [Erick Ramirez|https://twitter.com/ErickRamirezAU] * Introduction to Apache Cassandra™ 4.0 * Downside of Incremental Repairs by Payal Kumari * Apache Cassandra™ with Quarkus by Ravindra Kulkarni * Cassandra: Now and For The Future by Nirmal KPS Singh * Understanding Cassandra by Pradeep Gopal * Fun and Games h4. 1:00 - 2:00pm UTC | Moderated by [Ekaterina Dimitrova|https://twitter.com/EkaterinaDimit9] + [Patrick McFadin|https://github.com/pmcfadin] * Introduction to Apache Cassandra™ 4.0 * Cassandra Robustness: Errors I Made and You Cannot Anymore! by Carlos Rolo * Raising the Bar on QAMick by Semb Wever * Cassandra in Adobe Audience Manager by Serban Teodorescu * 11 Years of Cassandra by John Schulz * Fun and Games h4. 9:00 - 10:00pm UTC | Moderated by [Melissa Logan|https://twitter.com/Melissa_B2B] + [Ben Bromhead|https://twitter.com/BenBromhead] * Introduction to Apache Cassandra™ 4.0 * How Apache Cassandra™ Skills Help Women on a Path to Reentry in Tech by Autumn Capasso * Making Cassandra Easy by Rahul Xavier Singh * Optimizing Cassandra for Cloud Native Architecture by Subrata Ashe * Moving from Elastic to Cassandra by Charles Herring was: To announce World Party speakers per C* dev Slack: [https://the-asf.slack.com/archives/C01RY1LUPD5/p1618601199086500] Please have it go live on Monday, April 19. > WEBSITE - Publish agenda on World Party landing page > > > Key: CASSANDRA-16611 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16611 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Melissa Logan >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0 > > > To announce World Party speakers per C* dev Slack: > [https://the-asf.slack.com/archives/C01RY1LUPD5/p1618601199086500]. Please > have it go live on Monday, April 19. > From https://hopin.com/events/apache-cassandra-4-0-world-party: > h1. Agenda > Join us to hear from the following lineups at the following times: > h4. 5:00 - 6:00am UTC | Moderated by [Jeremy > Hanna|https://github.com/jeromatron] + [Erick > Ramirez|https://twitter.com/ErickRamirezAU] > * Introduction to Apache Cassandra™ 4.0 > * Downside of Incremental Repairs by Payal Kumari > * Apache Cassandra™ with Quarkus by Ravindra Kulkarni > * Cassandra: Now and For The Future by Nirmal KPS Singh > * Understanding Cassandra by Pradeep Gopal > * Fun and Games > h4. 1:00 - 2:00pm UTC | Moderated by [Ekaterina > Dimitrova|https://twitter.com/EkaterinaDimit9] + [Patrick > McFadin|https://github.com/pmcfadin] > * Introduction to Apache Cassandra™ 4.0 > * Cassandra Robustness: Errors I Made and You Cannot Anymore! by Carlos Rolo > * Raising the Bar on QAMick by Semb Wever > * Cassandra in Adobe Audience Manager by Serban Teodorescu > * 11 Years of Cassandra by John Schulz > * Fun and Games > h4. 9:00 - 10:00pm UTC | Moderated by [Melissa > Logan|https://twitter.com/Melissa_B2B] + [Ben > Bromhead|https://twitter.com/BenBromhead] > * Introduction to Apache Cassandra™ 4.0 > * How Apache Cassandra™ Skills Help Women on a Path to Reentry in Tech by > Autumn Capasso > * Making Cassandra Easy by Rahul Xavier Singh > * Optimizing Cassandra for Cloud Native Architecture by Subrata Ashe > * Moving from Elastic to Cassandra by Charles Herring -- 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-16611) WEBSITE - Publish agenda on World Party landing page
[ https://issues.apache.org/jira/browse/CASSANDRA-16611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-16611: --- Labels: pull-request-available (was: ) > WEBSITE - Publish agenda on World Party landing page > > > Key: CASSANDRA-16611 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16611 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Melissa Logan >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0 > > > To announce World Party speakers per C* dev Slack: > [https://the-asf.slack.com/archives/C01RY1LUPD5/p1618601199086500] > Please have it go live on Monday, April 19. -- 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-16611) WEBSITE - Publish agenda on World Party landing page
[ https://issues.apache.org/jira/browse/CASSANDRA-16611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16611: -- Summary: WEBSITE - Publish agenda on World Party landing page (was: BLOG - World Party Speakers) > WEBSITE - Publish agenda on World Party landing page > > > Key: CASSANDRA-16611 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16611 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Melissa Logan >Assignee: Erick Ramirez >Priority: Normal > Fix For: 4.0 > > > To announce World Party speakers per C* dev Slack: > [https://the-asf.slack.com/archives/C01RY1LUPD5/p1618601199086500] > Please have it go live on Monday, April 19. -- 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-16603) Sporadic CQL operation timeout due to unconfigured table
[
https://issues.apache.org/jira/browse/CASSANDRA-16603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324172#comment-17324172
]
Haoze Wu commented on CASSANDRA-16603:
--
I see. Injecting a shorter delay would also cause the symptom; we used the
15 minutes just for demo purpose, and >15 minutes delay has been observed in
some real production incident, e.g., ZOOKEEPER-2201.
I'm not saying that this issue that I propose is definitely a bug. It
could be a feature. I'm just curious because this injection not only makes its
own thread stuck, but also affects another thread, according to the jstack I
provided.
From our experience, this kind of injection generally only affects one
thread, and can be tolerated by the system itself, transparent to the client.
Therefore, it reminds me of ZOOKEEPER-2201.
ZOOKEEPER-2201 can be reproduced with a similar injection like this issue, and
it is accepted as a bug by developers because it not only makes its own thread
stuck, but also affects some other services that it shouldn't affect.
The injection in this issue is not an "artificial" scenario, because the
I/O can be particularly susceptible to slowness in a VM (like KAFKA-3042) where
a disk I/O operation may need to go through the network (hang for >15min like
ZOOKEEPER-2201). Therefore, it may be a real scenario in real world. The
question here is perhaps whether the system should be affected for as long as
the potentially long delay in commit log add, or there should be some tolerance
like timeout.
We have been analyzing the workflow for a while, and haven't got a final
conclusion. Specifically, after the injection happens, we are still not clear
why we have:
{code:java}
"MigrationStage:1" #69 daemon prio=5 os_prio=0 tid=0x7f857c6d1b20
nid=0x6ecd waiting on condition [0x7f8568cef000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0005e5e7abd8> (a
com.google.common.util.concurrent.ListenableFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:438)
at
org.apache.cassandra.schema.SchemaKeyspace.lambda$flush$1(SchemaKeyspace.java:310)
at
org.apache.cassandra.schema.SchemaKeyspace$$Lambda$263/1985363058.accept(Unknown
Source)
at java.lang.Iterable.forEach(Iterable.java:75)
at org.apache.cassandra.schema.SchemaKeyspace.flush(SchemaKeyspace.java:310)
at
org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1398)
- locked <0x000611bd39e0> (a java.lang.Class for
org.apache.cassandra.schema.SchemaKeyspace)
at
org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1380)
- locked <0x000611bd39e0> (a java.lang.Class for
org.apache.cassandra.schema.SchemaKeyspace)
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:51)
at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
at
org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$6/1239807799.run(Unknown
Source)
at java.lang.Thread.run(Thread.java:748)
{code}
> Sporadic CQL operation timeout due to unconfigured table
>
>
> Key: CASSANDRA-16603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16603
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Haoze Wu
>Priority: Normal
>
> We were doing some systematic testing in Cassandra stable release 3.11.10
> and found the disk I/O delay may cause some issues.
> We start a Cassandra cluster of 3 nodes with the default configuration,
> in node 1, we open the cqlsh shell and type in:
> {code:java}
> create keyspace ycsb WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor': 3 };
> USE ycsb;
> create table usertable (
> y_id varchar primary key,
> field0 varchar,
> field1 varchar,
> field2 varchar,
> field3 varchar,
> field4 varchar,
> field5 varchar,
> field6 varchar,
> field7 varchar,
> field8 varchar,
> field9 varchar);
> {code}
>
[jira] [Created] (CASSANDRA-16612) RingTest has inconsistent assertion
Jacek Lewandowski created CASSANDRA-16612:
-
Summary: RingTest has inconsistent assertion
Key: CASSANDRA-16612
URL: https://issues.apache.org/jira/browse/CASSANDRA-16612
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Jacek Lewandowski
Assignee: Jacek Lewandowski
There is an assertion for the node current load like:
{noformat}
assertThat(hostRing, matchesPattern(".*\\d+\\.\\d+ KiB.*"));
{noformat}
while we are formatting that value with {{#.##}}. Therefore if we say have 46
KiB, it will be formatted as 46 KiB rather than 46.00 KiB which is expected by
the test. We need to either change this assertion or change the format string
to {{#0.00}}
--
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-16586) Fix flaky test testAvailabilityV30ToV4 - org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
[
https://issues.apache.org/jira/browse/CASSANDRA-16586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16586:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Ekaterina Dimitrova, Ekaterina Dimitrova
Status: Review In Progress (was: Patch Available)
> Fix flaky test testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> --
>
> Key: CASSANDRA-16586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16586
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/881/workflows/8e477260-ac6a-4eab-b4be-cbc048199565/jobs/5269
> testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> {code}
> junit.framework.AssertionFailedError: Unexpected error in case QUORUM-QUORUM
> with not upgraded coordinator and 1 nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:127)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:79)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:186)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:81)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:53)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailabilityV30ToV4(MixedModeAvailabilityV30Test.java:39)
> Caused by: java.lang.RuntimeException:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 1 responses.
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$5(IsolatedExecutor.java:109)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeWithResult(Coordinator.java:69)
> at
> org.apache.cassandra.distributed.api.ICoordinator.execute(ICoordinator.java:32)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.lambda$test$1(MixedModeAvailabilityTestBase.java:120)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:139)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:119)
> Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
> timed out - received only 1 responses.
> at
> org.apache.cassandra.service.ReadCallback.awaitResults(ReadCallback.java:136)
> at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:142)
> at
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
> at
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1831)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1780)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1718)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1627)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1162)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:302)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:263)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:115)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeInternal(Coordinator.java:107)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:69)
> 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
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at
[jira] [Updated] (CASSANDRA-16611) BLOG - World Party Speakers
[ https://issues.apache.org/jira/browse/CASSANDRA-16611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16611: -- Change Category: Semantic Complexity: Normal Fix Version/s: 4.0 Status: Open (was: Triage Needed) > BLOG - World Party Speakers > --- > > Key: CASSANDRA-16611 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16611 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Melissa Logan >Assignee: Erick Ramirez >Priority: Normal > Fix For: 4.0 > > > To announce World Party speakers per C* dev Slack: > [https://the-asf.slack.com/archives/C01RY1LUPD5/p1618601199086500] > Please have it go live on Monday, April 19. -- 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-16611) BLOG - World Party Speakers
[ https://issues.apache.org/jira/browse/CASSANDRA-16611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez reassigned CASSANDRA-16611: - Assignee: Erick Ramirez > BLOG - World Party Speakers > --- > > Key: CASSANDRA-16611 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16611 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Melissa Logan >Assignee: Erick Ramirez >Priority: Normal > > To announce World Party speakers per C* dev Slack: > [https://the-asf.slack.com/archives/C01RY1LUPD5/p1618601199086500] > Please have it go live on Monday, April 19. -- 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-16611) BLOG - World Party Speakers
Melissa Logan created CASSANDRA-16611: - Summary: BLOG - World Party Speakers Key: CASSANDRA-16611 URL: https://issues.apache.org/jira/browse/CASSANDRA-16611 Project: Cassandra Issue Type: Task Components: Documentation/Blog Reporter: Melissa Logan To announce World Party speakers per C* dev Slack: [https://the-asf.slack.com/archives/C01RY1LUPD5/p1618601199086500] Please have it go live on Monday, April 19. -- 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-16610) Implement XXHashPartitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-16610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324080#comment-17324080
]
Stefan Miklosovic edited comment on CASSANDRA-16610 at 4/16/21, 9:01 PM:
-
[~brandon.williams] Fair enough, I just had this urge to code this up to see
the numbers in action on my own and I wanted to share it so maybe somebody will
be willing to do this too or sometimes in the future there will be some taste
to take it in but your point makes total sense too as I think about it, yeah ...
edit: but for new deployments ... why not? nobody is going to migrate a cluster
just because of this but when they start from scratch ...
was (Author: stefan.miklosovic):
[~brandon.williams] Fair enough, I just had this urge to code this up to see
the numbers in action on my own and I wanted to share it so maybe somebody will
be willing to do this too or sometimes in the future there will be some taste
to take it in but your point makes total sense too as I think about it, yeah ...
> Implement XXHashPartitioner
> ---
>
> Key: CASSANDRA-16610
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16610
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Priority: Normal
> Attachments: jmh-result.json
>
>
> I implemented partitioner based on XXHash algorithm.
> There are two branches, the first xxhash, extracts common parts with Murmur
> as there is a lot of overlap between these two.
> The second branch just copies everything from Murmur and changes just bits
> which are necessary.
> I am not sure what path we want to go with so I just provided both to easier
> elaborate on.
> I have written a microbenchmark measuring both partitioners and XXHash
> implementation is very fast, around 10x faster (on greater payloads).
> Benchmark is included in xxhash-2 branch.
> https://github.com/instaclustr/cassandra/tree/xxhash-2
> https://github.com/instaclustr/cassandra/tree/xxhash
> {code:java}
> [java] Benchmark (bufferSize) Mode Cnt
> Score Error Units
> [java] PartitionersBench.benchMurmur3Partitioner31 avgt 20
> 157.942 ± 0.110 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner67 avgt 20
> 204.670 ± 0.152 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 131 avgt 20
> 361.068 ± 0.228 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 517 avgt 20
> 1325.670 ± 1.255 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 1031 avgt 20
> 2594.651 ± 2.725 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 2041 avgt 20
> 5082.166 ± 1.721 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 4097 avgt 20
> 10112.020 ± 3.637 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 31 avgt 20
> 40.650 ± 0.025 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 67 avgt 20
> 53.305 ± 0.035 ns/op
> [java] PartitionersBench.benchXXHashPartitioner131 avgt 20
> 67.098 ± 0.057 ns/op
> [java] PartitionersBench.benchXXHashPartitioner517 avgt 20
> 150.415 ± 0.107 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 1031 avgt 20
> 265.614 ± 0.140 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 2041 avgt 20
> 365.796 ± 0.225 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 4097 avgt 20
> 925.841 ± 0.664 ns/op
> {code}
> {code:java}
> [java] PartitionersBench.benchMurmur3Partitioner 3 avgt5
> 44.516 ± 0.345 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 5 avgt5
> 54.930 ± 0.450 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 7 avgt5
> 63.428 ± 0.266 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 9 avgt5
> 69.456 ± 0.467 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner11 avgt5
> 81.411 ± 0.535 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner16 avgt5
> 68.621 ± 0.417 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 3 avgt5
> 26.820 ± 0.271 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 5 avgt5
> 28.182 ± 0.139 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 7 avgt5
> 31.557 ± 0.161 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 9 avgt5
> 31.017 ± 0.212 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 11 avgt5
> 33.233 ± 0.136 ns/op
> [java] PartitionersBench.benchXXHashPartitioner
[jira] [Commented] (CASSANDRA-16610) Implement XXHashPartitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-16610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324080#comment-17324080
]
Stefan Miklosovic commented on CASSANDRA-16610:
---
[~brandon.williams] Fair enough, I just had this urge to code this up to see
the numbers in action on my own and I wanted to share it so maybe somebody will
be willing to do this too or sometimes in the future there will be some taste
to take it in but your point makes total sense too as I think about it, yeah ...
> Implement XXHashPartitioner
> ---
>
> Key: CASSANDRA-16610
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16610
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Priority: Normal
> Attachments: jmh-result.json
>
>
> I implemented partitioner based on XXHash algorithm.
> There are two branches, the first xxhash, extracts common parts with Murmur
> as there is a lot of overlap between these two.
> The second branch just copies everything from Murmur and changes just bits
> which are necessary.
> I am not sure what path we want to go with so I just provided both to easier
> elaborate on.
> I have written a microbenchmark measuring both partitioners and XXHash
> implementation is very fast, around 10x faster (on greater payloads).
> Benchmark is included in xxhash-2 branch.
> https://github.com/instaclustr/cassandra/tree/xxhash-2
> https://github.com/instaclustr/cassandra/tree/xxhash
> {code:java}
> [java] Benchmark (bufferSize) Mode Cnt
> Score Error Units
> [java] PartitionersBench.benchMurmur3Partitioner31 avgt 20
> 157.942 ± 0.110 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner67 avgt 20
> 204.670 ± 0.152 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 131 avgt 20
> 361.068 ± 0.228 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 517 avgt 20
> 1325.670 ± 1.255 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 1031 avgt 20
> 2594.651 ± 2.725 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 2041 avgt 20
> 5082.166 ± 1.721 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 4097 avgt 20
> 10112.020 ± 3.637 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 31 avgt 20
> 40.650 ± 0.025 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 67 avgt 20
> 53.305 ± 0.035 ns/op
> [java] PartitionersBench.benchXXHashPartitioner131 avgt 20
> 67.098 ± 0.057 ns/op
> [java] PartitionersBench.benchXXHashPartitioner517 avgt 20
> 150.415 ± 0.107 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 1031 avgt 20
> 265.614 ± 0.140 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 2041 avgt 20
> 365.796 ± 0.225 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 4097 avgt 20
> 925.841 ± 0.664 ns/op
> {code}
> {code:java}
> [java] PartitionersBench.benchMurmur3Partitioner 3 avgt5
> 44.516 ± 0.345 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 5 avgt5
> 54.930 ± 0.450 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 7 avgt5
> 63.428 ± 0.266 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 9 avgt5
> 69.456 ± 0.467 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner11 avgt5
> 81.411 ± 0.535 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner16 avgt5
> 68.621 ± 0.417 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 3 avgt5
> 26.820 ± 0.271 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 5 avgt5
> 28.182 ± 0.139 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 7 avgt5
> 31.557 ± 0.161 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 9 avgt5
> 31.017 ± 0.212 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 11 avgt5
> 33.233 ± 0.136 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 16 avgt5
> 31.386 ± 0.128 ns/op
> {code}
> https://github.com/OpenHFT/Zero-Allocation-Hashing
> https://cyan4973.github.io/xxHash/
--
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-16610) Implement XXHashPartitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-16610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16610:
--
Description:
I implemented partitioner based on XXHash algorithm.
There are two branches, the first xxhash, extracts common parts with Murmur as
there is a lot of overlap between these two.
The second branch just copies everything from Murmur and changes just bits
which are necessary.
I am not sure what path we want to go with so I just provided both to easier
elaborate on.
I have written a microbenchmark measuring both partitioners and XXHash
implementation is very fast, around 10x faster (on greater payloads). Benchmark
is included in xxhash-2 branch.
https://github.com/instaclustr/cassandra/tree/xxhash-2
https://github.com/instaclustr/cassandra/tree/xxhash
{code:java}
[java] Benchmark (bufferSize) Mode Cnt
Score Error Units
[java] PartitionersBench.benchMurmur3Partitioner31 avgt 20
157.942 ± 0.110 ns/op
[java] PartitionersBench.benchMurmur3Partitioner67 avgt 20
204.670 ± 0.152 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 131 avgt 20
361.068 ± 0.228 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 517 avgt 20
1325.670 ± 1.255 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 1031 avgt 20
2594.651 ± 2.725 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 2041 avgt 20
5082.166 ± 1.721 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 4097 avgt 20
10112.020 ± 3.637 ns/op
[java] PartitionersBench.benchXXHashPartitioner 31 avgt 20
40.650 ± 0.025 ns/op
[java] PartitionersBench.benchXXHashPartitioner 67 avgt 20
53.305 ± 0.035 ns/op
[java] PartitionersBench.benchXXHashPartitioner131 avgt 20
67.098 ± 0.057 ns/op
[java] PartitionersBench.benchXXHashPartitioner517 avgt 20
150.415 ± 0.107 ns/op
[java] PartitionersBench.benchXXHashPartitioner 1031 avgt 20
265.614 ± 0.140 ns/op
[java] PartitionersBench.benchXXHashPartitioner 2041 avgt 20
365.796 ± 0.225 ns/op
[java] PartitionersBench.benchXXHashPartitioner 4097 avgt 20
925.841 ± 0.664 ns/op
{code}
{code:java}
[java] PartitionersBench.benchMurmur3Partitioner 3 avgt5
44.516 ± 0.345 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 5 avgt5
54.930 ± 0.450 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 7 avgt5
63.428 ± 0.266 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 9 avgt5
69.456 ± 0.467 ns/op
[java] PartitionersBench.benchMurmur3Partitioner11 avgt5
81.411 ± 0.535 ns/op
[java] PartitionersBench.benchMurmur3Partitioner16 avgt5
68.621 ± 0.417 ns/op
[java] PartitionersBench.benchXXHashPartitioner 3 avgt5
26.820 ± 0.271 ns/op
[java] PartitionersBench.benchXXHashPartitioner 5 avgt5
28.182 ± 0.139 ns/op
[java] PartitionersBench.benchXXHashPartitioner 7 avgt5
31.557 ± 0.161 ns/op
[java] PartitionersBench.benchXXHashPartitioner 9 avgt5
31.017 ± 0.212 ns/op
[java] PartitionersBench.benchXXHashPartitioner 11 avgt5
33.233 ± 0.136 ns/op
[java] PartitionersBench.benchXXHashPartitioner 16 avgt5
31.386 ± 0.128 ns/op
{code}
https://github.com/OpenHFT/Zero-Allocation-Hashing
https://cyan4973.github.io/xxHash/
was:
I implemented partitioner based on XXHash algorithm.
There are two branches, the first xxhash, extracts common parts with Murmur as
there is a lot of overlap between these two.
The second branch just copies everything from Murmur and changes just bits
which are necessary.
I am not sure what path we want to go with so I just provided both to easier
elaborate on.
I have written a microbenchmark measuring both partitioners and XXHash
implementation is very fast, around 10x faster (on greater payloads). Benchmark
is included in xxhash-2 branch.
https://github.com/instaclustr/cassandra/tree/xxhash-2
https://github.com/instaclustr/cassandra/tree/xxhash
{code:java}
[java] Benchmark (bufferSize) Mode Cnt
Score Error Units
[java] PartitionersBench.benchMurmur3Partitioner31 avgt 20
157.942 ± 0.110 ns/op
[java] PartitionersBench.benchMurmur3Partitioner67 avgt 20
204.670 ± 0.152 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 131 avgt 20
361.068 ± 0.228 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 517 avgt 20
1325.670 ± 1.255 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 1031 avgt 20
[jira] [Updated] (CASSANDRA-16610) Implement XXHashPartitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-16610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16610:
--
Description:
I implemented partitioner based on XXHash algorithm.
There are two branches, the first xxhash, extracts common parts with Murmur as
there is a lot of overlap between these two.
The second branch just copies everything from Murmur and changes just bits
which are necessary.
I am not sure what path we want to go with so I just provided both to easier
elaborate on.
I have written a microbenchmark measuring both partitioners and XXHash
implementation is very fast, around 10x faster (on greater payloads). Benchmark
is included in xxhash-2 branch.
https://github.com/instaclustr/cassandra/tree/xxhash-2
https://github.com/instaclustr/cassandra/tree/xxhash
{code:java}
[java] Benchmark (bufferSize) Mode Cnt
Score Error Units
[java] PartitionersBench.benchMurmur3Partitioner31 avgt 20
157.942 ± 0.110 ns/op
[java] PartitionersBench.benchMurmur3Partitioner67 avgt 20
204.670 ± 0.152 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 131 avgt 20
361.068 ± 0.228 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 517 avgt 20
1325.670 ± 1.255 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 1031 avgt 20
2594.651 ± 2.725 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 2041 avgt 20
5082.166 ± 1.721 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 4097 avgt 20
10112.020 ± 3.637 ns/op
[java] PartitionersBench.benchXXHashPartitioner 31 avgt 20
40.650 ± 0.025 ns/op
[java] PartitionersBench.benchXXHashPartitioner 67 avgt 20
53.305 ± 0.035 ns/op
[java] PartitionersBench.benchXXHashPartitioner131 avgt 20
67.098 ± 0.057 ns/op
[java] PartitionersBench.benchXXHashPartitioner517 avgt 20
150.415 ± 0.107 ns/op
[java] PartitionersBench.benchXXHashPartitioner 1031 avgt 20
265.614 ± 0.140 ns/op
[java] PartitionersBench.benchXXHashPartitioner 2041 avgt 20
365.796 ± 0.225 ns/op
[java] PartitionersBench.benchXXHashPartitioner 4097 avgt 20
925.841 ± 0.664 ns/op
{code}
https://github.com/OpenHFT/Zero-Allocation-Hashing
https://cyan4973.github.io/xxHash/
was:
I implemented partitioner based on XXHash algorithm.
There are two branches, the first xxhash, extracts common parts with Murmur as
there is a lot of overlap between these two.
The second branch just copies everything from Murmur and changes just bits
which are necessary.
I am not sure what path we want to go with so I just provided both to easier
elaborate on.
I have written a microbenchmark measuring both partitioners and XXHash
implementation is very fast, around 10x faster. Benchmark is included in
xxhash-2 branch.
https://github.com/instaclustr/cassandra/tree/xxhash-2
https://github.com/instaclustr/cassandra/tree/xxhash
{code:java}
[java] Benchmark (bufferSize) Mode Cnt
Score Error Units
[java] PartitionersBench.benchMurmur3Partitioner31 avgt 20
157.942 ± 0.110 ns/op
[java] PartitionersBench.benchMurmur3Partitioner67 avgt 20
204.670 ± 0.152 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 131 avgt 20
361.068 ± 0.228 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 517 avgt 20
1325.670 ± 1.255 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 1031 avgt 20
2594.651 ± 2.725 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 2041 avgt 20
5082.166 ± 1.721 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 4097 avgt 20
10112.020 ± 3.637 ns/op
[java] PartitionersBench.benchXXHashPartitioner 31 avgt 20
40.650 ± 0.025 ns/op
[java] PartitionersBench.benchXXHashPartitioner 67 avgt 20
53.305 ± 0.035 ns/op
[java] PartitionersBench.benchXXHashPartitioner131 avgt 20
67.098 ± 0.057 ns/op
[java] PartitionersBench.benchXXHashPartitioner517 avgt 20
150.415 ± 0.107 ns/op
[java] PartitionersBench.benchXXHashPartitioner 1031 avgt 20
265.614 ± 0.140 ns/op
[java] PartitionersBench.benchXXHashPartitioner 2041 avgt 20
365.796 ± 0.225 ns/op
[java] PartitionersBench.benchXXHashPartitioner 4097 avgt 20
925.841 ± 0.664 ns/op
{code}
https://github.com/OpenHFT/Zero-Allocation-Hashing
https://cyan4973.github.io/xxHash/
> Implement XXHashPartitioner
> ---
>
> Key: CASSANDRA-16610
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16610
>
[jira] [Commented] (CASSANDRA-16610) Implement XXHashPartitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-16610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324070#comment-17324070
]
Brandon Williams commented on CASSANDRA-16610:
--
As many times as we have lamented telling people there's no point in redoing
their entire cluster to switch for M3's gains, and given that those gains are
basically nonexistent as they are not visible outside of microbenchmarks since
the partitioner is generally not called often enough in any path to matter, I'm
not sure we should do this, even if we can.
/cc [~jjirsa]
> Implement XXHashPartitioner
> ---
>
> Key: CASSANDRA-16610
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16610
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Priority: Normal
> Attachments: jmh-result.json
>
>
> I implemented partitioner based on XXHash algorithm.
> There are two branches, the first xxhash, extracts common parts with Murmur
> as there is a lot of overlap between these two.
> The second branch just copies everything from Murmur and changes just bits
> which are necessary.
> I am not sure what path we want to go with so I just provided both to easier
> elaborate on.
> I have written a microbenchmark measuring both partitioners and XXHash
> implementation is very fast, around 10x faster. Benchmark is included in
> xxhash-2 branch.
> https://github.com/instaclustr/cassandra/tree/xxhash-2
> https://github.com/instaclustr/cassandra/tree/xxhash
> {code:java}
> [java] Benchmark (bufferSize) Mode Cnt
> Score Error Units
> [java] PartitionersBench.benchMurmur3Partitioner31 avgt 20
> 157.942 ± 0.110 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner67 avgt 20
> 204.670 ± 0.152 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 131 avgt 20
> 361.068 ± 0.228 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 517 avgt 20
> 1325.670 ± 1.255 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 1031 avgt 20
> 2594.651 ± 2.725 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 2041 avgt 20
> 5082.166 ± 1.721 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 4097 avgt 20
> 10112.020 ± 3.637 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 31 avgt 20
> 40.650 ± 0.025 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 67 avgt 20
> 53.305 ± 0.035 ns/op
> [java] PartitionersBench.benchXXHashPartitioner131 avgt 20
> 67.098 ± 0.057 ns/op
> [java] PartitionersBench.benchXXHashPartitioner517 avgt 20
> 150.415 ± 0.107 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 1031 avgt 20
> 265.614 ± 0.140 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 2041 avgt 20
> 365.796 ± 0.225 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 4097 avgt 20
> 925.841 ± 0.664 ns/op
> {code}
> https://github.com/OpenHFT/Zero-Allocation-Hashing
> https://cyan4973.github.io/xxHash/
--
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-13191) test failure in org.apache.cassandra.hints.HintsBufferPoolTest.testBackpressure
[
https://issues.apache.org/jira/browse/CASSANDRA-13191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-13191:
--
Resolution: Fixed
Status: Resolved (was: Open)
Fixed by CASSANDRA-16595, which merged yesterday.
> test failure in
> org.apache.cassandra.hints.HintsBufferPoolTest.testBackpressure
> ---
>
> Key: CASSANDRA-13191
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13191
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Testing, Test/unit
>Reporter: Michael Shuler
>Priority: Normal
> Labels: test-failure
> Fix For: 4.0-rc
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_testall/1392/testReport/org.apache.cassandra.hints/HintsBufferPoolTest/testBackpressure
> {noformat}
> Error Message
> Connection reset
> Stacktrace
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:209)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> at
> org.jboss.byteman.agent.submit.Submit$Comm.readResponse(Submit.java:941)
> at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:790)
> at org.jboss.byteman.agent.submit.Submit.addScripts(Submit.java:603)
> at
> org.jboss.byteman.contrib.bmunit.BMUnit.loadScriptText(BMUnit.java:268)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$10.evaluate(BMUnitRunner.java:369)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75)
> Standard Output
> ERROR [main] 2017-02-07 11:03:07,465 ?:? - SLF4J: stderr
> INFO [main] 2017-02-07 11:03:07,650 ?:? - Configuration location:
> file:/home/automaton/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2017-02-07 11:03:07,651 ?:? - Loading settings from
> file:/home/automaton/cassandra/test/conf/cassandra.yaml
> INFO [main] 2017-02-07 11:03:08,225 ?:? - Node
> configuration:[allocate_tokens_for_keyspace=null; authenticator=null;
> authorizer=null; auto_bootstrap=true; auto_snapshot=true;
> back_pressure_enabled=false; back_pressure_strategy=null;
> batch_size_fail_threshold_in_kb=50; batch_size_warn_threshold_in_kb=5;
> batchlog_replay_throttle_in_kb=1024; broadcast_address=null;
> broadcast_rpc_address=null; buffer_pool_use_heap_if_exhausted=true;
> cas_contention_timeout_in_ms=1000; cdc_enabled=false;
> cdc_free_space_check_interval_ms=250;
> cdc_raw_directory=build/test/cassandra/cdc_raw:222; cdc_total_space_in_mb=0;
> client_encryption_options=; cluster_name=Test Cluster;
> column_index_cache_size_in_kb=2; column_index_size_in_kb=4;
> commit_failure_policy=stop; commitlog_compression=null;
> commitlog_directory=build/test/cassandra/commitlog:222;
> commitlog_max_compression_buffers_in_pool=3;
> commitlog_periodic_queue_size=-1; commitlog_segment_size_in_mb=5;
> commitlog_sync=batch; commitlog_sync_batch_window_in_ms=1.0;
> commitlog_sync_period_in_ms=0; commitlog_total_space_in_mb=null;
> compaction_large_partition_warning_threshold_mb=100;
> compaction_throughput_mb_per_sec=0; concurrent_compactors=4;
> concurrent_counter_writes=32; concurrent_materialized_view_writes=32;
> concurrent_reads=32; concurrent_replicates=null; concurrent_writes=32;
> counter_cache_keys_to_save=2147483647; counter_cache_save_period=7200;
> counter_cache_size_in_mb=null; counter_write_request_timeout_in_ms=5000;
> credentials_cache_max_entries=1000; credentials_update_interval_in_ms=-1;
> credentials_validity_in_ms=2000; cross_node_timeout=false;
> data_file_directories=[Ljava.lang.String;@e7edb54; disk_access_mode=mmap;
> disk_failure_policy=ignore; disk_optimization_estimate_percentile=0.95;
> disk_optimization_page_cross_chance=0.1; disk_optimization_strategy=ssd;
> dynamic_snitch=true; dynamic_snitch_badness_threshold=0.1;
> dynamic_snitch_reset_interval_in_ms=60;
> dynamic_snitch_update_interval_in_ms=100;
> enable_scripted_user_defined_functions=true;
> enable_user_defined_functions=true;
> enable_user_defined_functions_threads=true; encryption_options=null;
> endpoint_snitch=org.apache.cassandra.locator.SimpleSnitch;
> file_cache_size_in_mb=null;
[jira] [Updated] (CASSANDRA-16610) Implement XXHashPartitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-16610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16610:
--
Attachment: jmh-result.json
> Implement XXHashPartitioner
> ---
>
> Key: CASSANDRA-16610
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16610
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Priority: Normal
> Attachments: jmh-result.json
>
>
> I implemented partitioner based on XXHash algorithm.
> There are two branches, the first xxhash, extracts common parts with Murmur
> as there is a lot of overlap between these two.
> The second branch just copies everything from Murmur and changes just bits
> which are necessary.
> I am not sure what path we want to go with so I just provided both to easier
> elaborate on.
> I have written a microbenchmark measuring both partitioners and XXHash
> implementation is very fast, around 10x faster. Benchmark is included in
> xxhash-2 branch.
> https://github.com/instaclustr/cassandra/tree/xxhash-2
> https://github.com/instaclustr/cassandra/tree/xxhash
> {code:java}
> [java] Benchmark (bufferSize) Mode Cnt
> Score Error Units
> [java] PartitionersBench.benchMurmur3Partitioner31 avgt 20
> 157.942 ± 0.110 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner67 avgt 20
> 204.670 ± 0.152 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 131 avgt 20
> 361.068 ± 0.228 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 517 avgt 20
> 1325.670 ± 1.255 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 1031 avgt 20
> 2594.651 ± 2.725 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 2041 avgt 20
> 5082.166 ± 1.721 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 4097 avgt 20
> 10112.020 ± 3.637 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 31 avgt 20
> 40.650 ± 0.025 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 67 avgt 20
> 53.305 ± 0.035 ns/op
> [java] PartitionersBench.benchXXHashPartitioner131 avgt 20
> 67.098 ± 0.057 ns/op
> [java] PartitionersBench.benchXXHashPartitioner517 avgt 20
> 150.415 ± 0.107 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 1031 avgt 20
> 265.614 ± 0.140 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 2041 avgt 20
> 365.796 ± 0.225 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 4097 avgt 20
> 925.841 ± 0.664 ns/op
> {code}
> https://github.com/OpenHFT/Zero-Allocation-Hashing
> https://cyan4973.github.io/xxHash/
--
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-16610) Implement XXHashPartitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-16610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16610:
--
Description:
I implemented partitioner based on XXHash algorithm.
There are two branches, the first xxhash, extracts common parts with Murmur as
there is a lot of overlap between these two.
The second branch just copies everything from Murmur and changes just bits
which are necessary.
I am not sure what path we want to go with so I just provided both to easier
elaborate on.
I have written a microbenchmark measuring both partitioners and XXHash
implementation is very fast, around 10x faster. Benchmark is included in
xxhash-2 branch.
https://github.com/instaclustr/cassandra/tree/xxhash-2
https://github.com/instaclustr/cassandra/tree/xxhash
{code:java}
[java] Benchmark (bufferSize) Mode Cnt
Score Error Units
[java] PartitionersBench.benchMurmur3Partitioner31 avgt 20
157.942 ± 0.110 ns/op
[java] PartitionersBench.benchMurmur3Partitioner67 avgt 20
204.670 ± 0.152 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 131 avgt 20
361.068 ± 0.228 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 517 avgt 20
1325.670 ± 1.255 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 1031 avgt 20
2594.651 ± 2.725 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 2041 avgt 20
5082.166 ± 1.721 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 4097 avgt 20
10112.020 ± 3.637 ns/op
[java] PartitionersBench.benchXXHashPartitioner 31 avgt 20
40.650 ± 0.025 ns/op
[java] PartitionersBench.benchXXHashPartitioner 67 avgt 20
53.305 ± 0.035 ns/op
[java] PartitionersBench.benchXXHashPartitioner131 avgt 20
67.098 ± 0.057 ns/op
[java] PartitionersBench.benchXXHashPartitioner517 avgt 20
150.415 ± 0.107 ns/op
[java] PartitionersBench.benchXXHashPartitioner 1031 avgt 20
265.614 ± 0.140 ns/op
[java] PartitionersBench.benchXXHashPartitioner 2041 avgt 20
365.796 ± 0.225 ns/op
[java] PartitionersBench.benchXXHashPartitioner 4097 avgt 20
925.841 ± 0.664 ns/op
{code}
https://github.com/OpenHFT/Zero-Allocation-Hashing
https://cyan4973.github.io/xxHash/
was:
I implemented partitioner based on XXHash algorithm.
There are two branches, the first xxhash, extracts common parts with Murmur as
there is a lot of overlap between these two.
The second branch just copies everything from Murmur and changes just bits
which are necessary.
I have written a microbenchmark measuring both partitioners and XXHash
implementation is very fast, around 10x faster. Benchmark is included in
xxhash-2 branch.
{code:java}
[java] Benchmark (bufferSize) Mode Cnt
Score Error Units
[java] PartitionersBench.benchMurmur3Partitioner31 avgt 20
157.942 ± 0.110 ns/op
[java] PartitionersBench.benchMurmur3Partitioner67 avgt 20
204.670 ± 0.152 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 131 avgt 20
361.068 ± 0.228 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 517 avgt 20
1325.670 ± 1.255 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 1031 avgt 20
2594.651 ± 2.725 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 2041 avgt 20
5082.166 ± 1.721 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 4097 avgt 20
10112.020 ± 3.637 ns/op
[java] PartitionersBench.benchXXHashPartitioner 31 avgt 20
40.650 ± 0.025 ns/op
[java] PartitionersBench.benchXXHashPartitioner 67 avgt 20
53.305 ± 0.035 ns/op
[java] PartitionersBench.benchXXHashPartitioner131 avgt 20
67.098 ± 0.057 ns/op
[java] PartitionersBench.benchXXHashPartitioner517 avgt 20
150.415 ± 0.107 ns/op
[java] PartitionersBench.benchXXHashPartitioner 1031 avgt 20
265.614 ± 0.140 ns/op
[java] PartitionersBench.benchXXHashPartitioner 2041 avgt 20
365.796 ± 0.225 ns/op
[java] PartitionersBench.benchXXHashPartitioner 4097 avgt 20
925.841 ± 0.664 ns/op
{code}
https://github.com/OpenHFT/Zero-Allocation-Hashing
https://cyan4973.github.io/xxHash/
> Implement XXHashPartitioner
> ---
>
> Key: CASSANDRA-16610
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16610
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> I implemented partitioner based on XXHash algorithm.
>
[jira] [Created] (CASSANDRA-16610) Implement XXHashPartitioner
Stefan Miklosovic created CASSANDRA-16610:
-
Summary: Implement XXHashPartitioner
Key: CASSANDRA-16610
URL: https://issues.apache.org/jira/browse/CASSANDRA-16610
Project: Cassandra
Issue Type: New Feature
Components: Legacy/Core
Reporter: Stefan Miklosovic
I implemented partitioner based on XXHash algorithm.
There are two branches, the first xxhash, extracts common parts with Murmur as
there is a lot of overlap between these two.
The second branch just copies everything from Murmur and changes just bits
which are necessary.
I have written a microbenchmark measuring both partitioners and XXHash
implementation is very fast, around 10x faster. Benchmark is included in
xxhash-2 branch.
{code:java}
[java] Benchmark (bufferSize) Mode Cnt
Score Error Units
[java] PartitionersBench.benchMurmur3Partitioner31 avgt 20
157.942 ± 0.110 ns/op
[java] PartitionersBench.benchMurmur3Partitioner67 avgt 20
204.670 ± 0.152 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 131 avgt 20
361.068 ± 0.228 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 517 avgt 20
1325.670 ± 1.255 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 1031 avgt 20
2594.651 ± 2.725 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 2041 avgt 20
5082.166 ± 1.721 ns/op
[java] PartitionersBench.benchMurmur3Partitioner 4097 avgt 20
10112.020 ± 3.637 ns/op
[java] PartitionersBench.benchXXHashPartitioner 31 avgt 20
40.650 ± 0.025 ns/op
[java] PartitionersBench.benchXXHashPartitioner 67 avgt 20
53.305 ± 0.035 ns/op
[java] PartitionersBench.benchXXHashPartitioner131 avgt 20
67.098 ± 0.057 ns/op
[java] PartitionersBench.benchXXHashPartitioner517 avgt 20
150.415 ± 0.107 ns/op
[java] PartitionersBench.benchXXHashPartitioner 1031 avgt 20
265.614 ± 0.140 ns/op
[java] PartitionersBench.benchXXHashPartitioner 2041 avgt 20
365.796 ± 0.225 ns/op
[java] PartitionersBench.benchXXHashPartitioner 4097 avgt 20
925.841 ± 0.664 ns/op
{code}
https://github.com/OpenHFT/Zero-Allocation-Hashing
https://cyan4973.github.io/xxHash/
--
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-16588) NPE getting host_id in Gossiper.isSafeForStartup
[
https://issues.apache.org/jira/browse/CASSANDRA-16588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324042#comment-17324042
]
Brandon Williams edited comment on CASSANDRA-16588 at 4/16/21, 7:40 PM:
||Patch||CI||
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-16588]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/680/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/680/pipeline]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-16588-trunk]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/681/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/681/pipeline]|
was (Author: brandon.williams):
||Patch||CI||
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-16588]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/680/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/680/pipeline]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-16588-trunk|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/681/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/681/pipeline]|
> NPE getting host_id in Gossiper.isSafeForStartup
>
>
> Key: CASSANDRA-16588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16588
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0-rc
>
>
> As seen here:
> https://ci-cassandra.apache.org/job/Cassandra-devbranch/604/testReport/junit/org.apache.cassandra.distributed.upgrade/MixedModeGossipTest/testStatusFieldShouldExistInOldVersionNodesEdgeCase/
> {noformat}
> java.lang.NullPointerException
> at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:952)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:657)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:933)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:784)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:541)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I believe what is happening is a GossipDigestAck has been queued to ack the
> shutdown state from the node on the seed, but isn't actually sent until the
> node has restarted and gone into shadow. Since the ack contains the node's
> IP, it assumes a host_id will be there but since this is not an actual shadow
> response, it is not.
--
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-16588) NPE getting host_id in Gossiper.isSafeForStartup
[
https://issues.apache.org/jira/browse/CASSANDRA-16588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324042#comment-17324042
]
Brandon Williams commented on CASSANDRA-16588:
--
||Patch||CI||
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-16588]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/680/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/680/pipeline]|
[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-16588-trunk|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/681/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/681/pipeline]|
> NPE getting host_id in Gossiper.isSafeForStartup
>
>
> Key: CASSANDRA-16588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16588
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0-rc
>
>
> As seen here:
> https://ci-cassandra.apache.org/job/Cassandra-devbranch/604/testReport/junit/org.apache.cassandra.distributed.upgrade/MixedModeGossipTest/testStatusFieldShouldExistInOldVersionNodesEdgeCase/
> {noformat}
> java.lang.NullPointerException
> at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:952)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:657)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:933)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:784)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:541)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I believe what is happening is a GossipDigestAck has been queued to ack the
> shutdown state from the node on the seed, but isn't actually sent until the
> node has restarted and gone into shadow. Since the ack contains the node's
> IP, it assumes a host_id will be there but since this is not an actual shadow
> response, it is not.
--
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-16588) NPE getting host_id in Gossiper.isSafeForStartup
[
https://issues.apache.org/jira/browse/CASSANDRA-16588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324042#comment-17324042
]
Brandon Williams edited comment on CASSANDRA-16588 at 4/16/21, 7:38 PM:
||Patch||CI||
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-16588]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/680/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/680/pipeline]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-16588-trunk|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/681/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/681/pipeline]|
was (Author: brandon.williams):
||Patch||CI||
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-16588]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/680/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/680/pipeline]|
[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-16588-trunk|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/681/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/681/pipeline]|
> NPE getting host_id in Gossiper.isSafeForStartup
>
>
> Key: CASSANDRA-16588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16588
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0-rc
>
>
> As seen here:
> https://ci-cassandra.apache.org/job/Cassandra-devbranch/604/testReport/junit/org.apache.cassandra.distributed.upgrade/MixedModeGossipTest/testStatusFieldShouldExistInOldVersionNodesEdgeCase/
> {noformat}
> java.lang.NullPointerException
> at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:952)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:657)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:933)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:784)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:541)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I believe what is happening is a GossipDigestAck has been queued to ack the
> shutdown state from the node on the seed, but isn't actually sent until the
> node has restarted and gone into shadow. Since the ack contains the node's
> IP, it assumes a host_id will be there but since this is not an actual shadow
> response, it is not.
--
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-16586) Fix flaky test testAvailabilityV30ToV4 - org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
[
https://issues.apache.org/jira/browse/CASSANDRA-16586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16586:
--
Test and Documentation Plan: JVM upgrade test modified, run
Status: Patch Available (was: In Progress)
> Fix flaky test testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> --
>
> Key: CASSANDRA-16586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16586
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/881/workflows/8e477260-ac6a-4eab-b4be-cbc048199565/jobs/5269
> testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> {code}
> junit.framework.AssertionFailedError: Unexpected error in case QUORUM-QUORUM
> with not upgraded coordinator and 1 nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:127)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:79)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:186)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:81)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:53)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailabilityV30ToV4(MixedModeAvailabilityV30Test.java:39)
> Caused by: java.lang.RuntimeException:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 1 responses.
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$5(IsolatedExecutor.java:109)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeWithResult(Coordinator.java:69)
> at
> org.apache.cassandra.distributed.api.ICoordinator.execute(ICoordinator.java:32)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.lambda$test$1(MixedModeAvailabilityTestBase.java:120)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:139)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:119)
> Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
> timed out - received only 1 responses.
> at
> org.apache.cassandra.service.ReadCallback.awaitResults(ReadCallback.java:136)
> at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:142)
> at
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
> at
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1831)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1780)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1718)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1627)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1162)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:302)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:263)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:115)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeInternal(Coordinator.java:107)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:69)
> 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
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by
[jira] [Commented] (CASSANDRA-16586) Fix flaky test testAvailabilityV30ToV4 - org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
[
https://issues.apache.org/jira/browse/CASSANDRA-16586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324024#comment-17324024
]
Adam Holmberg commented on CASSANDRA-16586:
---
I ran into trouble getting the shutdown approach working with some of the
earlier versions. Instead I pushed a simplified version that
1.) extends the request timeout by a second to get away from false negatives
2.) uses message filtering to effect timeouts to nodes when "down"
test run
[here|https://app.circleci.com/pipelines/github/aholmberg/cassandra/250/workflows/c139a296-8b51-4e33-881f-ff811dbec0d3/jobs/2998/parallel-runs/0?filterBy=ALL]
> Fix flaky test testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> --
>
> Key: CASSANDRA-16586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16586
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/881/workflows/8e477260-ac6a-4eab-b4be-cbc048199565/jobs/5269
> testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> {code}
> junit.framework.AssertionFailedError: Unexpected error in case QUORUM-QUORUM
> with not upgraded coordinator and 1 nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:127)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:79)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:186)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:81)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:53)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailabilityV30ToV4(MixedModeAvailabilityV30Test.java:39)
> Caused by: java.lang.RuntimeException:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 1 responses.
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$5(IsolatedExecutor.java:109)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeWithResult(Coordinator.java:69)
> at
> org.apache.cassandra.distributed.api.ICoordinator.execute(ICoordinator.java:32)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.lambda$test$1(MixedModeAvailabilityTestBase.java:120)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:139)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:119)
> Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
> timed out - received only 1 responses.
> at
> org.apache.cassandra.service.ReadCallback.awaitResults(ReadCallback.java:136)
> at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:142)
> at
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
> at
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1831)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1780)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1718)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1627)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1162)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:302)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:263)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:115)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeInternal(Coordinator.java:107)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:69)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
>
[jira] [Comment Edited] (CASSANDRA-16495) Scheduled (Delayed) Schema Pull Tasks May Run After MIGRATION Stage Shutdown During Decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-16495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17309730#comment-17309730
]
Ekaterina Dimitrova edited comment on CASSANDRA-16495 at 4/16/21, 5:30 PM:
---
Thanks [~maedhroz], all valid points.
[PR|https://github.com/ekaterinadimitrova2/cassandra/pull/] updated.
New CI triggered [here
|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/510/]
And I think we need one more committer to review it too.
was (Author: e.dimitrova):
Thanks [~maedhroz], all valid points.
[PR|https://github.com/ekaterinadimitrova2/cassandra/pull/97] updated.
New CI triggered [here
|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/510/]
And I think we need one more committer to review it too.
> Scheduled (Delayed) Schema Pull Tasks May Run After MIGRATION Stage Shutdown
> During Decommission
>
>
> Key: CASSANDRA-16495
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16495
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Caleb Rackliffe
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.25, 3.11.11, 4.0-rc1
>
>
> A new test added in CASSANDRA-16181 stumbled across this, although it doesn’t
> happen consistently. When [failure
> occurs|https://app.circleci.com/pipelines/github/maedhroz/cassandra/235/workflows/eb8133ce-9373-4136-b404-ceca167353f6/jobs/1355/tests],
> it appears to be because a delayed schema pull happens after decommission
> shuts down the MIGRATION stage’s thread pool.
> {noformat}
> ERROR [node1_isolatedExecutor:1] node1 2021-02-15 19:35:36,284
> CassandraDaemon.java:579 - Exception in thread
> Thread[node1_NonPeriodicTasks:1,5,node1]
> java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut
> down at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:72)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:825)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1355)
>
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:176)
>
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
> at org.apache.cassandra.concurrent.Stage.submit(Stage.java:129)
> at
> org.apache.cassandra.schema.MigrationCoordinator.lambda$scheduleSchemaPull$2(MigrationCoordinator.java:362)
>
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
> A fix might be as simple as shutting down ScheduledExecutors.nonPeriodicTasks
> in StorageService#decommission(). See the original discussion
> [here|https://issues.apache.org/jira/browse/CASSANDRA-16181?focusedCommentId=17293329=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17293329].
--
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-16495) Scheduled (Delayed) Schema Pull Tasks May Run After MIGRATION Stage Shutdown During Decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-16495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315055#comment-17315055
]
Ekaterina Dimitrova edited comment on CASSANDRA-16495 at 4/16/21, 5:28 PM:
---
Thank you both!
I just squashed the commits; pushed patches and submitted CI runs for 3.0, 3.11
and 4.0. The only difference is that Stage class was refactored in 4.0 but this
doesn't affect a lot the patch.
[3.0
patch|https://github.com/ekaterinadimitrova2/cassandra/commit/71d06d9b45d907687cef7e1cc6d6210f1b2079c9]
| [CI run |https://jenkins-cm4.apache.org/job/Cassandra-devbranch/583/]
[3.11
patch|https://github.com/ekaterinadimitrova2/cassandra/commit/74a6cbd82bfd3c7177f4067bf63e96114dc0ba85]
| [CI run |https://jenkins-cm4.apache.org/job/Cassandra-devbranch/584/]
[trunk patch|https://github.com/ekaterinadimitrova2/cassandra/pull/] | [CI run
|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/585/]
was (Author: e.dimitrova):
Thank you both!
I just squashed the commits; pushed patches and submitted CI runs for 3.0, 3.11
and 4.0. The only difference is that Stage class was refactored in 4.0 but this
doesn't affect a lot the patch.
[3.0
patch|https://github.com/ekaterinadimitrova2/cassandra/commit/71d06d9b45d907687cef7e1cc6d6210f1b2079c9]
| [CI run |https://jenkins-cm4.apache.org/job/Cassandra-devbranch/583/]
[3.11
patch|https://github.com/ekaterinadimitrova2/cassandra/commit/74a6cbd82bfd3c7177f4067bf63e96114dc0ba85]
| [CI run |https://jenkins-cm4.apache.org/job/Cassandra-devbranch/584/]
[trunk
patch|https://github.com/ekaterinadimitrova2/cassandra/pull/97/commits/ad531e827d4dd88e7d688e79aaa2045c9bb49eb]
| [CI run |https://jenkins-cm4.apache.org/job/Cassandra-devbranch/585/]
> Scheduled (Delayed) Schema Pull Tasks May Run After MIGRATION Stage Shutdown
> During Decommission
>
>
> Key: CASSANDRA-16495
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16495
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Caleb Rackliffe
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.25, 3.11.11, 4.0-rc1
>
>
> A new test added in CASSANDRA-16181 stumbled across this, although it doesn’t
> happen consistently. When [failure
> occurs|https://app.circleci.com/pipelines/github/maedhroz/cassandra/235/workflows/eb8133ce-9373-4136-b404-ceca167353f6/jobs/1355/tests],
> it appears to be because a delayed schema pull happens after decommission
> shuts down the MIGRATION stage’s thread pool.
> {noformat}
> ERROR [node1_isolatedExecutor:1] node1 2021-02-15 19:35:36,284
> CassandraDaemon.java:579 - Exception in thread
> Thread[node1_NonPeriodicTasks:1,5,node1]
> java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut
> down at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:72)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:825)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1355)
>
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:176)
>
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
> at org.apache.cassandra.concurrent.Stage.submit(Stage.java:129)
> at
> org.apache.cassandra.schema.MigrationCoordinator.lambda$scheduleSchemaPull$2(MigrationCoordinator.java:362)
>
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
> A fix might be as simple as shutting down ScheduledExecutors.nonPeriodicTasks
> in StorageService#decommission(). See the original discussion
> [here|https://issues.apache.org/jira/browse/CASSANDRA-16181?focusedCommentId=17293329=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17293329].
--
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-16495) Scheduled (Delayed) Schema Pull Tasks May Run After MIGRATION Stage Shutdown During Decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-16495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315055#comment-17315055
]
Ekaterina Dimitrova edited comment on CASSANDRA-16495 at 4/16/21, 5:28 PM:
---
Thank you both!
I just squashed the commits; pushed patches and submitted CI runs for 3.0, 3.11
and 4.0. The only difference is that Stage class was refactored in 4.0 but this
doesn't affect a lot the patch.
[3.0
patch|https://github.com/ekaterinadimitrova2/cassandra/commit/71d06d9b45d907687cef7e1cc6d6210f1b2079c9]
| [CI run |https://jenkins-cm4.apache.org/job/Cassandra-devbranch/583/]
[3.11
patch|https://github.com/ekaterinadimitrova2/cassandra/commit/74a6cbd82bfd3c7177f4067bf63e96114dc0ba85]
| [CI run |https://jenkins-cm4.apache.org/job/Cassandra-devbranch/584/]
[trunk
patch|https://github.com/ekaterinadimitrova2/cassandra/pull/97/commits/ad531e827d4dd88e7d688e79aaa2045c9bb49eb]
| [CI run |https://jenkins-cm4.apache.org/job/Cassandra-devbranch/585/]
was (Author: e.dimitrova):
Thank you both!
I just squashed the commits; pushed patches and submitted CI runs for 3.0, 3.11
and 4.0. The only difference is that Stage class was refactored in 4.0 but this
doesn't affect a lot the patch.
[3.0
patch|https://github.com/ekaterinadimitrova2/cassandra/commit/71d06d9b45d907687cef7e1cc6d6210f1b2079c9]
| [CI run |https://jenkins-cm4.apache.org/job/Cassandra-devbranch/583/]
[3.11
patch|https://github.com/ekaterinadimitrova2/cassandra/commit/74a6cbd82bfd3c7177f4067bf63e96114dc0ba85]
| [CI run |https://jenkins-cm4.apache.org/job/Cassandra-devbranch/584/]
[trunk
patch|https://github.com/ekaterinadimitrova2/cassandra/pull/97/commits/ad531e827d4dd88e7d688e79aaa2045c9bb49eb7]
| [CI run |https://jenkins-cm4.apache.org/job/Cassandra-devbranch/585/]
> Scheduled (Delayed) Schema Pull Tasks May Run After MIGRATION Stage Shutdown
> During Decommission
>
>
> Key: CASSANDRA-16495
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16495
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Caleb Rackliffe
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.25, 3.11.11, 4.0-rc1
>
>
> A new test added in CASSANDRA-16181 stumbled across this, although it doesn’t
> happen consistently. When [failure
> occurs|https://app.circleci.com/pipelines/github/maedhroz/cassandra/235/workflows/eb8133ce-9373-4136-b404-ceca167353f6/jobs/1355/tests],
> it appears to be because a delayed schema pull happens after decommission
> shuts down the MIGRATION stage’s thread pool.
> {noformat}
> ERROR [node1_isolatedExecutor:1] node1 2021-02-15 19:35:36,284
> CassandraDaemon.java:579 - Exception in thread
> Thread[node1_NonPeriodicTasks:1,5,node1]
> java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut
> down at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:72)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:825)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1355)
>
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:176)
>
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
> at org.apache.cassandra.concurrent.Stage.submit(Stage.java:129)
> at
> org.apache.cassandra.schema.MigrationCoordinator.lambda$scheduleSchemaPull$2(MigrationCoordinator.java:362)
>
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
> A fix might be as simple as shutting down ScheduledExecutors.nonPeriodicTasks
> in StorageService#decommission(). See the original discussion
> [here|https://issues.apache.org/jira/browse/CASSANDRA-16181?focusedCommentId=17293329=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17293329].
--
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:
[jira] [Commented] (CASSANDRA-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17323974#comment-17323974
]
Adam Holmberg commented on CASSANDRA-16524:
---
I understand that this was found during upgrade, but imo an upgrade test is
fairly abstract characterization of this fix. [~gianluca] said creating the
cert chain was fairly involved. Do you think it's worth codifying that in an
integration test? I had been thinking that the new unit tests were sufficient.
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException:
> writerIndex(8560) + minWritableBytes(1977) exceeds
[jira] [Comment Edited] (CASSANDRA-16607) Fix flaky test testRequestResponse – org.apache.cassandra.net.MockMessagingServiceTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17323947#comment-17323947
]
Andres de la Peña edited comment on CASSANDRA-16607 at 4/16/21, 5:15 PM:
-
It seems that the problem is that since CASSANDRA-12653
{{MockMessagingSpy#mockedMessageResponses}} is increased asynchronously by
[this
thread|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/net/MatcherResponse.java#L185-L198].
Because of this the value of {{mockedMessageResponses}} can be checked before
it has been increased by the thread, causing the reported failure. While the
test doesn't fail very often, the failure can be easily reproduced by manually
adding a sleep in the aforementioned thread.
The proposed PRs simply use {{spinAssertEquals}} to wait for the writer thread.
Also, I think there could be thread safety issues when increasing
{{mockedMessageResponses}} from different threads, so I'm making it an
{{AtomicInteger}}.
CI for 3.11:
*
[CircleCI|https://app.circleci.com/pipelines/github/adelapena/cassandra/275/workflows/8be80b18-c168-478d-ae1d-7cb5c04d4b9d]
* [Multiplexer
MockMessagingServiceTest|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/805/]
* [Multiplexer
ShadowRoundTest|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/807/]
CI for trunk:
* [CircleCI
j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/276/workflows/f95f3503-1471-492a-ab86-13b7cd9fded2]
* [CircleCI
j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/275/workflows/8be80b18-c168-478d-ae1d-7cb5c04d4b9d]
* [Multiplexer
MockMessagingServiceTest|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/806/]
* [Multiplexer
ShadowRoundTest|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/808/]
was (Author: adelapena):
It seems that the problem is that since CASSANDRA-12653
{{MockMessagingSpy#mockedMessageResponses}} is increased asynchronously by
[this
thread|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/net/MatcherResponse.java#L185-L198].
Because of this the value of {{mockedMessageResponses}} can be checked before
it has been increased by the thread, causing the reported failure.
The proposed PRs simply use {{spinAssertEquals}} to wait for the writer thread.
Also, I think there could be thread safety issues when increasing
{{mockedMessageResponses}} from different threads, so I'm making it an
{{AtomicInteger}}.
CI for 3.11:
*
[CircleCI|https://app.circleci.com/pipelines/github/adelapena/cassandra/275/workflows/8be80b18-c168-478d-ae1d-7cb5c04d4b9d]
* [Multiplexer
MockMessagingServiceTest|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/805/]
* [Multiplexer
ShadowRoundTest|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/807/]
CI for trunk:
* [CircleCI
j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/276/workflows/f95f3503-1471-492a-ab86-13b7cd9fded2]
* [CircleCI
j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/275/workflows/8be80b18-c168-478d-ae1d-7cb5c04d4b9d]
* [Multiplexer
MockMessagingServiceTest|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/806/]
* [Multiplexer
ShadowRoundTest|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/808/]
> Fix flaky test testRequestResponse –
> org.apache.cassandra.net.MockMessagingServiceTest
> --
>
> Key: CASSANDRA-16607
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16607
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.11.11, 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/659/tests/
> {code}
> Error
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.net.MockMessagingServiceTest.testRequestResponse(MockMessagingServiceTest.java:81)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2021-04-15 08:22:46,838
[jira] [Updated] (CASSANDRA-16607) Fix flaky test testRequestResponse – org.apache.cassandra.net.MockMessagingServiceTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16607:
--
Fix Version/s: 3.11.11
> Fix flaky test testRequestResponse –
> org.apache.cassandra.net.MockMessagingServiceTest
> --
>
> Key: CASSANDRA-16607
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16607
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.11.11, 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/659/tests/
> {code}
> Error
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.net.MockMessagingServiceTest.testRequestResponse(MockMessagingServiceTest.java:81)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2021-04-15 08:22:46,838 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2021-04-15 08:22:46,840 YamlConfigurationLoader.java:112 -
> Loading settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2021-04-15 08:22:46,899 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-04-15 08:22:46,911 PlatformDependent0.java:417 -
> -Dio.netty.noUnsaf
> ...[truncated 61235 chars]...
> te NORMAL, token [a57d4b7f61f49471614b7ac41f16477e]
> DEBUG [main] 2021-04-15 08:22:49,840 StorageService.java:2674 - New node
> /127.0.0.1:7069 at token a57d4b7f61f49471614b7ac41f16477e
> DEBUG [main] 2021-04-15 08:22:49,848 StorageService.java:2727 - Node
> /127.0.0.1:7069 state NORMAL, token [a57d4b7f61f49471614b7ac41f16477e]
> INFO [main] 2021-04-15 08:22:49,848 StorageService.java:2730 - Node
> /127.0.0.1:7069 state jump to NORMAL
> DEBUG [main] 2021-04-15 08:22:49,849 StorageService.java:1619 - NORMAL
> {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-16607) Fix flaky test testRequestResponse – org.apache.cassandra.net.MockMessagingServiceTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16607:
--
Test and Documentation Plan: Flaky test fix
Status: Patch Available (was: In Progress)
> Fix flaky test testRequestResponse –
> org.apache.cassandra.net.MockMessagingServiceTest
> --
>
> Key: CASSANDRA-16607
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16607
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/659/tests/
> {code}
> Error
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.net.MockMessagingServiceTest.testRequestResponse(MockMessagingServiceTest.java:81)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2021-04-15 08:22:46,838 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2021-04-15 08:22:46,840 YamlConfigurationLoader.java:112 -
> Loading settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2021-04-15 08:22:46,899 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-04-15 08:22:46,911 PlatformDependent0.java:417 -
> -Dio.netty.noUnsaf
> ...[truncated 61235 chars]...
> te NORMAL, token [a57d4b7f61f49471614b7ac41f16477e]
> DEBUG [main] 2021-04-15 08:22:49,840 StorageService.java:2674 - New node
> /127.0.0.1:7069 at token a57d4b7f61f49471614b7ac41f16477e
> DEBUG [main] 2021-04-15 08:22:49,848 StorageService.java:2727 - Node
> /127.0.0.1:7069 state NORMAL, token [a57d4b7f61f49471614b7ac41f16477e]
> INFO [main] 2021-04-15 08:22:49,848 StorageService.java:2730 - Node
> /127.0.0.1:7069 state jump to NORMAL
> DEBUG [main] 2021-04-15 08:22:49,849 StorageService.java:1619 - NORMAL
> {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-16607) Fix flaky test testRequestResponse – org.apache.cassandra.net.MockMessagingServiceTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17323947#comment-17323947
]
Andres de la Peña commented on CASSANDRA-16607:
---
It seems that the problem is that since CASSANDRA-12653
{{MockMessagingSpy#mockedMessageResponses}} is increased asynchronously by
[this
thread|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/net/MatcherResponse.java#L185-L198].
Because of this the value of {{mockedMessageResponses}} can be checked before
it has been increased by the thread, causing the reported failure.
The proposed PRs simply use {{spinAssertEquals}} to wait for the writer thread.
Also, I think there could be thread safety issues when increasing
{{mockedMessageResponses}} from different threads, so I'm making it an
{{AtomicInteger}}.
CI for 3.11:
*
[CircleCI|https://app.circleci.com/pipelines/github/adelapena/cassandra/275/workflows/8be80b18-c168-478d-ae1d-7cb5c04d4b9d]
* [Multiplexer
MockMessagingServiceTest|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/805/]
* [Multiplexer
ShadowRoundTest|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/807/]
CI for trunk:
* [CircleCI
j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/276/workflows/f95f3503-1471-492a-ab86-13b7cd9fded2]
* [CircleCI
j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/275/workflows/8be80b18-c168-478d-ae1d-7cb5c04d4b9d]
* [Multiplexer
MockMessagingServiceTest|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/806/]
* [Multiplexer
ShadowRoundTest|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/808/]
> Fix flaky test testRequestResponse –
> org.apache.cassandra.net.MockMessagingServiceTest
> --
>
> Key: CASSANDRA-16607
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16607
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/659/tests/
> {code}
> Error
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.net.MockMessagingServiceTest.testRequestResponse(MockMessagingServiceTest.java:81)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2021-04-15 08:22:46,838 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2021-04-15 08:22:46,840 YamlConfigurationLoader.java:112 -
> Loading settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2021-04-15 08:22:46,899 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-04-15 08:22:46,911 PlatformDependent0.java:417 -
> -Dio.netty.noUnsaf
> ...[truncated 61235 chars]...
> te NORMAL, token [a57d4b7f61f49471614b7ac41f16477e]
> DEBUG [main] 2021-04-15 08:22:49,840 StorageService.java:2674 - New node
> /127.0.0.1:7069 at token a57d4b7f61f49471614b7ac41f16477e
> DEBUG [main] 2021-04-15 08:22:49,848 StorageService.java:2727 - Node
> /127.0.0.1:7069 state NORMAL, token [a57d4b7f61f49471614b7ac41f16477e]
> INFO [main] 2021-04-15 08:22:49,848 StorageService.java:2730 - Node
> /127.0.0.1:7069 state jump to NORMAL
> DEBUG [main] 2021-04-15 08:22:49,849 StorageService.java:1619 - NORMAL
> {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-16588) NPE getting host_id in Gossiper.isSafeForStartup
[
https://issues.apache.org/jira/browse/CASSANDRA-16588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17323917#comment-17323917
]
Matt Fleming commented on CASSANDRA-16588:
--
I think the patch from Sam is a bit too aggressive and will incorrectly think
that gossip data for the local node that contains dead states ("left",
"removing", "hibernate", etc) is the bad ACK that we're trying to detect to
avoid the NPE in isSafeForStartup. You should be able to trigger this by
assassinating a non-seed node in a cluster.
We should probably filter out deadStates because they won't trigger the NPE.
Something like this
https://github.com/mfleming/cassandra/commit/e68602ae300e6a2567e1b59efa4229ff3456e521
> NPE getting host_id in Gossiper.isSafeForStartup
>
>
> Key: CASSANDRA-16588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16588
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0-rc
>
>
> As seen here:
> https://ci-cassandra.apache.org/job/Cassandra-devbranch/604/testReport/junit/org.apache.cassandra.distributed.upgrade/MixedModeGossipTest/testStatusFieldShouldExistInOldVersionNodesEdgeCase/
> {noformat}
> java.lang.NullPointerException
> at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:952)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:657)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:933)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:784)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:541)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I believe what is happening is a GossipDigestAck has been queued to ack the
> shutdown state from the node on the seed, but isn't actually sent until the
> node has restarted and gone into shadow. Since the ack contains the node's
> IP, it assumes a host_id will be there but since this is not an actual shadow
> response, it is not.
--
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-15635) Script to autogenerate cassandra.yaml
[ https://issues.apache.org/jira/browse/CASSANDRA-15635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15635: - Mentor: Brandon Williams > Script to autogenerate cassandra.yaml > - > > Key: CASSANDRA-15635 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15635 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config, Local/Scripts >Reporter: Dinesh Joshi >Assignee: Mitesh Gupta >Priority: Normal > Labels: gsoc2021, mentor > > It would be useful to have a script that can ask the user a few questions and > generate a recommended cassandra.yaml based on their answers. This will help > solve issues like selecting num_tokens. It can also be integrated into OS > specific packaging tools such as debconf[1]. Rather than just documenting on > the website, it is best to provide a simple script to auto-generate > configuration based on common use-cases. > [1] https://wiki.debian.org/debconf -- 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-16567) Fix test testCompoundPartitionKey - org.apache.cassandra.cql3.ViewTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16567:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Status: Review In Progress (was: Patch Available)
> Fix test testCompoundPartitionKey - org.apache.cassandra.cql3.ViewTest
> --
>
> Key: CASSANDRA-16567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16567
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/unit
>Reporter: David Capwell
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/874/workflows/0b0a1e36-107a-43c7-815f-bf8e61d3028d/jobs/5227/tests
> {code}
> junit.framework.AssertionFailedError: Got more rows than expected. Expected 0
> but got 1.
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1185)
> at
> org.apache.cassandra.cql3.ViewTest.testCompoundPartitionKey(ViewTest.java:817)
> {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-16567) Fix test testCompoundPartitionKey - org.apache.cassandra.cql3.ViewTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16567:
Reviewers: Ekaterina Dimitrova
> Fix test testCompoundPartitionKey - org.apache.cassandra.cql3.ViewTest
> --
>
> Key: CASSANDRA-16567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16567
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/unit
>Reporter: David Capwell
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/874/workflows/0b0a1e36-107a-43c7-815f-bf8e61d3028d/jobs/5227/tests
> {code}
> junit.framework.AssertionFailedError: Got more rows than expected. Expected 0
> but got 1.
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1185)
> at
> org.apache.cassandra.cql3.ViewTest.testCompoundPartitionKey(ViewTest.java:817)
> {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-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17323814#comment-17323814
]
Ekaterina Dimitrova edited comment on CASSANDRA-16524 at 4/16/21, 2:02 PM:
---
Thanks [~gianluca] for all the work and bearing with me in Slack to confirm
details.
I just submitted my pass of review with just small comments. I have only two
questions.
- Do we really need to use the new capacity function for max ?
I want to align this with 3.11 and have the least hurdle. Does 3.11 always use
the Netty
[DEFAULT_MAX_CAPACITY|https://github.com/netty/netty/blob/netty-4.1.58.Final/buffer/src/main/java/io/netty/buffer/AbstractByteBufAllocator.java#L31]?
- resizing happens in the same way it happens in 3.11 now?
Also, [~aholmber], as you were working on the upgrade tests, do you think there
is another one we can add to cover this case and show the smooth upgrade after
this patch or it is overkill?
was (Author: e.dimitrova):
Thanks [~gianluca] for all the work and bearing with me in Slack to confirm
details.
I just submitted my pass of review with just small comments. I have only two
questions.
- Do we really need to use the new capacity function for max ?
I want to align this with 3.11 and have the least hurdle. Does 3.11 always use
the Netty
[DEFAULT_MAX_CAPACITY|https://github.com/netty/netty/blob/netty-4.1.58.Final/buffer/src/main/java/io/netty/buffer/AbstractByteBufAllocator.java#L31]?
- resizing happens in the same way it happens in 3.11 now?
Also, [~aholmber], as you were working on the upgrade tests, do you think there
is another one we can add to cover this case and show the smooth upgrade after
this patch or it is overkill?
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
>
[jira] [Comment Edited] (CASSANDRA-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17323814#comment-17323814
]
Ekaterina Dimitrova edited comment on CASSANDRA-16524 at 4/16/21, 1:59 PM:
---
Thanks [~gianluca] for all the work and bearing with me in Slack to confirm
details.
I just submitted my pass of review with just small comments. I have only two
questions.
- Do we really need to use the new capacity function for max ?
I want to align this with 3.11 and have the least hurdle. Does 3.11 always use
the Netty
[DEFAULT_MAX_CAPACITY|https://github.com/netty/netty/blob/netty-4.1.58.Final/buffer/src/main/java/io/netty/buffer/AbstractByteBufAllocator.java#L31]?
- resizing happens in the same way it happens in 3.11 now?
Also, [~aholmber], as you were working on the upgrade tests, do you think there
is another one we can add to cover this case and show the smooth upgrade after
this patch or it is overkill?
was (Author: e.dimitrova):
Thanks [~gianluca] for all the work and bearing with me in Slack to confirm
details.
I just submitted my pass of review with just small comments. I have only one
bigger question.
Do we really need to use the new capacity function for max?
I want to align this with 3.11 and have the least hurdle. Does 3.11 always use
the Netty
[DEFAULT_MAX_CAPACITY|https://github.com/netty/netty/blob/netty-4.1.58.Final/buffer/src/main/java/io/netty/buffer/AbstractByteBufAllocator.java#L31]?
Also, [~aholmber], as you were working on the upgrade tests, do you think there
is another one we can add to cover this case and show the smooth upgrade after
this patch or it is overkill?
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
>
[jira] [Updated] (CASSANDRA-16608) Nodetool verify fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-16608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-16608: - Reviewers: Jon Meredith, Jon Meredith (was: Jon Meredith) Jon Meredith, Jon Meredith Status: Review In Progress (was: Patch Available) +1, thanks for the fix. > Nodetool verify fixes > - > > Key: CASSANDRA-16608 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16608 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-rc1, 4.0 > > > A few issues with nodetool verify: > * Include cause exception when it fails verifying an sstable > * Don't try to check if the node owns tokens from localpartitioner sstables > * Don't try to deserialise non-existing bloom filter file -- 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-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17323814#comment-17323814
]
Ekaterina Dimitrova commented on CASSANDRA-16524:
-
Thanks [~gianluca] for all the work and bearing with me in Slack to confirm
details.
I just submitted my pass of review with just small comments. I have only one
bigger question.
Do we really need to use the new capacity function for max?
I want to align this with 3.11 and have the least hurdle. Does 3.11 always use
the Netty
[DEFAULT_MAX_CAPACITY|https://github.com/netty/netty/blob/netty-4.1.58.Final/buffer/src/main/java/io/netty/buffer/AbstractByteBufAllocator.java#L31]?
Also, [~aholmber], as you were working on the upgrade tests, do you think there
is another one we can add to cover this case and show the smooth upgrade after
this patch or it is overkill?
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
>
[cassandra] 01/01: Merge branch 'cassandra-2.2' into cassandra-3.0
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 7a6a7099dc9dbbb9054787f431a45461a20cfaa5 Merge: 5f1b538 99b6095 Author: Brandon Williams AuthorDate: Fri Apr 16 08:22:58 2021 -0500 Merge branch 'cassandra-2.2' into cassandra-3.0 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
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 dbedf57572fb907ae41b475f6b9b41c50c1bf3ec Merge: 038271c 2d474c8 Author: Brandon Williams AuthorDate: Fri Apr 16 08:23:22 2021 -0500 Merge branch 'cassandra-3.11' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (038271c -> dbedf57)
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 038271c Use source release of python driver from pip rather than GitHub add 99b6095 Fix init script for debian Buster new 7a6a709 Merge branch 'cassandra-2.2' into cassandra-3.0 new 2d474c8 Merge branch 'cassandra-3.0' into cassandra-3.11 new dbedf57 Merge branch 'cassandra-3.11' into trunk The 3 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: - 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 (cca5ce5 -> 2d474c8)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from cca5ce5 Merge branch 'cassandra-3.0' into cassandra-3.11 add 99b6095 Fix init script for debian Buster new 7a6a709 Merge branch 'cassandra-2.2' into cassandra-3.0 new 2d474c8 Merge branch 'cassandra-3.0' into cassandra-3.11 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: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 2d474c86a35797872e10aed9a5b04150d76b1fd3 Merge: cca5ce5 7a6a709 Author: Brandon Williams AuthorDate: Fri Apr 16 08:23:10 2021 -0500 Merge branch 'cassandra-3.0' into cassandra-3.11 - 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 (5f1b538 -> 7a6a709)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 5f1b538 Merge branch 'cassandra-2.2' into cassandra-3.0 add 99b6095 Fix init script for debian Buster new 7a6a709 Merge branch 'cassandra-2.2' into cassandra-3.0 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: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15770) stop and restart fail in Debian 10 buster
[
https://issues.apache.org/jira/browse/CASSANDRA-15770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15770:
-
Fix Version/s: 2.2.20
> stop and restart fail in Debian 10 buster
> -
>
> Key: CASSANDRA-15770
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15770
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Vicente Jimenez Aguilar
>Assignee: Vicente Jimenez Aguilar
>Priority: Normal
> Labels: Debian, easyfix, patch
> Fix For: 2.2.20, 3.0.21, 3.11.7, 4.0, 4.0-beta1
>
> Attachments: 0001-Fix-init-script-for-debian-Buster.patch
>
>
> Debian 10 "buster" has an updated {{start-stop-daemon}} version that causes
> init script to fail to stop or restart Cassandra daemon. {{stop}} option do
> not stops first launched instance and depending of previous operations,
> {{restart}} and {{start}} could launch a second Cassandra daemon instance.
> {{start-stop-daemon}} since version 1.19.3 fail to stop matching only a
> pidfile that can be writen by an unprivileged (non-root) user because it is
> considered a security risk.
> Adding a second matching option (user) solved this.
> This fix does not break compatibility with older versions and does not mess
> with pidfile's mode or permissions.
> Related: CASSANDRA-15099
> https://github.com/vice/cassandra/tree/debian-buster
--
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-15770) stop and restart fail in Debian 10 buster
[
https://issues.apache.org/jira/browse/CASSANDRA-15770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17323799#comment-17323799
]
Brandon Williams commented on CASSANDRA-15770:
--
Added to 2.2 in 99b6095ecc02de415feaa029afea71ca824344fc
> stop and restart fail in Debian 10 buster
> -
>
> Key: CASSANDRA-15770
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15770
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Vicente Jimenez Aguilar
>Assignee: Vicente Jimenez Aguilar
>Priority: Normal
> Labels: Debian, easyfix, patch
> Fix For: 2.2.20, 3.0.21, 3.11.7, 4.0, 4.0-beta1
>
> Attachments: 0001-Fix-init-script-for-debian-Buster.patch
>
>
> Debian 10 "buster" has an updated {{start-stop-daemon}} version that causes
> init script to fail to stop or restart Cassandra daemon. {{stop}} option do
> not stops first launched instance and depending of previous operations,
> {{restart}} and {{start}} could launch a second Cassandra daemon instance.
> {{start-stop-daemon}} since version 1.19.3 fail to stop matching only a
> pidfile that can be writen by an unprivileged (non-root) user because it is
> considered a security risk.
> Adding a second matching option (user) solved this.
> This fix does not break compatibility with older versions and does not mess
> with pidfile's mode or permissions.
> Related: CASSANDRA-15099
> https://github.com/vice/cassandra/tree/debian-buster
--
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-2.2 updated: Fix init script for debian Buster
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-2.2 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-2.2 by this push: new 99b6095 Fix init script for debian Buster 99b6095 is described below commit 99b6095ecc02de415feaa029afea71ca824344fc Author: Vicente Jimenez Aguilar AuthorDate: Wed Apr 29 11:03:30 2020 +0200 Fix init script for debian Buster Patch by Vicente Jimenez Aguilar, reviewed by brandonwilliams for CASSANDRA-15770 --- CHANGES.txt | 1 + debian/init | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/CHANGES.txt b/CHANGES.txt index 5199140..f8f5bfc 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 2.2.20 + * Fix Debian init start/stop (CASSANDRA-15770) * Remove ant targets list-jvm-dtests and ant list-jvm-upgrade-dtests (CASSANDRA-16519) * Fix centos packaging for arm64, >=4.0 rpm's now require python3 (CASSANDRA-16477) * Make TokenMetadata's ring version increments atomic (CASSANDRA-16286) diff --git a/debian/init b/debian/init index 72417ae..727468c 100644 --- a/debian/init +++ b/debian/init @@ -97,7 +97,7 @@ do_stop() # 1 if daemon was already stopped # 2 if daemon could not be stopped # other if a failure occurred -start-stop-daemon -K -p "$PIDFILE" -R TERM/30/KILL/5 >/dev/null +start-stop-daemon -K -u cassandra -p "$PIDFILE" -R TERM/30/KILL/5 >/dev/null RET=$? rm -f "$PIDFILE" return $RET - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16588) NPE getting host_id in Gossiper.isSafeForStartup
[
https://issues.apache.org/jira/browse/CASSANDRA-16588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322315#comment-17322315
]
Brandon Williams edited comment on CASSANDRA-16588 at 4/16/21, 1:11 PM:
Your 3.11 build aborted for some reason, I started it again.
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/677/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/677/pipeline]
I was a bit concerned that we could get a valid shadow ack where our own IP was
somehow missing HOST_ID, causing us to stay in shadow forever and fail startup.
In fact, our empty state from CASSANDRA-16561 would do this if not for the
fact that since the generation and version are zero, the seed will filter
sending the empty state out (by luck of neither generation nor version being
perceived as changed.) So I opted for detecting the bad ack as specifically as
possible.
That said, there may be other unintentional bad responses possible here that
your patch would catch and prevent the NPE. I'm not sure which route is best.
*EDIT*: it looks like other states can be sent with this ACK, so I'm +1 on your
version. Restarted CI for 3.11.
was (Author: brandon.williams):
Your 3.11 build aborted for some reason, I started it again.
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/667/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/667/pipeline]
I was a bit concerned that we could get a valid shadow ack where our own IP was
somehow missing HOST_ID, causing us to stay in shadow forever and fail startup.
In fact, our empty state from CASSANDRA-16561 would do this if not for the
fact that since the generation and version are zero, the seed will filter
sending the empty state out (by luck of neither generation nor version being
perceived as changed.) So I opted for detecting the bad ack as specifically as
possible.
That said, there may be other unintentional bad responses possible here that
your patch would catch and prevent the NPE. I'm not sure which route is best.
> NPE getting host_id in Gossiper.isSafeForStartup
>
>
> Key: CASSANDRA-16588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16588
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0-rc
>
>
> As seen here:
> https://ci-cassandra.apache.org/job/Cassandra-devbranch/604/testReport/junit/org.apache.cassandra.distributed.upgrade/MixedModeGossipTest/testStatusFieldShouldExistInOldVersionNodesEdgeCase/
> {noformat}
> java.lang.NullPointerException
> at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:952)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:657)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:933)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:784)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:541)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I believe what is happening is a GossipDigestAck has been queued to ack the
> shutdown state from the node on the seed, but isn't actually sent until the
> node has restarted and gone into shadow. Since the ack contains the node's
> IP, it assumes a host_id will be there but since this is not an actual shadow
> response, it is not.
--
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-16609) Debian init script for 2.2.19 mostly broken on Debian 10 with systemd
[ https://issues.apache.org/jira/browse/CASSANDRA-16609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Schröder updated CASSANDRA-16609: Resolution: Duplicate Status: Resolved (was: Triage Needed) > Debian init script for 2.2.19 mostly broken on Debian 10 with systemd > - > > Key: CASSANDRA-16609 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16609 > Project: Cassandra > Issue Type: Bug >Reporter: Martin Schröder >Priority: Normal > > The debian package for 2.2.19 doesn't contain a unit file, it has (or > installs) only a script for /etc/init..d/cassandra > With systemd this script can only start the process; stoping and restarting > the service doesn't work. -- 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-15770) stop and restart fail in Debian 10 buster
[
https://issues.apache.org/jira/browse/CASSANDRA-15770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17323748#comment-17323748
]
Martin Schröder commented on CASSANDRA-15770:
-
This is also a problem in 2.2.19 - please also fix it there.
> stop and restart fail in Debian 10 buster
> -
>
> Key: CASSANDRA-15770
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15770
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Vicente Jimenez Aguilar
>Assignee: Vicente Jimenez Aguilar
>Priority: Normal
> Labels: Debian, easyfix, patch
> Fix For: 3.0.21, 3.11.7, 4.0, 4.0-beta1
>
> Attachments: 0001-Fix-init-script-for-debian-Buster.patch
>
>
> Debian 10 "buster" has an updated {{start-stop-daemon}} version that causes
> init script to fail to stop or restart Cassandra daemon. {{stop}} option do
> not stops first launched instance and depending of previous operations,
> {{restart}} and {{start}} could launch a second Cassandra daemon instance.
> {{start-stop-daemon}} since version 1.19.3 fail to stop matching only a
> pidfile that can be writen by an unprivileged (non-root) user because it is
> considered a security risk.
> Adding a second matching option (user) solved this.
> This fix does not break compatibility with older versions and does not mess
> with pidfile's mode or permissions.
> Related: CASSANDRA-15099
> https://github.com/vice/cassandra/tree/debian-buster
--
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-15770) stop and restart fail in Debian 10 buster
[
https://issues.apache.org/jira/browse/CASSANDRA-15770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Schröder updated CASSANDRA-15770:
Since Version: 2.2.19 (was: 3.0.0)
> stop and restart fail in Debian 10 buster
> -
>
> Key: CASSANDRA-15770
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15770
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Vicente Jimenez Aguilar
>Assignee: Vicente Jimenez Aguilar
>Priority: Normal
> Labels: Debian, easyfix, patch
> Fix For: 3.0.21, 3.11.7, 4.0, 4.0-beta1
>
> Attachments: 0001-Fix-init-script-for-debian-Buster.patch
>
>
> Debian 10 "buster" has an updated {{start-stop-daemon}} version that causes
> init script to fail to stop or restart Cassandra daemon. {{stop}} option do
> not stops first launched instance and depending of previous operations,
> {{restart}} and {{start}} could launch a second Cassandra daemon instance.
> {{start-stop-daemon}} since version 1.19.3 fail to stop matching only a
> pidfile that can be writen by an unprivileged (non-root) user because it is
> considered a security risk.
> Adding a second matching option (user) solved this.
> This fix does not break compatibility with older versions and does not mess
> with pidfile's mode or permissions.
> Related: CASSANDRA-15099
> https://github.com/vice/cassandra/tree/debian-buster
--
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-16609) Debian init script for 2.2.19 mostly broken on Debian 10 with systemd
Martin Schröder created CASSANDRA-16609: --- Summary: Debian init script for 2.2.19 mostly broken on Debian 10 with systemd Key: CASSANDRA-16609 URL: https://issues.apache.org/jira/browse/CASSANDRA-16609 Project: Cassandra Issue Type: Bug Reporter: Martin Schröder The debian package for 2.2.19 doesn't contain a unit file, it has (or installs) only a script for /etc/init..d/cassandra With systemd this script can only start the process; stoping and restarting the service doesn't work. -- 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-16607) Fix flaky test testRequestResponse – org.apache.cassandra.net.MockMessagingServiceTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña reassigned CASSANDRA-16607:
-
Assignee: Andres de la Peña
> Fix flaky test testRequestResponse –
> org.apache.cassandra.net.MockMessagingServiceTest
> --
>
> Key: CASSANDRA-16607
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16607
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/659/tests/
> {code}
> Error
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.net.MockMessagingServiceTest.testRequestResponse(MockMessagingServiceTest.java:81)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2021-04-15 08:22:46,838 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2021-04-15 08:22:46,840 YamlConfigurationLoader.java:112 -
> Loading settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2021-04-15 08:22:46,899 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-04-15 08:22:46,911 PlatformDependent0.java:417 -
> -Dio.netty.noUnsaf
> ...[truncated 61235 chars]...
> te NORMAL, token [a57d4b7f61f49471614b7ac41f16477e]
> DEBUG [main] 2021-04-15 08:22:49,840 StorageService.java:2674 - New node
> /127.0.0.1:7069 at token a57d4b7f61f49471614b7ac41f16477e
> DEBUG [main] 2021-04-15 08:22:49,848 StorageService.java:2727 - Node
> /127.0.0.1:7069 state NORMAL, token [a57d4b7f61f49471614b7ac41f16477e]
> INFO [main] 2021-04-15 08:22:49,848 StorageService.java:2730 - Node
> /127.0.0.1:7069 state jump to NORMAL
> DEBUG [main] 2021-04-15 08:22:49,849 StorageService.java:1619 - NORMAL
> {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-16601) Flaky CassandraIndexTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16601:
--
Reviewers: Andres de la Peña, Andres de la Peña (was: Andres de la Peña)
Andres de la Peña, Andres de la Peña (was: Andres de la Peña)
Status: Review In Progress (was: Patch Available)
> Flaky CassandraIndexTest
>
>
> Key: CASSANDRA-16601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16601
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/436/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexCorrectlyMarkedAsBuildAndRemoved_cdc/]
> {noformat}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:588)
> {noformat}
--
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-16601) Flaky CassandraIndexTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17323513#comment-17323513
]
Andres de la Peña commented on CASSANDRA-16601:
---
Great, with CASSANDRA-16595 merged we can happily wait for the cleanup tasks.
Probably {{spinAssertEquals}} can be replaced by {{Awaitabilty.await()}} to
specify a poll delay and save us the try-catch block. Also I still think we
should remove most of the changes introduced by CASSANDRA-15565 since they are
not needed anymore, as it's done
[here|https://github.com/adelapena/cassandra/blob/8cf7145b8437f616e8085169cc3829197961031c/test/unit/org/apache/cassandra/index/internal/CassandraIndexTest.java#L567-L584].
> Flaky CassandraIndexTest
>
>
> Key: CASSANDRA-16601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16601
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/436/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexCorrectlyMarkedAsBuildAndRemoved_cdc/]
> {noformat}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:588)
> {noformat}
--
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-16601) Flaky CassandraIndexTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16601:
Status: Patch Available (was: In Progress)
> Flaky CassandraIndexTest
>
>
> Key: CASSANDRA-16601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16601
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/436/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexCorrectlyMarkedAsBuildAndRemoved_cdc/]
> {noformat}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:588)
> {noformat}
--
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-16601) Flaky CassandraIndexTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322765#comment-17322765
]
Berenguer Blasi commented on CASSANDRA-16601:
-
Took ages to complete but yep, {{spinAssert}} +200 runs seems to work :-)
> Flaky CassandraIndexTest
>
>
> Key: CASSANDRA-16601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16601
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/436/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexCorrectlyMarkedAsBuildAndRemoved_cdc/]
> {noformat}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:588)
> {noformat}
--
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-16597) Introduce Maven wrapper to build for Maven-less build environments
[
https://issues.apache.org/jira/browse/CASSANDRA-16597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16597:
---
Status: Changes Suggested (was: Ready to Commit)
On further testing…
The following fails
{noformat}
ant mvn-install
…
mvn-install:
[exec] Error: Could not find or load main class
org.apache.maven.wrapper.MavenWrapperMain
[exec] Result: 1
[exec] Error: Could not find or load main class
org.apache.maven.wrapper.MavenWrapperMain
[exec] Result: 1
[exec] Error: Could not find or load main class
org.apache.maven.wrapper.MavenWrapperMain
[exec] Result: 1
[exec] Error: Could not find or load main class
org.apache.maven.wrapper.MavenWrapperMain
[exec] Result: 1
{noformat}
Also, does maven-wrapper have an offline mode? `ant mvn-install` should work
without internet.
> Introduce Maven wrapper to build for Maven-less build environments
> --
>
> Key: CASSANDRA-16597
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16597
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> With the introduction of CASSANDRA-16391, the build machine needs to have
> Maven installed locally as it executes "mvn" command in its tasks. This might
> be avoided by adding Maven wrapper which would download (and cache) such
> installation so build environment might be completely Maven-less otherwise.
--
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-16608) Nodetool verify fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-16608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16608: Test and Documentation Plan: cci run Status: Patch Available (was: Open) > Nodetool verify fixes > - > > Key: CASSANDRA-16608 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16608 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-rc1, 4.0 > > > A few issues with nodetool verify: > * Include cause exception when it fails verifying an sstable > * Don't try to check if the node owns tokens from localpartitioner sstables > * Don't try to deserialise non-existing bloom filter file -- 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-16608) Nodetool verify fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-16608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16608: Bug Category: Parent values: Degradation(12984)Level 1 values: Other Exception(12998) Complexity: Low Hanging Fruit Component/s: Local/Other Discovered By: Adhoc Test Fix Version/s: 4.0 4.0-rc1 Severity: Low Status: Open (was: Triage Needed) https://github.com/krummas/cassandra/commits/marcuse/16608 (last 3 non-cci commits) https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F16608 > Nodetool verify fixes > - > > Key: CASSANDRA-16608 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16608 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-rc1, 4.0 > > > A few issues with nodetool verify: > * Include cause exception when it fails verifying an sstable > * Don't try to check if the node owns tokens from localpartitioner sstables > * Don't try to deserialise non-existing bloom filter file -- 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-16608) Nodetool verify fixes
Marcus Eriksson created CASSANDRA-16608: --- Summary: Nodetool verify fixes Key: CASSANDRA-16608 URL: https://issues.apache.org/jira/browse/CASSANDRA-16608 Project: Cassandra Issue Type: Bug Reporter: Marcus Eriksson Assignee: Marcus Eriksson A few issues with nodetool verify: * Include cause exception when it fails verifying an sstable * Don't try to check if the node owns tokens from localpartitioner sstables * Don't try to deserialise non-existing bloom filter file -- 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
