[jira] [Commented] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17868096#comment-17868096
]
Ariel Weisberg commented on CASSANDRA-19651:
I want to make sure you aren't waiting on me. Can you create PRs for 4.0, 4.1,
5.0, and trunk? Thanks
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> org.apache.cassandra.service.AbstractWriteResponseHandler:
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17866452#comment-17866452
]
Ariel Weisberg commented on CASSANDRA-19651:
The patch attached to the ticket seems a bit out of date compared to the
branch, would be better to remove it. This will need patches for 4.0, 4.1, 5.0,
and trunk. You can skip modifying `CHANGES.txt`, I will add that when I commit.
When you do modify `CHANGES.txt` always insert your new change at the top of
the list for the version.
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: 19651-4.1.patch
>
>
> org.apache.cassandra.service.AbstractWriteResponseHandler:
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19748) [Analytics] Refactor Analytics to move standalone code into common module with minimal dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-19748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865531#comment-17865531 ] Ariel Weisberg commented on CASSANDRA-19748: +1 TY > [Analytics] Refactor Analytics to move standalone code into common module > with minimal dependencies > --- > > Key: CASSANDRA-19748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19748 > Project: Cassandra > Issue Type: Improvement > Components: Analytics Library >Reporter: James Berragan >Assignee: James Berragan >Priority: Low > Fix For: NA > > Time Spent: 4h 10m > Remaining Estimate: 0h > > The Analytics codebase is heavily tied to Spark. In an effort to re-use code > across projects (like CDC) we should move standalone Pojos and util classes > into an cassandra-analytics-common module that exists standalone without > dependencies to Cassandra or Spark and with minimal standard dependencies > (Kryo, Guava, Jackson, Apache Commons Lang etc). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19651:
---
Reviewers: Ariel Weisberg, Ariel Weisberg
Ariel Weisberg, Ariel Weisberg (was: Ariel Weisberg)
Status: Review In Progress (was: Patch Available)
Thanks for spotting this. I’ll take a look.
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: 19651-4.1.patch
>
>
> org.apache.cassandra.service.AbstractWriteResponseHandler:
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19437) Non-serial reads/range reads need to be done through Accord for Accord to support async apply/commit
[ https://issues.apache.org/jira/browse/CASSANDRA-19437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17864747#comment-17864747 ] Ariel Weisberg edited comment on CASSANDRA-19437 at 7/10/24 4:55 PM: - Another thing to keep in mind is that `TxnQuery` will need validate that range reads against Accord are against ranges that are managed by Accord in the epoch that the read executes in. `TxnQuery` also currently has a problem with its validation where it doesn't have access to the migration information for the epoch of the transaction and just has whatever the latest information is. was (Author: aweisberg): Another thing to keep in mind is that `TxnQuery` will need validate that range reads against Accord are against ranges that are managed by Accord in the epoch that the read executes in. > Non-serial reads/range reads need to be done through Accord for Accord to > support async apply/commit > > > Key: CASSANDRA-19437 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19437 > Project: Cassandra > Issue Type: Bug >Reporter: Ariel Weisberg >Priority: Normal > > Currently they haven't been implemented. We have a path forward for it using > ephemeral reads. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19437) Non-serial reads/range reads need to be done through Accord for Accord to support async apply/commit
[ https://issues.apache.org/jira/browse/CASSANDRA-19437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17864747#comment-17864747 ] Ariel Weisberg commented on CASSANDRA-19437: Another thing to keep in mind is that `TxnQuery` will need validate that range reads against Accord are against ranges that are managed by Accord in the epoch that the read executes in. > Non-serial reads/range reads need to be done through Accord for Accord to > support async apply/commit > > > Key: CASSANDRA-19437 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19437 > Project: Cassandra > Issue Type: Bug >Reporter: Ariel Weisberg >Priority: Normal > > Currently they haven't been implemented. We have a path forward for it using > ephemeral reads. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19436) When transitioning to Accord migration it's not safe to read immediately using Accord due to concurrent non-serial writes
[ https://issues.apache.org/jira/browse/CASSANDRA-19436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19436: --- Description: Concurrent writes at the same time that migration starts make it unsafe to read from Accord because txn recovery will not be deterministic in the presences of writes not done through Accord. Migration to Accord needs to be split into two phases, in the first phase we write through Accord and always respect the consistency level and do synchronous commit. This allows Paxos and non-serial writes to continue while Accord's metadata covers everything needed for future reads. Paxos continues to operate as normal since it has enough metadata to allow key migration in the second phase and we need to stay online so something needs to handle LWTs. Then repair runs and makes it possible for Accord to read any data written non-transactionally and we can then do key migration and route all updates (conditional or blind) through Accord while Paxos repair runs so we can stop doing key migration. was: Concurrent writes at the same time that migration starts make it unsafe to read from Accord because txn recovery will not be deterministic in the presences of writes not done through Accord. Adding key migration to non-serial writes could solve this by causing writes not going through Accord to be rejected at nodes where key migration already occurred. > When transitioning to Accord migration it's not safe to read immediately > using Accord due to concurrent non-serial writes > - > > Key: CASSANDRA-19436 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19436 > Project: Cassandra > Issue Type: Bug >Reporter: Ariel Weisberg >Priority: Normal > > Concurrent writes at the same time that migration starts make it unsafe to > read from Accord because txn recovery will not be deterministic in the > presences of writes not done through Accord. > Migration to Accord needs to be split into two phases, in the first phase we > write through Accord and always respect the consistency level and do > synchronous commit. This allows Paxos and non-serial writes to continue while > Accord's metadata covers everything needed for future reads. Paxos continues > to operate as normal since it has enough metadata to allow key migration in > the second phase and we need to stay online so something needs to handle LWTs. > Then repair runs and makes it possible for Accord to read any data written > non-transactionally and we can then do key migration and route all updates > (conditional or blind) through Accord while Paxos repair runs so we can stop > doing key migration. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19687) ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch
[ https://issues.apache.org/jira/browse/CASSANDRA-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19687: --- Source Control Link: [37c957c719491634f081b39900ebf708079ef3ee|https://github.com/apache/cassandra-accord/commit/37c957c719491634f081b39900ebf708079ef3ee] [24fb418adb70f37dfd717fef2a2f33a8802https://github.com/apache/cassandra/commit/24fb418adb70f37dfd717fef2a2f33a8802f21a7] (was: https://github.com/apache/cassandra-accord/commit/37c957c719491634f081b39900ebf708079ef3ee https://github.com/apache/cassandra/commit/24fb418adb70f37dfd717fef2a2f33a8802f21a7) > ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch > - > > Key: CASSANDRA-19687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19687 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 5.1 > > Attachments: ci_summary.html > > > It's from the `txnId` not the `executeAt` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19687) ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch
[ https://issues.apache.org/jira/browse/CASSANDRA-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19687: --- Source Control Link: https://github.com/apache/cassandra-accord/commit/37c957c719491634f081b39900ebf708079ef3ee 24fb418adb70f37dfd717fef2a2f33a8802https://github.com/apache/cassandra/commit/24fb418adb70f37dfd717fef2a2f33a8802f21a7 (was: [37c957c719491634f081b39900ebf708079ef3ee|https://github.com/apache/cassandra-accord/commit/37c957c719491634f081b39900ebf708079ef3ee] [24fb418adb70f37dfd717fef2a2f33a8802https://github.com/apache/cassandra/commit/24fb418adb70f37dfd717fef2a2f33a8802f21a7]) > ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch > - > > Key: CASSANDRA-19687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19687 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 5.1 > > Attachments: ci_summary.html > > > It's from the `txnId` not the `executeAt` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19687) ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch
[ https://issues.apache.org/jira/browse/CASSANDRA-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19687: --- Source Control Link: https://github.com/apache/cassandra-accord/commit/37c957c719491634f081b39900ebf708079ef3ee https://github.com/apache/cassandra/commit/24fb418adb70f37dfd717fef2a2f33a8802f21a7 (was: https://github.com/apache/cassandra-accord/commit/37c957c719491634f081b39900ebf708079ef3ee,https://github.com/apache/cassandra/commit/24fb418adb70f37dfd717fef2a2f33a8802f21a7) > ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch > - > > Key: CASSANDRA-19687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19687 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 5.1 > > Attachments: ci_summary.html > > > It's from the `txnId` not the `executeAt` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19687) ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch
[ https://issues.apache.org/jira/browse/CASSANDRA-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19687: --- Fix Version/s: 5.1 Since Version: 5.1 Source Control Link: https://github.com/apache/cassandra-accord/commit/37c957c719491634f081b39900ebf708079ef3ee,https://github.com/apache/cassandra/commit/24fb418adb70f37dfd717fef2a2f33a8802f21a7 Resolution: Fixed Status: Resolved (was: Ready to Commit) > ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch > - > > Key: CASSANDRA-19687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19687 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 5.1 > > Attachments: ci_summary.html > > > It's from the `txnId` not the `executeAt` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19687) ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch
[ https://issues.apache.org/jira/browse/CASSANDRA-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19687: --- Source Control Link: https://github.com/apache/cassandra-accord/commit/37c957c719491634f081b39900ebf708079ef3ee https://github.com/apache/cassandra/commit/24fb418adb70f37dfd717fef2a2f33a8802f21a7 (was: https://github.com/apache/cassandra-accord/commit/37c957c719491634f081b39900ebf708079ef3ee 24fb418adb70f37dfd717fef2a2f33a8802https://github.com/apache/cassandra/commit/24fb418adb70f37dfd717fef2a2f33a8802f21a7) > ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch > - > > Key: CASSANDRA-19687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19687 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 5.1 > > Attachments: ci_summary.html > > > It's from the `txnId` not the `executeAt` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19687) ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch
[ https://issues.apache.org/jira/browse/CASSANDRA-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19687: --- Status: Ready to Commit (was: Review In Progress) Committed as Accord [37c957c719491634f081b39900ebf708079ef3ee|https://github.com/apache/cassandra-accord/commit/37c957c719491634f081b39900ebf708079ef3ee] and Cassandra [24fb418adb70f37dfd717fef2a2f33a8802f21a7|https://github.com/apache/cassandra/commit/24fb418adb70f37dfd717fef2a2f33a8802f21a7] > ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch > - > > Key: CASSANDRA-19687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19687 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Attachments: ci_summary.html > > > It's from the `txnId` not the `executeAt` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19687) ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch
[ https://issues.apache.org/jira/browse/CASSANDRA-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19687: --- Reviewers: Benedict Elliott Smith, Ariel Weisberg (was: Benedict Elliott Smith) Benedict Elliott Smith, Ariel Weisberg (was: Ariel Weisberg, Benedict Elliott Smith) Status: Review In Progress (was: Patch Available) > ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch > - > > Key: CASSANDRA-19687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19687 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Attachments: ci_summary.html > > > It's from the `txnId` not the `executeAt` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19737) Accord migration mode FULL always runs with interop
[ https://issues.apache.org/jira/browse/CASSANDRA-19737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863829#comment-17863829 ] Ariel Weisberg edited comment on CASSANDRA-19737 at 7/8/24 3:22 PM: I should add that some of interop might be working as expected with FULL because even though it's an interop execution we do handle consistency levels different and provide null for the read and commit CLs to the interop code and I see code that should handle this. Where I thought I saw an issue was the read for Accord occurring through the interop read path which is a read executor and that surprised me as it pretty much obsoletes Accord's internal read path. was (Author: aweisberg): I should add that some of interop might be working as expected with FULL because even though it's an interop execution we do handle consistency levels different and provide null for the read and commit CLs to the interop code and I see code that should handle this. Where I saw issues was read repair occurring when I thought the transactional mode was full. > Accord migration mode FULL always runs with interop > --- > > Key: CASSANDRA-19737 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19737 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > Whether we use interop is not done per transaction. Accord always seems to > run with interop for every transaction when it is constructed with the > factory that creates interop execution. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19737) Accord migration mode FULL always runs with interop
[ https://issues.apache.org/jira/browse/CASSANDRA-19737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863829#comment-17863829 ] Ariel Weisberg commented on CASSANDRA-19737: I should add that some of interop might be working as expected with FULL because even though it's an interop execution we do handle consistency levels different and provide null for the read and commit CLs to the interop code and I see code that should handle this. Where I saw issues was read repair occurring when I thought the transactional mode was full. > Accord migration mode FULL always runs with interop > --- > > Key: CASSANDRA-19737 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19737 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > Whether we use interop is not done per transaction. Accord always seems to > run with interop for every transaction when it is constructed with the > factory that creates interop execution. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19419) Non-transactional schema updates can interfere with Accord transaction execution
[ https://issues.apache.org/jira/browse/CASSANDRA-19419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19419: --- Summary: Non-transactional schema updates can interfere with Accord transaction execution (was: Non-transactional schema updates can interfere with Accord transaction execuion) > Non-transactional schema updates can interfere with Accord transaction > execution > > > Key: CASSANDRA-19419 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19419 > Project: Cassandra > Issue Type: Bug >Reporter: Ariel Weisberg >Priority: Normal > > While Accord can handle topology changes correctly it can’t handle > non-transaction schema updates because those execute outside of Accord. When > Accord tries to execute a transaction against the schema in the epoch the > transaction is supposed to execute in then it is possible for different nodes > to see different schemas when reading or writing data as part of a > transaction. > Dropping a needed a column or table is the most likely issue as we don't > support altering column types. > Because commit is async it is possible for a table or to be dropped before > the writes can be propagated after it was acknowledged instead of signaling > an error. While the table was dropped it's possible the client needed the > error to know that the request was processed improperly or that it needed to > take some other action client side. > Or add table where the original coordinator can't read the table, but the > recovery coordinator can and might apply different results to different > replicas. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19744) Accord migration and interop correctness
Ariel Weisberg created CASSANDRA-19744: -- Summary: Accord migration and interop correctness Key: CASSANDRA-19744 URL: https://issues.apache.org/jira/browse/CASSANDRA-19744 Project: Cassandra Issue Type: Bug Components: Accord Reporter: Ariel Weisberg Assignee: Ariel Weisberg There are several issues around splitting and retrying mutations, using the original timestamp for batchlog/hints, batchlog/hint support in general, running Accord barriers only against the ranges actually owned by Accord. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19737) Accord migration mode FULL always runs with interop
Ariel Weisberg created CASSANDRA-19737: -- Summary: Accord migration mode FULL always runs with interop Key: CASSANDRA-19737 URL: https://issues.apache.org/jira/browse/CASSANDRA-19737 Project: Cassandra Issue Type: Bug Components: Accord Reporter: Ariel Weisberg Whether we use interop is not done per transaction. Accord always seems to run with interop for every transaction when it is constructed with the factory that creates interop execution. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19737) Accord migration mode FULL always runs with interop
[ https://issues.apache.org/jira/browse/CASSANDRA-19737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg reassigned CASSANDRA-19737: -- Assignee: Ariel Weisberg > Accord migration mode FULL always runs with interop > --- > > Key: CASSANDRA-19737 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19737 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > Whether we use interop is not done per transaction. Accord always seems to > run with interop for every transaction when it is constructed with the > factory that creates interop execution. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19736) Batchlog and hint replay have timestamps replaced by Accord
[ https://issues.apache.org/jira/browse/CASSANDRA-19736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19736: --- Bug Category: Parent values: Correctness(12982)Level 1 values: Unrecoverable Corruption / Loss(13161) Complexity: Normal Discovered By: Code Inspection Severity: Critical Status: Open (was: Triage Needed) > Batchlog and hint replay have timestamps replaced by Accord > --- > > Key: CASSANDRA-19736 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19736 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > The issue is that we might create the transaction at a much later time and > then the operation would be written to Cassandra with a later timestamp. It > should be fine to use the minimum of the two. > This also means that `USING TIMESTAMP` will also work as long as the provided > timestamp is < the Accord timestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19736) Batchlog and hint replay have timestamps replaced by Accord
[ https://issues.apache.org/jira/browse/CASSANDRA-19736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg reassigned CASSANDRA-19736: -- Assignee: Ariel Weisberg > Batchlog and hint replay have timestamps replaced by Accord > --- > > Key: CASSANDRA-19736 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19736 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > The issue is that we might create the transaction at a much later time and > then the operation would be written to Cassandra with a later timestamp. It > should be fine to use the minimum of the two. > This also means that `USING TIMESTAMP` will also work as long as the provided > timestamp is < the Accord timestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19736) Batchlog and hint replay have timestamps replaced by Accord
Ariel Weisberg created CASSANDRA-19736: -- Summary: Batchlog and hint replay have timestamps replaced by Accord Key: CASSANDRA-19736 URL: https://issues.apache.org/jira/browse/CASSANDRA-19736 Project: Cassandra Issue Type: Bug Components: Accord Reporter: Ariel Weisberg The issue is that we might create the transaction at a much later time and then the operation would be written to Cassandra with a later timestamp. It should be fine to use the minimum of the two. This also means that `USING TIMESTAMP` will also work as long as the provided timestamp is < the Accord timestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19718) CEP-15: (Accord) SyncPoint timeouts become a Exhausted rather than a Timeout and doesn’t get retried
[ https://issues.apache.org/jira/browse/CASSANDRA-19718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19718: --- Reviewers: Ariel Weisberg > CEP-15: (Accord) SyncPoint timeouts become a Exhausted rather than a Timeout > and doesn’t get retried > > > Key: CASSANDRA-19718 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19718 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > In Cassandra we try to make sure coordinators return timeout if every call > under it was also a timeout, this makes it easier to understand what is going > on (coordination failure due to timeouts looks very different than us just > timing out), but accord doesn't do this; leading to an Exhausted error (which > we don't retry) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19687) ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch
[ https://issues.apache.org/jira/browse/CASSANDRA-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19687: --- Attachment: ci_summary.html > ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch > - > > Key: CASSANDRA-19687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19687 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Attachments: ci_summary.html > > > It's from the `txnId` not the `executeAt` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19687) ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch
[ https://issues.apache.org/jira/browse/CASSANDRA-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19687: --- Test and Documentation Plan: Burn test Status: Patch Available (was: Open) > ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch > - > > Key: CASSANDRA-19687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19687 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > It's from the `txnId` not the `executeAt` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19687) ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch
[ https://issues.apache.org/jira/browse/CASSANDRA-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19687: --- Bug Category: Parent values: Correctness(12982) Complexity: Normal Discovered By: Fuzz Test Reviewers: Benedict Elliott Smith Severity: Normal Status: Open (was: Triage Needed) > ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch > - > > Key: CASSANDRA-19687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19687 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > It's from the `txnId` not the `executeAt` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19687) ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch
Ariel Weisberg created CASSANDRA-19687: -- Summary: ApplyThenWaitUntilApplied supplies wrong epoch for executeAtEpoch Key: CASSANDRA-19687 URL: https://issues.apache.org/jira/browse/CASSANDRA-19687 Project: Cassandra Issue Type: Bug Components: Accord Reporter: Ariel Weisberg Assignee: Ariel Weisberg It's from the `txnId` not the `executeAt` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19641) Accord barriers/inclusive sync points cause failures in BurnTest
[ https://issues.apache.org/jira/browse/CASSANDRA-19641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19641: --- Fix Version/s: 5.x Since Version: 5.x Source Control Link: https://github.com/apache/cassandra/commit/3b99044d6d5491304d4a25d8dcea54510cfd3215 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as Cassandra and Accord [4e8bcae81f9751b9d732fd5056bce31c97ad58f3|https://github.com/apache/cassandra-accord/commit/4e8bcae81f9751b9d732fd5056bce31c97ad58f3]. > Accord barriers/inclusive sync points cause failures in BurnTest > > > Key: CASSANDRA-19641 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19641 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary.html > > > The burn test fails almost every run at the moment we found several things to > fix. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19641) Accord barriers/inclusive sync points cause failures in BurnTest
[ https://issues.apache.org/jira/browse/CASSANDRA-19641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19641: --- Status: Ready to Commit (was: Review In Progress) > Accord barriers/inclusive sync points cause failures in BurnTest > > > Key: CASSANDRA-19641 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19641 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Attachments: ci_summary.html > > > The burn test fails almost every run at the moment we found several things to > fix. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19641) Accord barriers/inclusive sync points cause failures in BurnTest
[ https://issues.apache.org/jira/browse/CASSANDRA-19641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19641: --- Reviewers: Benedict Elliott Smith, Ariel Weisberg Benedict Elliott Smith, Ariel Weisberg (was: Ariel Weisberg, Benedict Elliott Smith) Status: Review In Progress (was: Patch Available) > Accord barriers/inclusive sync points cause failures in BurnTest > > > Key: CASSANDRA-19641 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19641 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Attachments: ci_summary.html > > > The burn test fails almost every run at the moment we found several things to > fix. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19641) Accord barriers/inclusive sync points cause failures in BurnTest
[ https://issues.apache.org/jira/browse/CASSANDRA-19641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19641: --- Attachment: ci_summary.html > Accord barriers/inclusive sync points cause failures in BurnTest > > > Key: CASSANDRA-19641 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19641 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Attachments: ci_summary.html > > > The burn test fails almost every run at the moment we found several things to > fix. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19641) Accord barriers/inclusive sync points cause failures in BurnTest
[ https://issues.apache.org/jira/browse/CASSANDRA-19641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19641: --- Test and Documentation Plan: Small tweaks to one of the Accord tests, covered by existing simulator tests, going to add checks in AccordMigrationTest that validate that the cache and system table for migrated keys is being correctly populated Status: Patch Available (was: Open) > Accord barriers/inclusive sync points cause failures in BurnTest > > > Key: CASSANDRA-19641 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19641 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > The burn test fails almost every run at the moment we found several things to > fix. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19641) Accord barriers/inclusive sync points cause failures in BurnTest
[ https://issues.apache.org/jira/browse/CASSANDRA-19641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19641: --- Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Discovered By: Fuzz Test Severity: Normal Status: Open (was: Triage Needed) > Accord barriers/inclusive sync points cause failures in BurnTest > > > Key: CASSANDRA-19641 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19641 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > The burn test fails almost every run at the moment we found several things to > fix. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19641) Accord barriers/inclusive sync points cause failures in BurnTest
Ariel Weisberg created CASSANDRA-19641: -- Summary: Accord barriers/inclusive sync points cause failures in BurnTest Key: CASSANDRA-19641 URL: https://issues.apache.org/jira/browse/CASSANDRA-19641 Project: Cassandra Issue Type: Bug Components: Accord Reporter: Ariel Weisberg Assignee: Ariel Weisberg The burn test fails almost every run at the moment we found several things to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847378#comment-17847378
]
Ariel Weisberg commented on CASSANDRA-19636:
I didn't test this yet (still working on getting the existing changes to run),
but +1 on what I saw in the PR and its description.
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846980#comment-17846980
]
Ariel Weisberg edited comment on CASSANDRA-19636 at 5/16/24 2:37 PM:
-
Great!
I assume separately the [[upgrade_manifest.py|http://example.com]] to not
depend on the JAVAX_HOME so we have a more canonical set of things to test?
was (Author: aweisberg):
Great!
I assume separately the
[upgrade_manifest.py](https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py#L228)
to not depend on the JAVAX_HOME so we have a more canonical set of things to
test?
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846980#comment-17846980
]
Ariel Weisberg edited comment on CASSANDRA-19636 at 5/16/24 2:37 PM:
-
Great!
I assume separately the [upgrade_manifest.py|http://example.com] to not depend
on the JAVAX_HOME so we have a more canonical set of things to test?
was (Author: aweisberg):
Great!
I assume separately the [[upgrade_manifest.py|http://example.com]] to not
depend on the JAVAX_HOME so we have a more canonical set of things to test?
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846980#comment-17846980
]
Ariel Weisberg commented on CASSANDRA-19636:
Great!
I assume separately the
[upgrade_manifest.py](https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py#L228)
to not depend on the JAVAX_HOME so we have a more canonical set of things to
test?
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846957#comment-17846957
]
Ariel Weisberg commented on CASSANDRA-19636:
In terms of future direction for CCM behavior. If CCM automatically selecting a
compatible version goes away we should minimize the number of things you need
to manage to make CCM do the thing.
* Ignore PATH and only use JAVA_HOME
* If JAVA_HOME JDK is incompatible return an error
* Allowing specifying JDK version as a parameter and then look up the actual
JDK location from JAVAX_HOME
Existing users now don't need to modify environment variables to do whatever it
is they are trying to do with CCM.
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19596) IntervalTree build throughput is low enough to be a bottleneck
[ https://issues.apache.org/jira/browse/CASSANDRA-19596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19596: --- Attachment: ci_summary.html > IntervalTree build throughput is low enough to be a bottleneck > -- > > Key: CASSANDRA-19596 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19596 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Local/SSTable >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary.html > > > With several terabytes of data and 8 compactors it’s possible for the > compactors to spend a lot of time blocked waiting on IntervalTrees to be > built. > There is also a lot of wasted CPU because it’s updated optimistically so most > of them end up being thrown away. > This can end up being quite painful because it can block memtable flushing as > well and then a single slow CFS can block unrelated CFS because the memtable > post flush executor is single threaded and shared across all CFS. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19596) IntervalTree build throughput is low enough to be a bottleneck
[ https://issues.apache.org/jira/browse/CASSANDRA-19596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845106#comment-17845106 ] Ariel Weisberg commented on CASSANDRA-19596: This is a quick and dirty improvement that removes the redundant sorting and replaces it with re-use of the existing sorted data. So instead of having to repeat the n * Lg(n) sort to construct every node we only have to do linear scans of the already sorted data that is in that nodes subtree. > IntervalTree build throughput is low enough to be a bottleneck > -- > > Key: CASSANDRA-19596 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19596 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Local/SSTable >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 5.x > > > With several terabytes of data and 8 compactors it’s possible for the > compactors to spend a lot of time blocked waiting on IntervalTrees to be > built. > There is also a lot of wasted CPU because it’s updated optimistically so most > of them end up being thrown away. > This can end up being quite painful because it can block memtable flushing as > well and then a single slow CFS can block unrelated CFS because the memtable > post flush executor is single threaded and shared across all CFS. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19596) IntervalTree build throughput is low enough to be a bottleneck
[ https://issues.apache.org/jira/browse/CASSANDRA-19596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19596: --- Change Category: Performance Complexity: Low Hanging Fruit Fix Version/s: 5.x Status: Open (was: Triage Needed) > IntervalTree build throughput is low enough to be a bottleneck > -- > > Key: CASSANDRA-19596 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19596 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Local/SSTable >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 5.x > > > With several terabytes of data and 8 compactors it’s possible for the > compactors to spend a lot of time blocked waiting on IntervalTrees to be > built. > There is also a lot of wasted CPU because it’s updated optimistically so most > of them end up being thrown away. > This can end up being quite painful because it can block memtable flushing as > well and then a single slow CFS can block unrelated CFS because the memtable > post flush executor is single threaded and shared across all CFS. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19596) IntervalTree build throughput is low enough to be a bottleneck
[ https://issues.apache.org/jira/browse/CASSANDRA-19596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19596: --- Test and Documentation Plan: Existing units tests + a new QT based test Status: Patch Available (was: Open) > IntervalTree build throughput is low enough to be a bottleneck > -- > > Key: CASSANDRA-19596 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19596 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Local/SSTable >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 5.x > > > With several terabytes of data and 8 compactors it’s possible for the > compactors to spend a lot of time blocked waiting on IntervalTrees to be > built. > There is also a lot of wasted CPU because it’s updated optimistically so most > of them end up being thrown away. > This can end up being quite painful because it can block memtable flushing as > well and then a single slow CFS can block unrelated CFS because the memtable > post flush executor is single threaded and shared across all CFS. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19596) IntervalTree build throughput is low enough to be a bottleneck
[ https://issues.apache.org/jira/browse/CASSANDRA-19596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg reassigned CASSANDRA-19596: -- Assignee: Ariel Weisberg > IntervalTree build throughput is low enough to be a bottleneck > -- > > Key: CASSANDRA-19596 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19596 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Local/SSTable >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > With several terabytes of data and 8 compactors it’s possible for the > compactors to spend a lot of time blocked waiting on IntervalTrees to be > built. > There is also a lot of wasted CPU because it’s updated optimistically so most > of them end up being thrown away. > This can end up being quite painful because it can block memtable flushing as > well and then a single slow CFS can block unrelated CFS because the memtable > post flush executor is single threaded and shared across all CFS. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19597) SystemKeyspace CFS flushing blocked by unrelated keyspace flushing/compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-19597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842456#comment-17842456 ] Ariel Weisberg commented on CASSANDRA-19597: I have a patch for this. I think I need to add a test as flushing and doing post flush things in order doesn't seem like it is very well covered. `CommitLogTest` has something, but it doesn't look like it actually checks that the post flush stuff runs in order or makes it run out of order. CFS also doesn't look very testable so I need to spend some time figuring out how to test it without making a mess. > SystemKeyspace CFS flushing blocked by unrelated keyspace flushing/compaction > - > > Key: CASSANDRA-19597 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19597 > Project: Cassandra > Issue Type: Bug > Components: Local/Memtable >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Attachments: ci_summary.html > > > There is a single post flush thread and that thread processes tasks in order > and one of those tasks can be a memtable flush for an unrelated keyspace/cfs, > and that memtable flush can be blocked by slow IntervalTree building and > racing with compactors to try and build an interval tree. > Unless there is a requirement for ordering we probably want to loosen this to > the actual ordering requirement so that problems in one keyspace can’t effect > another. > SystemKeyspace and Gossip in particular cause lots of weird problems like > nodes marking each other down because Gossip can’t process nodes being > removed (blocking flush each time in SystemKeyspace.removeNode) > A very simple fix here might be to queue the post flush task at the same time > as the flush in a per CFS queue, and then submit the task only once the flush > is completed. > If flushes complete out of order the queue will still ensure their > completions are processed in order. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19597) SystemKeyspace CFS flushing blocked by unrelated keyspace flushing/compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-19597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19597: --- Attachment: ci_summary.html > SystemKeyspace CFS flushing blocked by unrelated keyspace flushing/compaction > - > > Key: CASSANDRA-19597 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19597 > Project: Cassandra > Issue Type: Bug > Components: Local/Memtable >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Attachments: ci_summary.html > > > There is a single post flush thread and that thread processes tasks in order > and one of those tasks can be a memtable flush for an unrelated keyspace/cfs, > and that memtable flush can be blocked by slow IntervalTree building and > racing with compactors to try and build an interval tree. > Unless there is a requirement for ordering we probably want to loosen this to > the actual ordering requirement so that problems in one keyspace can’t effect > another. > SystemKeyspace and Gossip in particular cause lots of weird problems like > nodes marking each other down because Gossip can’t process nodes being > removed (blocking flush each time in SystemKeyspace.removeNode) > A very simple fix here might be to queue the post flush task at the same time > as the flush in a per CFS queue, and then submit the task only once the flush > is completed. > If flushes complete out of order the queue will still ensure their > completions are processed in order. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19597) SystemKeyspace CFS flushing blocked by unrelated keyspace flushing/compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-19597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19597: --- Bug Category: Parent values: Availability(12983)Level 1 values: Unavailable(12994) Complexity: Normal Component/s: Local/Memtable Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > SystemKeyspace CFS flushing blocked by unrelated keyspace flushing/compaction > - > > Key: CASSANDRA-19597 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19597 > Project: Cassandra > Issue Type: Bug > Components: Local/Memtable >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > There is a single post flush thread and that thread processes tasks in order > and one of those tasks can be a memtable flush for an unrelated keyspace/cfs, > and that memtable flush can be blocked by slow IntervalTree building and > racing with compactors to try and build an interval tree. > Unless there is a requirement for ordering we probably want to loosen this to > the actual ordering requirement so that problems in one keyspace can’t effect > another. > SystemKeyspace and Gossip in particular cause lots of weird problems like > nodes marking each other down because Gossip can’t process nodes being > removed (blocking flush each time in SystemKeyspace.removeNode) > A very simple fix here might be to queue the post flush task at the same time > as the flush in a per CFS queue, and then submit the task only once the flush > is completed. > If flushes complete out of order the queue will still ensure their > completions are processed in order. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19597) SystemKeyspace CFS flushing blocked by unrelated keyspace flushing/compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-19597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842091#comment-17842091 ] Ariel Weisberg commented on CASSANDRA-19597: [~benedict] is the requirement for post flush processing that it be done in order per CFS so a per CFS queue would actually address the problem of keeping the post flush processing in order? > SystemKeyspace CFS flushing blocked by unrelated keyspace flushing/compaction > - > > Key: CASSANDRA-19597 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19597 > Project: Cassandra > Issue Type: Bug >Reporter: Ariel Weisberg >Priority: Normal > > There is a single post flush thread and that thread processes tasks in order > and one of those tasks can be a memtable flush for an unrelated keyspace/cfs, > and that memtable flush can be blocked by slow IntervalTree building and > racing with compactors to try and build an interval tree. > Unless there is a requirement for ordering we probably want to loosen this to > the actual ordering requirement so that problems in one keyspace can’t effect > another. > SystemKeyspace and Gossip in particular cause lots of weird problems like > nodes marking each other down because Gossip can’t process nodes being > removed (blocking flush each time in SystemKeyspace.removeNode) > A very simple fix here might be to queue the post flush task at the same time > as the flush in a per CFS queue, and then submit the task only once the flush > is completed. > If flushes complete out of order the queue will still ensure their > completions are processed in order. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19597) SystemKeyspace CFS flushing blocked by unrelated keyspace flushing/compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-19597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg reassigned CASSANDRA-19597: -- Assignee: Ariel Weisberg > SystemKeyspace CFS flushing blocked by unrelated keyspace flushing/compaction > - > > Key: CASSANDRA-19597 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19597 > Project: Cassandra > Issue Type: Bug >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > There is a single post flush thread and that thread processes tasks in order > and one of those tasks can be a memtable flush for an unrelated keyspace/cfs, > and that memtable flush can be blocked by slow IntervalTree building and > racing with compactors to try and build an interval tree. > Unless there is a requirement for ordering we probably want to loosen this to > the actual ordering requirement so that problems in one keyspace can’t effect > another. > SystemKeyspace and Gossip in particular cause lots of weird problems like > nodes marking each other down because Gossip can’t process nodes being > removed (blocking flush each time in SystemKeyspace.removeNode) > A very simple fix here might be to queue the post flush task at the same time > as the flush in a per CFS queue, and then submit the task only once the flush > is completed. > If flushes complete out of order the queue will still ensure their > completions are processed in order. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19597) SystemKeyspace CFS flushing blocked by unrelated keyspace flushing/compaction
Ariel Weisberg created CASSANDRA-19597: -- Summary: SystemKeyspace CFS flushing blocked by unrelated keyspace flushing/compaction Key: CASSANDRA-19597 URL: https://issues.apache.org/jira/browse/CASSANDRA-19597 Project: Cassandra Issue Type: Bug Reporter: Ariel Weisberg There is a single post flush thread and that thread processes tasks in order and one of those tasks can be a memtable flush for an unrelated keyspace/cfs, and that memtable flush can be blocked by slow IntervalTree building and racing with compactors to try and build an interval tree. Unless there is a requirement for ordering we probably want to loosen this to the actual ordering requirement so that problems in one keyspace can’t effect another. SystemKeyspace and Gossip in particular cause lots of weird problems like nodes marking each other down because Gossip can’t process nodes being removed (blocking flush each time in SystemKeyspace.removeNode) A very simple fix here might be to queue the post flush task at the same time as the flush in a per CFS queue, and then submit the task only once the flush is completed. If flushes complete out of order the queue will still ensure their completions are processed in order. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19596) IntervalTree build throughput is low enough to be a bottleneck
Ariel Weisberg created CASSANDRA-19596: -- Summary: IntervalTree build throughput is low enough to be a bottleneck Key: CASSANDRA-19596 URL: https://issues.apache.org/jira/browse/CASSANDRA-19596 Project: Cassandra Issue Type: Improvement Components: Local/Compaction, Local/SSTable Reporter: Ariel Weisberg With several terabytes of data and 8 compactors it’s possible for the compactors to spend a lot of time blocked waiting on IntervalTrees to be built. There is also a lot of wasted CPU because it’s updated optimistically so most of them end up being thrown away. This can end up being quite painful because it can block memtable flushing as well and then a single slow CFS can block unrelated CFS because the memtable post flush executor is single threaded and shared across all CFS. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19551) CCM nodes share the same environment variable map breaking upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837791#comment-17837791
]
Ariel Weisberg commented on CASSANDRA-19551:
TY!
> CCM nodes share the same environment variable map breaking upgrade tests
>
>
> Key: CASSANDRA-19551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.31, 3.11.17, 4.0.13, 5.0-beta2, 5.1
>
> Attachments: ci_summary.html
>
>
> In {{node.py}} {{__environment_variables}} is generally always set with a map
> that is passed in from {{cluster.py}} so it is [shared between
> nodes|https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151]
> and if nodes modify the map, such as in {{start}} when [updating the Java
> version|https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860]
> then when {{get_env}} runs it will [overwrite the Java
> version|https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244]
> that is selected by {{update_java_version}}.
> This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
> some of the upgrade tests because after the first node upgrades to 4.0 it's
> not longer possible for the subsequent nodes to select a Java version that
> isn't 11 because it's overridden by {{__environment_variables}}.
> I'm not even 100% clear on why the code in {{start}} should update
> {{__environment_variables}} at all if we calculate the correct java version
> on every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19551) CCM nodes share the same environment variable map breaking upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19551:
---
Description:
In {{node.py}} {{__environment_variables}} is generally always set with a map
that is passed in from {{cluster.py}} so it is [shared between
nodes|https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151]
and if nodes modify the map, such as in {{start}} when [updating the Java
version|https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860]
then when {{get_env}} runs it will [overwrite the Java
version|https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244]
that is selected by {{update_java_version}}.
This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
some of the upgrade tests because after the first node upgrades to 4.0 it's not
longer possible for the subsequent nodes to select a Java version that isn't 11
because it's overridden by {{__environment_variables}}.
I'm not even 100% clear on why the code in {{start}} should update
{{__environment_variables}} at all if we calculate the correct java version on
every invocation of other tools.
was:
In {{node.py}} {{__environment_variables}} is generally always set with a map
that is passed in from {{cluster.py}} so it is [shared between
nodes](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151)
and if nodes modify the map, such as in {{start}} when [updating the Java
version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860)
then when {{get_env}} runs it will [overwrite the Java
version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244)
that is selected by {{update_java_version}}.
This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
some of the upgrade tests because after the first node upgrades to 4.0 it's not
longer possible for the subsequent nodes to select a Java version that isn't 11
because it's overridden by {{__environment_variables}}.
I'm not even 100% clear on why the code in {{start}} should update
{{__environment_variables}} at all if we calculate the correct java version on
every invocation of other tools.
> CCM nodes share the same environment variable map breaking upgrade tests
>
>
> Key: CASSANDRA-19551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> In {{node.py}} {{__environment_variables}} is generally always set with a map
> that is passed in from {{cluster.py}} so it is [shared between
> nodes|https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151]
> and if nodes modify the map, such as in {{start}} when [updating the Java
> version|https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860]
> then when {{get_env}} runs it will [overwrite the Java
> version|https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244]
> that is selected by {{update_java_version}}.
> This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
> some of the upgrade tests because after the first node upgrades to 4.0 it's
> not longer possible for the subsequent nodes to select a Java version that
> isn't 11 because it's overridden by {{__environment_variables}}.
> I'm not even 100% clear on why the code in {{start}} should update
> {{__environment_variables}} at all if we calculate the correct java version
> on every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19551) CCM nodes share the same environment variable map breaking upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837447#comment-17837447
]
Ariel Weisberg edited comment on CASSANDRA-19551 at 4/15/24 9:12 PM:
-
Looks like {{TestGossip::test_assassinate_valid_node}} and
{{TestLargeColumn::test_cleanup}} consistently every time the past 5 runs, but
{{bootstrap_test.py::TestBootstrap::test_cleanup}} I haven't seen a failure for.
was (Author: aweisberg):
Looks like `TestGossip::test_assassinate_valid_node` and
`TestLargeColumn::test_cleanup` consistently every time the past 5 runs, but
`bootstrap_test.py::TestBootstrap::test_cleanup` I haven't seen a failure for.
> CCM nodes share the same environment variable map breaking upgrade tests
>
>
> Key: CASSANDRA-19551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> In {{node.py}} {{__environment_variables}} is generally always set with a map
> that is passed in from {{cluster.py}} so it is [shared between
> nodes](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151)
> and if nodes modify the map, such as in {{start}} when [updating the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860)
> then when {{get_env}} runs it will [overwrite the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244)
> that is selected by {{update_java_version}}.
> This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
> some of the upgrade tests because after the first node upgrades to 4.0 it's
> not longer possible for the subsequent nodes to select a Java version that
> isn't 11 because it's overridden by {{__environment_variables}}.
> I'm not even 100% clear on why the code in {{start}} should update
> {{__environment_variables}} at all if we calculate the correct java version
> on every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19551) CCM nodes share the same environment variable map breaking upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837447#comment-17837447
]
Ariel Weisberg commented on CASSANDRA-19551:
Looks like `TestGossip::test_assassinate_valid_node` and
`TestLargeColumn::test_cleanup` consistently every time the past 5 runs, but
`bootstrap_test.py::TestBootstrap::test_cleanup` I haven't seen a failure for.
> CCM nodes share the same environment variable map breaking upgrade tests
>
>
> Key: CASSANDRA-19551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> In {{node.py}} {{__environment_variables}} is generally always set with a map
> that is passed in from {{cluster.py}} so it is [shared between
> nodes](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151)
> and if nodes modify the map, such as in {{start}} when [updating the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860)
> then when {{get_env}} runs it will [overwrite the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244)
> that is selected by {{update_java_version}}.
> This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
> some of the upgrade tests because after the first node upgrades to 4.0 it's
> not longer possible for the subsequent nodes to select a Java version that
> isn't 11 because it's overridden by {{__environment_variables}}.
> I'm not even 100% clear on why the code in {{start}} should update
> {{__environment_variables}} at all if we calculate the correct java version
> on every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19551) CCM nodes share the same environment variable map breaking upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837444#comment-17837444
]
Ariel Weisberg commented on CASSANDRA-19551:
Attached result of running on trunk with a copy of the environment variables
for each node.
One failure is an assertion on some values which looks like an unrelated
problem since the cluster is coming up and working.
Looking into the other failures now. I'll also have baseline nightlies tomorrow.
> CCM nodes share the same environment variable map breaking upgrade tests
>
>
> Key: CASSANDRA-19551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> In {{node.py}} {{__environment_variables}} is generally always set with a map
> that is passed in from {{cluster.py}} so it is [shared between
> nodes](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151)
> and if nodes modify the map, such as in {{start}} when [updating the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860)
> then when {{get_env}} runs it will [overwrite the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244)
> that is selected by {{update_java_version}}.
> This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
> some of the upgrade tests because after the first node upgrades to 4.0 it's
> not longer possible for the subsequent nodes to select a Java version that
> isn't 11 because it's overridden by {{__environment_variables}}.
> I'm not even 100% clear on why the code in {{start}} should update
> {{__environment_variables}} at all if we calculate the correct java version
> on every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19551) CCM nodes share the same environment variable map breaking upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19551:
---
Attachment: ci_summary.html
> CCM nodes share the same environment variable map breaking upgrade tests
>
>
> Key: CASSANDRA-19551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> In {{node.py}} {{__environment_variables}} is generally always set with a map
> that is passed in from {{cluster.py}} so it is [shared between
> nodes](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151)
> and if nodes modify the map, such as in {{start}} when [updating the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860)
> then when {{get_env}} runs it will [overwrite the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244)
> that is selected by {{update_java_version}}.
> This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
> some of the upgrade tests because after the first node upgrades to 4.0 it's
> not longer possible for the subsequent nodes to select a Java version that
> isn't 11 because it's overridden by {{__environment_variables}}.
> I'm not even 100% clear on why the code in {{start}} should update
> {{__environment_variables}} at all if we calculate the correct java version
> on every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19551) CCM nodes share the same environment variable map breaking upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835866#comment-17835866
]
Ariel Weisberg commented on CASSANDRA-19551:
This doesn't make sense to me
https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L844
every time {{start}} is called after an upgrade we revert back to the old
{{JAVA_HOME}} from before upgrade, and then replace that anyways with
{{update_java_version}}. Nothing in {{update_java_version}} looks dependent on
the existing value of {{JAVA_HOME}} in {{env}} and it doesn't have visibility
to {{__environment_variables}} at all.
> CCM nodes share the same environment variable map breaking upgrade tests
>
>
> Key: CASSANDRA-19551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 5.x
>
>
> In {{node.py}} {{__environment_variables}} is generally always set with a map
> that is passed in from {{cluster.py}} so it is [shared between
> nodes](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151)
> and if nodes modify the map, such as in {{start}} when [updating the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860)
> then when {{get_env}} runs it will [overwrite the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244)
> that is selected by {{update_java_version}}.
> This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
> some of the upgrade tests because after the first node upgrades to 4.0 it's
> not longer possible for the subsequent nodes to select a Java version that
> isn't 11 because it's overridden by {{__environment_variables}}.
> I'm not even 100% clear on why the code in {{start}} should update
> {{__environment_variables}} at all if we calculate the correct java version
> on every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19551) CCM nodes share the same environment variable map breaking upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19551:
---
Test and Documentation Plan: Run all python dtests
Status: Patch Available (was: Open)
> CCM nodes share the same environment variable map breaking upgrade tests
>
>
> Key: CASSANDRA-19551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 5.x
>
>
> In {{node.py}} {{__environment_variables}} is generally always set with a map
> that is passed in from {{cluster.py}} so it is [shared between
> nodes](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151)
> and if nodes modify the map, such as in {{start}} when [updating the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860)
> then when {{get_env}} runs it will [overwrite the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244)
> that is selected by {{update_java_version}}.
> This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
> some of the upgrade tests because after the first node upgrades to 4.0 it's
> not longer possible for the subsequent nodes to select a Java version that
> isn't 11 because it's overridden by {{__environment_variables}}.
> I'm not even 100% clear on why the code in {{start}} should update
> {{__environment_variables}} at all if we calculate the correct java version
> on every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19551) CCM nodes share the same environment variable map breaking upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19551:
---
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Low Hanging Fruit
Discovered By: DTest
Fix Version/s: 5.x
Reviewers: Joshua McKenzie
Severity: Normal
Assignee: Ariel Weisberg
Status: Open (was: Triage Needed)
> CCM nodes share the same environment variable map breaking upgrade tests
>
>
> Key: CASSANDRA-19551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 5.x
>
>
> In {{node.py}} {{__environment_variables}} is generally always set with a map
> that is passed in from {{cluster.py}} so it is [shared between
> nodes](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151)
> and if nodes modify the map, such as in {{start}} when [updating the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860)
> then when {{get_env}} runs it will [overwrite the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244)
> that is selected by {{update_java_version}}.
> This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
> some of the upgrade tests because after the first node upgrades to 4.0 it's
> not longer possible for the subsequent nodes to select a Java version that
> isn't 11 because it's overridden by {{__environment_variables}}.
> I'm not even 100% clear on why the code in {{start}} should update
> {{__environment_variables}} at all if we calculate the correct java version
> on every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19551) CCM nodes share the same environment variable map breaking upgrade tests
Ariel Weisberg created CASSANDRA-19551:
--
Summary: CCM nodes share the same environment variable map
breaking upgrade tests
Key: CASSANDRA-19551
URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Ariel Weisberg
In {{node.py}} {{__environment_variables}} is generally always set with a map
that is passed in from {{cluster.py}} so it is [shared between
nodes](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151)
and if nodes modify the map, such as in {{start}} when [updating the Java
version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860)
then when {{get_env}} runs it will [overwrite the Java
version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244)
that is selected by {{update_java_version}}.
This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
some of the upgrade tests because after the first node upgrades to 4.0 it's not
longer possible for the subsequent nodes to select a Java version that isn't 11
because it's overridden by {{__environment_variables}}.
I'm not even 100% clear on why the code in {{start}} should update
{{__environment_variables}} at all if we calculate the correct java version on
every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19444) AccordRepairJob should be async like CassandraRepairJob
[ https://issues.apache.org/jira/browse/CASSANDRA-19444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832886#comment-17832886 ] Ariel Weisberg commented on CASSANDRA-19444: Blake will be fixing this in CASSANDRA-19472 > AccordRepairJob should be async like CassandraRepairJob > --- > > Key: CASSANDRA-19444 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19444 > Project: Cassandra > Issue Type: Bug >Reporter: Ariel Weisberg >Priority: Normal > > The thread that manages repairs needs to be available and not block. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19444) AccordRepairJob should be async like CassandraRepairJob
[ https://issues.apache.org/jira/browse/CASSANDRA-19444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19444: --- Resolution: Fixed Status: Resolved (was: Triage Needed) > AccordRepairJob should be async like CassandraRepairJob > --- > > Key: CASSANDRA-19444 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19444 > Project: Cassandra > Issue Type: Bug >Reporter: Ariel Weisberg >Priority: Normal > > The thread that manages repairs needs to be available and not block. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19496) Add properties for redirecting build-resolve to mirrors
[
https://issues.apache.org/jira/browse/CASSANDRA-19496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831465#comment-17831465
]
Ariel Weisberg commented on CASSANDRA-19496:
Committed. We would need to release {{3.0.30}} and {{3.11.17}} and point to
those in {{upgrade_manifest.py}} for this to be helpful. Or at least create
some tag to use. It would be helpful to stick with the existing format just
because some things do very kludgy parsing of {{upgrade_manifest.py}}.
> Add properties for redirecting build-resolve to mirrors
> ---
>
> Key: CASSANDRA-19496
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19496
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.30, 3.11.17
>
>
> When running upgrade tests in CI it's not always possible to reach the public
> mirrors. Currently we have properties for configuring private mirrors in 4.0+
> but we don't have this for 3.x.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19496) Add properties for redirecting build-resolve to mirrors
[ https://issues.apache.org/jira/browse/CASSANDRA-19496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19496: --- Fix Version/s: 3.0.30 3.11.17 (was: 3.0.x) (was: 3.11.x) Source Control Link: https://github.com/apache/cassandra/commit/56d3efff0c574a7c1ac2ebb6c90d283c1d256ee8 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Add properties for redirecting build-resolve to mirrors > --- > > Key: CASSANDRA-19496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19496 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 3.0.30, 3.11.17 > > > When running upgrade tests in CI it's not always possible to reach the public > mirrors. Currently we have properties for configuring private mirrors in 4.0+ > but we don't have this for 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19496) Add properties for redirecting build-resolve to mirrors
[ https://issues.apache.org/jira/browse/CASSANDRA-19496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831405#comment-17831405 ] Ariel Weisberg commented on CASSANDRA-19496: [Looks like this should change from 4.0.11 to 4.0.16?|https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py#L172] > Add properties for redirecting build-resolve to mirrors > --- > > Key: CASSANDRA-19496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19496 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > When running upgrade tests in CI it's not always possible to reach the public > mirrors. Currently we have properties for configuring private mirrors in 4.0+ > but we don't have this for 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19496) Add properties for redirecting build-resolve to mirrors
[ https://issues.apache.org/jira/browse/CASSANDRA-19496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19496: --- Test and Documentation Plan: Run 4.0 tests showing upgrade tests work. Don't have a way to run the full 3.x tests, but run what we can in CircleCI. (was: Run 4.0 tests. Don't have a way to run the full 3.x tests, but run what we can in CircleCI.) > Add properties for redirecting build-resolve to mirrors > --- > > Key: CASSANDRA-19496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19496 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > When running upgrade tests in CI it's not always possible to reach the public > mirrors. Currently we have properties for configuring private mirrors in 4.0+ > but we don't have this for 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19496) Add properties for redirecting build-resolve to mirrors
[ https://issues.apache.org/jira/browse/CASSANDRA-19496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19496: --- Test and Documentation Plan: Run 4.0 tests. Don't have a way to run the full 3.x tests, but run what we can in CircleCI. Status: Patch Available (was: Open) > Add properties for redirecting build-resolve to mirrors > --- > > Key: CASSANDRA-19496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19496 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > When running upgrade tests in CI it's not always possible to reach the public > mirrors. Currently we have properties for configuring private mirrors in 4.0+ > but we don't have this for 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19496) Add properties for redirecting build-resolve to mirrors
[ https://issues.apache.org/jira/browse/CASSANDRA-19496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19496: --- Change Category: Quality Assurance Complexity: Normal Status: Open (was: Triage Needed) > Add properties for redirecting build-resolve to mirrors > --- > > Key: CASSANDRA-19496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19496 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > When running upgrade tests in CI it's not always possible to reach the public > mirrors. Currently we have properties for configuring private mirrors in 4.0+ > but we don't have this for 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19496) Add properties for redirecting build-resolve to mirrors
Ariel Weisberg created CASSANDRA-19496: -- Summary: Add properties for redirecting build-resolve to mirrors Key: CASSANDRA-19496 URL: https://issues.apache.org/jira/browse/CASSANDRA-19496 Project: Cassandra Issue Type: Improvement Components: Build Reporter: Ariel Weisberg Assignee: Ariel Weisberg When running upgrade tests in CI it's not always possible to reach the public mirrors. Currently we have properties for configuring private mirrors in 4.0+ but we don't have this for 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19496) Add properties for redirecting build-resolve to mirrors
[ https://issues.apache.org/jira/browse/CASSANDRA-19496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19496: --- Fix Version/s: 3.0.x 3.11.x > Add properties for redirecting build-resolve to mirrors > --- > > Key: CASSANDRA-19496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19496 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > When running upgrade tests in CI it's not always possible to reach the public > mirrors. Currently we have properties for configuring private mirrors in 4.0+ > but we don't have this for 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19332) Dropwizard Meter causes timeouts when infrequently used
[
https://issues.apache.org/jira/browse/CASSANDRA-19332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830652#comment-17830652
]
Ariel Weisberg commented on CASSANDRA-19332:
I think I figured out what happened. The latest test repo version was tested,
but my branch was behind trunk so it didn't have the change to nodetool.
> Dropwizard Meter causes timeouts when infrequently used
> ---
>
> Key: CASSANDRA-19332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19332
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0, 5.1
>
> Attachments: ci_summary_4.1.html, ci_summary_5.0.html,
> ci_summary_trunk.html, result_details_4.1.tar.gz, result_details_5.0.tar.gz,
> result_details_trunk.tar.gz
>
>
> Observed instances of timeouts on clusters with long uptime and infrequently
> used tables and possibly just request paths such as not using CAS for large
> fractions of a year.
> CAS seems to be more severely impacted because it has more metrics in the
> request path such as latency measurements for prepare, propose, and the read
> from the underlying table.
> Tracing showed ~600-800 milliseconds for these operations in between the
> “appending to memtable” and “sending a response” events. Reads had a delay
> between finishing the construction of the iterator and sending the read
> response.
> Stack traces dumped every 100 milliseconds using {{sjk}} shows that in
> prepare and propose a lot of time was being spent in
> {{{}Meter.tickIfNecessary{}}}.
> {code:java}
> Thread [2537] RUNNABLE at 2024-01-25T21:14:48.218 - MutationStage-2
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:71)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.prepare(PaxosState.java:92)
> Thread [2539] RUNNABLE at 2024-01-25T21:14:48.520 - MutationStage-4
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:72)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.propose(PaxosState.java:127){code}
> {{tickIfNecessary}} does a linear amount of work proportional to the time
> since the last time the metric was updated/read/created and this can actually
> take a measurable amount of time even in a tight loop. On my M2 MBP it was
> 1.5 milliseconds for a day, ~200 days took ~74 milliseconds. Before it warmed
> up it was 140 milliseconds.
> A quick fix is to schedule a task to read all the meters once a day so it
> isn’t done in the request path and we have a more incremental amount to
> process at a time.
> Also observed that {{tickIfNecessary}} is not 100% thread safe in that if it
> takes longer than 5 seconds to run the loop it can end up with multiple
> threads attempting to run the loop at once and then they will concurrently
> run {{EWMA.tick}} which probably results in some ticks not being performed.
> This issue is still present in the latest version of {{Metrics}} if using
> {{{}EWMA{}}}, but {{SlidingWindowTimeAverages}} looks like it has a bounded
> amount of work required to tick. Switching would change how our metrics work
> since the two don't have the same behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19332) Dropwizard Meter causes timeouts when infrequently used
[
https://issues.apache.org/jira/browse/CASSANDRA-19332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830649#comment-17830649
]
Ariel Weisberg commented on CASSANDRA-19332:
So which build are you referring to? When I look at the trunk build that
generated that error the log has
Cloned https://github.com/apache/cassandra-dtest.git trunk to
/workspace/context/cassandra-dtest; commit is
7a82b3757c136f79b52a76fdf3e98891dfff6b41
and that SHA comes after f3ca59c
[https://github.com/apache/cassandra-dtest/commits/trunk/]
I'll look a little deeper and try to figure out how the executors ended up
running with the wrong commit on the dtest repo because clearly it happened.
> Dropwizard Meter causes timeouts when infrequently used
> ---
>
> Key: CASSANDRA-19332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19332
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0, 5.1
>
> Attachments: ci_summary_4.1.html, ci_summary_5.0.html,
> ci_summary_trunk.html, result_details_4.1.tar.gz, result_details_5.0.tar.gz,
> result_details_trunk.tar.gz
>
>
> Observed instances of timeouts on clusters with long uptime and infrequently
> used tables and possibly just request paths such as not using CAS for large
> fractions of a year.
> CAS seems to be more severely impacted because it has more metrics in the
> request path such as latency measurements for prepare, propose, and the read
> from the underlying table.
> Tracing showed ~600-800 milliseconds for these operations in between the
> “appending to memtable” and “sending a response” events. Reads had a delay
> between finishing the construction of the iterator and sending the read
> response.
> Stack traces dumped every 100 milliseconds using {{sjk}} shows that in
> prepare and propose a lot of time was being spent in
> {{{}Meter.tickIfNecessary{}}}.
> {code:java}
> Thread [2537] RUNNABLE at 2024-01-25T21:14:48.218 - MutationStage-2
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:71)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.prepare(PaxosState.java:92)
> Thread [2539] RUNNABLE at 2024-01-25T21:14:48.520 - MutationStage-4
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:72)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.propose(PaxosState.java:127){code}
> {{tickIfNecessary}} does a linear amount of work proportional to the time
> since the last time the metric was updated/read/created and this can actually
> take a measurable amount of time even in a tight loop. On my M2 MBP it was
> 1.5 milliseconds for a day, ~200 days took ~74 milliseconds. Before it warmed
> up it was 140 milliseconds.
> A quick fix is to schedule a task to read all the meters once a day so it
> isn’t done in the request path and we have a more incremental amount to
> process at a time.
> Also observed that {{tickIfNecessary}} is not 100% thread safe in that if it
> takes longer than 5 seconds to run the loop it can end up with multiple
> threads attempting to run the loop at once and then they will concurrently
> run {{EWMA.tick}} which probably results in some ticks not being performed.
> This issue is still present in the latest version of {{Metrics}} if using
> {{{}EWMA{}}}, but {{SlidingWindowTimeAverages}} looks like it has a bounded
> amount of work required to tick. Switching would change how our metrics work
> since the two don't have the same behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19332) Dropwizard Meter causes timeouts when infrequently used
[
https://issues.apache.org/jira/browse/CASSANDRA-19332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830606#comment-17830606
]
Ariel Weisberg commented on CASSANDRA-19332:
Sounds good, I will wait for that.
> Dropwizard Meter causes timeouts when infrequently used
> ---
>
> Key: CASSANDRA-19332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19332
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0, 5.1
>
> Attachments: ci_summary_4.1.html, ci_summary_5.0.html,
> ci_summary_trunk.html, result_details_4.1.tar.gz, result_details_5.0.tar.gz,
> result_details_trunk.tar.gz
>
>
> Observed instances of timeouts on clusters with long uptime and infrequently
> used tables and possibly just request paths such as not using CAS for large
> fractions of a year.
> CAS seems to be more severely impacted because it has more metrics in the
> request path such as latency measurements for prepare, propose, and the read
> from the underlying table.
> Tracing showed ~600-800 milliseconds for these operations in between the
> “appending to memtable” and “sending a response” events. Reads had a delay
> between finishing the construction of the iterator and sending the read
> response.
> Stack traces dumped every 100 milliseconds using {{sjk}} shows that in
> prepare and propose a lot of time was being spent in
> {{{}Meter.tickIfNecessary{}}}.
> {code:java}
> Thread [2537] RUNNABLE at 2024-01-25T21:14:48.218 - MutationStage-2
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:71)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.prepare(PaxosState.java:92)
> Thread [2539] RUNNABLE at 2024-01-25T21:14:48.520 - MutationStage-4
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:72)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.propose(PaxosState.java:127){code}
> {{tickIfNecessary}} does a linear amount of work proportional to the time
> since the last time the metric was updated/read/created and this can actually
> take a measurable amount of time even in a tight loop. On my M2 MBP it was
> 1.5 milliseconds for a day, ~200 days took ~74 milliseconds. Before it warmed
> up it was 140 milliseconds.
> A quick fix is to schedule a task to read all the meters once a day so it
> isn’t done in the request path and we have a more incremental amount to
> process at a time.
> Also observed that {{tickIfNecessary}} is not 100% thread safe in that if it
> takes longer than 5 seconds to run the loop it can end up with multiple
> threads attempting to run the loop at once and then they will concurrently
> run {{EWMA.tick}} which probably results in some ticks not being performed.
> This issue is still present in the latest version of {{Metrics}} if using
> {{{}EWMA{}}}, but {{SlidingWindowTimeAverages}} looks like it has a bounded
> amount of work required to tick. Switching would change how our metrics work
> since the two don't have the same behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19332) Dropwizard Meter causes timeouts when infrequently used
[
https://issues.apache.org/jira/browse/CASSANDRA-19332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830574#comment-17830574
]
Ariel Weisberg commented on CASSANDRA-19332:
Yeah the Dropwizard fix makes this not necessary by fixing the cost of marking
a meter that hasn't been used in a long time. We can remove this once that is
fixed. Since we don't update dependencies in older versions so we will need
this in 4.0/4.1, and 5.0 if it releases before Dropwizard does.
> Dropwizard Meter causes timeouts when infrequently used
> ---
>
> Key: CASSANDRA-19332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19332
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0, 5.1
>
> Attachments: ci_summary_4.1.html, ci_summary_5.0.html,
> ci_summary_trunk.html, result_details_4.1.tar.gz, result_details_5.0.tar.gz,
> result_details_trunk.tar.gz
>
>
> Observed instances of timeouts on clusters with long uptime and infrequently
> used tables and possibly just request paths such as not using CAS for large
> fractions of a year.
> CAS seems to be more severely impacted because it has more metrics in the
> request path such as latency measurements for prepare, propose, and the read
> from the underlying table.
> Tracing showed ~600-800 milliseconds for these operations in between the
> “appending to memtable” and “sending a response” events. Reads had a delay
> between finishing the construction of the iterator and sending the read
> response.
> Stack traces dumped every 100 milliseconds using {{sjk}} shows that in
> prepare and propose a lot of time was being spent in
> {{{}Meter.tickIfNecessary{}}}.
> {code:java}
> Thread [2537] RUNNABLE at 2024-01-25T21:14:48.218 - MutationStage-2
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:71)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.prepare(PaxosState.java:92)
> Thread [2539] RUNNABLE at 2024-01-25T21:14:48.520 - MutationStage-4
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:72)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.propose(PaxosState.java:127){code}
> {{tickIfNecessary}} does a linear amount of work proportional to the time
> since the last time the metric was updated/read/created and this can actually
> take a measurable amount of time even in a tight loop. On my M2 MBP it was
> 1.5 milliseconds for a day, ~200 days took ~74 milliseconds. Before it warmed
> up it was 140 milliseconds.
> A quick fix is to schedule a task to read all the meters once a day so it
> isn’t done in the request path and we have a more incremental amount to
> process at a time.
> Also observed that {{tickIfNecessary}} is not 100% thread safe in that if it
> takes longer than 5 seconds to run the loop it can end up with multiple
> threads attempting to run the loop at once and then they will concurrently
> run {{EWMA.tick}} which probably results in some ticks not being performed.
> This issue is still present in the latest version of {{Metrics}} if using
> {{{}EWMA{}}}, but {{SlidingWindowTimeAverages}} looks like it has a bounded
> amount of work required to tick. Switching would change how our metrics work
> since the two don't have the same behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19332) Dropwizard Meter causes timeouts when infrequently used
[
https://issues.apache.org/jira/browse/CASSANDRA-19332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830549#comment-17830549
]
Ariel Weisberg commented on CASSANDRA-19332:
I haven't merged this for a while because I have had a steady stream of CI
issues. Based on comparisons with nightlies it doesn't look like the test
failures are related. 5.0 is basically clean, 4.0/4.1 have a bunch of upgrade
test issues, and so does trunk. I think this is more specific to our CI
environment and some issues invoking different upgrade paths.
I'm going to go ahead and merge anyways unless someone objects since the scope
of this change is pretty narrow and doesn't look related to any of the failures.
> Dropwizard Meter causes timeouts when infrequently used
> ---
>
> Key: CASSANDRA-19332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19332
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0, 5.1
>
> Attachments: ci_summary_4.1.html, ci_summary_5.0.html,
> ci_summary_trunk.html, result_details_4.1.tar.gz, result_details_5.0.tar.gz,
> result_details_trunk.tar.gz
>
>
> Observed instances of timeouts on clusters with long uptime and infrequently
> used tables and possibly just request paths such as not using CAS for large
> fractions of a year.
> CAS seems to be more severely impacted because it has more metrics in the
> request path such as latency measurements for prepare, propose, and the read
> from the underlying table.
> Tracing showed ~600-800 milliseconds for these operations in between the
> “appending to memtable” and “sending a response” events. Reads had a delay
> between finishing the construction of the iterator and sending the read
> response.
> Stack traces dumped every 100 milliseconds using {{sjk}} shows that in
> prepare and propose a lot of time was being spent in
> {{{}Meter.tickIfNecessary{}}}.
> {code:java}
> Thread [2537] RUNNABLE at 2024-01-25T21:14:48.218 - MutationStage-2
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:71)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.prepare(PaxosState.java:92)
> Thread [2539] RUNNABLE at 2024-01-25T21:14:48.520 - MutationStage-4
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:72)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.propose(PaxosState.java:127){code}
> {{tickIfNecessary}} does a linear amount of work proportional to the time
> since the last time the metric was updated/read/created and this can actually
> take a measurable amount of time even in a tight loop. On my M2 MBP it was
> 1.5 milliseconds for a day, ~200 days took ~74 milliseconds. Before it warmed
> up it was 140 milliseconds.
> A quick fix is to schedule a task to read all the meters once a day so it
> isn’t done in the request path and we have a more incremental amount to
> process at a time.
> Also observed that {{tickIfNecessary}} is not 100% thread safe in that if it
> takes longer than 5 seconds to run the loop it can end up with multiple
> threads attempting to run the loop at once and then they will concurrently
> run {{EWMA.tick}} which probably results in some ticks not being performed.
> This issue is still present in the latest version of {{Metrics}} if using
> {{{}EWMA{}}}, but {{SlidingWindowTimeAverages}} looks like it has a bounded
> amount of work required to tick. Switching would change how our metrics work
> since the two don't have the same behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19332) Dropwizard Meter causes timeouts when infrequently used
[
https://issues.apache.org/jira/browse/CASSANDRA-19332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19332:
---
Fix Version/s: 5.0
5.1
> Dropwizard Meter causes timeouts when infrequently used
> ---
>
> Key: CASSANDRA-19332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19332
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0, 5.1
>
> Attachments: ci_summary_4.1.html, ci_summary_5.0.html,
> ci_summary_trunk.html, result_details_4.1.tar.gz, result_details_5.0.tar.gz,
> result_details_trunk.tar.gz
>
>
> Observed instances of timeouts on clusters with long uptime and infrequently
> used tables and possibly just request paths such as not using CAS for large
> fractions of a year.
> CAS seems to be more severely impacted because it has more metrics in the
> request path such as latency measurements for prepare, propose, and the read
> from the underlying table.
> Tracing showed ~600-800 milliseconds for these operations in between the
> “appending to memtable” and “sending a response” events. Reads had a delay
> between finishing the construction of the iterator and sending the read
> response.
> Stack traces dumped every 100 milliseconds using {{sjk}} shows that in
> prepare and propose a lot of time was being spent in
> {{{}Meter.tickIfNecessary{}}}.
> {code:java}
> Thread [2537] RUNNABLE at 2024-01-25T21:14:48.218 - MutationStage-2
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:71)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.prepare(PaxosState.java:92)
> Thread [2539] RUNNABLE at 2024-01-25T21:14:48.520 - MutationStage-4
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:72)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.propose(PaxosState.java:127){code}
> {{tickIfNecessary}} does a linear amount of work proportional to the time
> since the last time the metric was updated/read/created and this can actually
> take a measurable amount of time even in a tight loop. On my M2 MBP it was
> 1.5 milliseconds for a day, ~200 days took ~74 milliseconds. Before it warmed
> up it was 140 milliseconds.
> A quick fix is to schedule a task to read all the meters once a day so it
> isn’t done in the request path and we have a more incremental amount to
> process at a time.
> Also observed that {{tickIfNecessary}} is not 100% thread safe in that if it
> takes longer than 5 seconds to run the loop it can end up with multiple
> threads attempting to run the loop at once and then they will concurrently
> run {{EWMA.tick}} which probably results in some ticks not being performed.
> This issue is still present in the latest version of {{Metrics}} if using
> {{{}EWMA{}}}, but {{SlidingWindowTimeAverages}} looks like it has a bounded
> amount of work required to tick. Switching would change how our metrics work
> since the two don't have the same behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19332) Dropwizard Meter causes timeouts when infrequently used
[
https://issues.apache.org/jira/browse/CASSANDRA-19332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19332:
---
Attachment: ci_summary_4.1.html
result_details_4.1.tar.gz
> Dropwizard Meter causes timeouts when infrequently used
> ---
>
> Key: CASSANDRA-19332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19332
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: ci_summary_4.1.html, ci_summary_5.0.html,
> ci_summary_trunk.html, result_details_4.1.tar.gz, result_details_5.0.tar.gz,
> result_details_trunk.tar.gz
>
>
> Observed instances of timeouts on clusters with long uptime and infrequently
> used tables and possibly just request paths such as not using CAS for large
> fractions of a year.
> CAS seems to be more severely impacted because it has more metrics in the
> request path such as latency measurements for prepare, propose, and the read
> from the underlying table.
> Tracing showed ~600-800 milliseconds for these operations in between the
> “appending to memtable” and “sending a response” events. Reads had a delay
> between finishing the construction of the iterator and sending the read
> response.
> Stack traces dumped every 100 milliseconds using {{sjk}} shows that in
> prepare and propose a lot of time was being spent in
> {{{}Meter.tickIfNecessary{}}}.
> {code:java}
> Thread [2537] RUNNABLE at 2024-01-25T21:14:48.218 - MutationStage-2
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:71)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.prepare(PaxosState.java:92)
> Thread [2539] RUNNABLE at 2024-01-25T21:14:48.520 - MutationStage-4
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:72)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.propose(PaxosState.java:127){code}
> {{tickIfNecessary}} does a linear amount of work proportional to the time
> since the last time the metric was updated/read/created and this can actually
> take a measurable amount of time even in a tight loop. On my M2 MBP it was
> 1.5 milliseconds for a day, ~200 days took ~74 milliseconds. Before it warmed
> up it was 140 milliseconds.
> A quick fix is to schedule a task to read all the meters once a day so it
> isn’t done in the request path and we have a more incremental amount to
> process at a time.
> Also observed that {{tickIfNecessary}} is not 100% thread safe in that if it
> takes longer than 5 seconds to run the loop it can end up with multiple
> threads attempting to run the loop at once and then they will concurrently
> run {{EWMA.tick}} which probably results in some ticks not being performed.
> This issue is still present in the latest version of {{Metrics}} if using
> {{{}EWMA{}}}, but {{SlidingWindowTimeAverages}} looks like it has a bounded
> amount of work required to tick. Switching would change how our metrics work
> since the two don't have the same behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19332) Dropwizard Meter causes timeouts when infrequently used
[
https://issues.apache.org/jira/browse/CASSANDRA-19332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19332:
---
Attachment: ci_summary_5.0.html
result_details_5.0.tar.gz
> Dropwizard Meter causes timeouts when infrequently used
> ---
>
> Key: CASSANDRA-19332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19332
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: ci_summary_5.0.html, ci_summary_trunk.html,
> result_details_5.0.tar.gz, result_details_trunk.tar.gz
>
>
> Observed instances of timeouts on clusters with long uptime and infrequently
> used tables and possibly just request paths such as not using CAS for large
> fractions of a year.
> CAS seems to be more severely impacted because it has more metrics in the
> request path such as latency measurements for prepare, propose, and the read
> from the underlying table.
> Tracing showed ~600-800 milliseconds for these operations in between the
> “appending to memtable” and “sending a response” events. Reads had a delay
> between finishing the construction of the iterator and sending the read
> response.
> Stack traces dumped every 100 milliseconds using {{sjk}} shows that in
> prepare and propose a lot of time was being spent in
> {{{}Meter.tickIfNecessary{}}}.
> {code:java}
> Thread [2537] RUNNABLE at 2024-01-25T21:14:48.218 - MutationStage-2
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:71)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.prepare(PaxosState.java:92)
> Thread [2539] RUNNABLE at 2024-01-25T21:14:48.520 - MutationStage-4
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:72)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.propose(PaxosState.java:127){code}
> {{tickIfNecessary}} does a linear amount of work proportional to the time
> since the last time the metric was updated/read/created and this can actually
> take a measurable amount of time even in a tight loop. On my M2 MBP it was
> 1.5 milliseconds for a day, ~200 days took ~74 milliseconds. Before it warmed
> up it was 140 milliseconds.
> A quick fix is to schedule a task to read all the meters once a day so it
> isn’t done in the request path and we have a more incremental amount to
> process at a time.
> Also observed that {{tickIfNecessary}} is not 100% thread safe in that if it
> takes longer than 5 seconds to run the loop it can end up with multiple
> threads attempting to run the loop at once and then they will concurrently
> run {{EWMA.tick}} which probably results in some ticks not being performed.
> This issue is still present in the latest version of {{Metrics}} if using
> {{{}EWMA{}}}, but {{SlidingWindowTimeAverages}} looks like it has a bounded
> amount of work required to tick. Switching would change how our metrics work
> since the two don't have the same behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19332) Dropwizard Meter causes timeouts when infrequently used
[
https://issues.apache.org/jira/browse/CASSANDRA-19332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19332:
---
Attachment: ci_summary_trunk.html
result_details_trunk.tar.gz
> Dropwizard Meter causes timeouts when infrequently used
> ---
>
> Key: CASSANDRA-19332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19332
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: ci_summary_trunk.html, result_details_trunk.tar.gz
>
>
> Observed instances of timeouts on clusters with long uptime and infrequently
> used tables and possibly just request paths such as not using CAS for large
> fractions of a year.
> CAS seems to be more severely impacted because it has more metrics in the
> request path such as latency measurements for prepare, propose, and the read
> from the underlying table.
> Tracing showed ~600-800 milliseconds for these operations in between the
> “appending to memtable” and “sending a response” events. Reads had a delay
> between finishing the construction of the iterator and sending the read
> response.
> Stack traces dumped every 100 milliseconds using {{sjk}} shows that in
> prepare and propose a lot of time was being spent in
> {{{}Meter.tickIfNecessary{}}}.
> {code:java}
> Thread [2537] RUNNABLE at 2024-01-25T21:14:48.218 - MutationStage-2
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:71)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.prepare(PaxosState.java:92)
> Thread [2539] RUNNABLE at 2024-01-25T21:14:48.520 - MutationStage-4
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:72)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.propose(PaxosState.java:127){code}
> {{tickIfNecessary}} does a linear amount of work proportional to the time
> since the last time the metric was updated/read/created and this can actually
> take a measurable amount of time even in a tight loop. On my M2 MBP it was
> 1.5 milliseconds for a day, ~200 days took ~74 milliseconds. Before it warmed
> up it was 140 milliseconds.
> A quick fix is to schedule a task to read all the meters once a day so it
> isn’t done in the request path and we have a more incremental amount to
> process at a time.
> Also observed that {{tickIfNecessary}} is not 100% thread safe in that if it
> takes longer than 5 seconds to run the loop it can end up with multiple
> threads attempting to run the loop at once and then they will concurrently
> run {{EWMA.tick}} which probably results in some ticks not being performed.
> This issue is still present in the latest version of {{Metrics}} if using
> {{{}EWMA{}}}, but {{SlidingWindowTimeAverages}} looks like it has a bounded
> amount of work required to tick. Switching would change how our metrics work
> since the two don't have the same behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19484:
---
Fix Version/s: 3.0.30
3.11.17
4.0.13
4.1.5
5.0
5.1
(was: 3.0.x)
(was: 3.11.x)
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
(was: 5.0.x)
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.30, 3.11.17, 4.0.13, 4.1.5, 5.0, 5.1
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19484:
---
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19484:
---
Status: Review In Progress (was: Patch Available)
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19484:
---
Status: Ready to Commit (was: Review In Progress)
It's clean on all the branches.
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19484:
---
Source Control Link:
https://github.com/apache/cassandra/commit/c8fbb97ab04142f9b49fe86017b808ff3e35c10a
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19484:
---
Reviewers: Berenguer Blasi (was: Berenguer Blasi, Joshua McKenzie)
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829629#comment-17829629
]
Ariel Weisberg edited comment on CASSANDRA-19484 at 3/21/24 5:43 PM:
-
*edit* Removed a bunch of incorrectly generated dependencies with CVEs to
shorten the comment thread.
was (Author: aweisberg):
3.0
{noformat}
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-core/pom.xml:
CVE-2010-0538
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-mapping/pom.xml:
CVE-2010-0538
jackson-databind-2.13.2.2.jar: CVE-2023-35116, CVE-2022-42003, CVE-2022-42004
snappy-java-1.1.8.4.jar: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453,
CVE-2023-43642
{noformat}
3.11
{noformat}
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-core/pom.xml:
CVE-2010-0538
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-mapping/pom.xml:
CVE-2010-0538
jackson-mapper-asl-1.9.2.jar: CVE-2017-7525, CVE-2019-10172
snakeyaml-1.11.jar: CVE-2017-18640
snappy-java-1.1.8.4.jar: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453,
CVE-2023-43642
{noformat}
4.0
{noformat}
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-core/pom.xml:
CVE-2010-0538
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-mapping/pom.xml:
CVE-2010-0538
guava-18.0.jar: CVE-2018-10237
jackson-mapper-asl-1.9.2.jar: CVE-2017-7525, CVE-2019-10172
libthrift-0.9.2.jar: CVE-2016-5397, CVE-2018-1320, CVE-2015-3254,
CVE-2018-11798, CVE-2019-0205
netty-all-4.0.44.Final.jar: CVE-2019-16869, CVE-2019-20445, CVE-2019-20444,
CVE-2020-7238
snakeyaml-1.11.jar: CVE-2017-18640
snappy-java-1.1.8.4.jar: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453,
CVE-2023-43642
thrift-server-0.3.7.jar: CVE-2016-5397, CVE-2015-3254, CVE-2019-0205
{noformat}
4.1
{noformat}
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-core/pom.xml:
CVE-2010-0538
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-mapping/pom.xml:
CVE-2010-0538
guava-18.0.jar: CVE-2018-10237
jackson-mapper-asl-1.9.2.jar: CVE-2017-7525, CVE-2019-10172
libthrift-0.9.2.jar: CVE-2016-5397, CVE-2018-1320, CVE-2015-3254,
CVE-2018-11798, CVE-2019-0205
netty-all-4.0.44.Final.jar: CVE-2019-16869, CVE-2019-20445, CVE-2019-20444,
CVE-2020-7238
snakeyaml-1.11.jar: CVE-2017-18640
snappy-java-1.1.8.4.jar: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453,
CVE-2023-43642
thrift-server-0.3.7.jar: CVE-2016-5397, CVE-2015-3254, CVE-2019-0205
{noformat}
5.0
{noformat}
guava-18.0.jar: CVE-2020-8908, CVE-2018-10237, CVE-2023-2976
guava-27.0-jre.jar: CVE-2020-8908, CVE-2023-2976
jackson-mapper-asl-1.9.2.jar: CVE-2017-7525, CVE-2019-10172
libthrift-0.9.2.jar: CVE-2016-5397, CVE-2018-1320, CVE-2015-3254,
CVE-2018-11798, CVE-2019-0205
netty-all-4.0.44.Final.jar: CVE-2021-43797, CVE-2019-16869, CVE-2021-37136,
CVE-2021-37137, CVE-2019-20445, CVE-2019-20444, CVE-2021-21295, CVE-2023-34462,
CVE-2021-21290, CVE-2022-24823, CVE-2022-41881, CVE-2021-21409, CVE-2020-7238
netty-all-4.1.58.Final.jar: CVE-2021-43797, CVE-2021-37136, CVE-2021-37137,
CVE-2022-24823, CVE-2022-41881, CVE-2021-21295, CVE-2021-21409, CVE-2023-34462,
CVE-2021-21290
snakeyaml-1.11.jar: CVE-2017-18640
snappy-java-1.1.8.4.jar: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453,
CVE-2023-43642
thrift-server-0.3.7.jar: CVE-2016-5397, CVE-2015-3254, CVE-2019-0205
{noformat}
trunk
{noformat}
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-core/pom.xml:
CVE-2010-0538
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-mapping/pom.xml:
CVE-2010-0538
guava-18.0.jar: CVE-2020-8908, CVE-2018-10237, CVE-2023-2976
guava-27.0-jre.jar: CVE-2020-8908, CVE-2023-2976
jackson-databind-2.13.2.2.jar: CVE-2022-42003, CVE-2022-42004
jackson-mapper-asl-1.9.2.jar: CVE-2017-7525, CVE-2019-10172
libthrift-0.9.2.jar: CVE-2016-5397, CVE-2018-1320, CVE-2015-3254,
CVE-2018-11798, CVE-2019-0205
netty-all-4.0.44.Final.jar: CVE-2021-43797, CVE-2019-16869, CVE-2021-37136,
CVE-2021-37137, CVE-2019-20445, CVE-2019-20444, CVE-2021-21295, CVE-2023-34462,
CVE-2021-21290, CVE-2022-24823, CVE-2022-41881, CVE-2021-21409, CVE-2020-7238
netty-all-4.1.58.Final.jar: CVE-2021-43797, CVE-2021-37136, CVE-2021-37137,
CVE-2022-24823, CVE-2022-41881, CVE-2021-21295, CVE-2021-21409, CVE-2023-34462,
CVE-2021-21290
snakeyaml-1.11.jar: CVE-2017-18640, CVE-2022-38752, CVE-2022-38751,
CVE-2022-38750, CVE-2022-41854, CVE-2022-25857, CVE-2022-38749, CVE-2022-1471
snakeyaml-1.26.jar: CVE-2022-38752, CVE-2022-38751, CVE-2022-38750,
CVE-2022-41854, CVE-2022-25857, CVE-2022-38749, CVE-2022-1471
snappy-java-1.1.8.4.jar: CVE-2023-34455,
[jira] [Commented] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829631#comment-17829631
]
Ariel Weisberg commented on CASSANDRA-19484:
PEBKAC, I didn't know you need a clean build before running the dependency
check.
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829629#comment-17829629
]
Ariel Weisberg commented on CASSANDRA-19484:
3.0
{noformat}
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-core/pom.xml:
CVE-2010-0538
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-mapping/pom.xml:
CVE-2010-0538
jackson-databind-2.13.2.2.jar: CVE-2023-35116, CVE-2022-42003, CVE-2022-42004
snappy-java-1.1.8.4.jar: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453,
CVE-2023-43642
{noformat}
3.11
{noformat}
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-core/pom.xml:
CVE-2010-0538
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-mapping/pom.xml:
CVE-2010-0538
jackson-mapper-asl-1.9.2.jar: CVE-2017-7525, CVE-2019-10172
snakeyaml-1.11.jar: CVE-2017-18640
snappy-java-1.1.8.4.jar: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453,
CVE-2023-43642
{noformat}
4.0
{noformat}
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-core/pom.xml:
CVE-2010-0538
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-mapping/pom.xml:
CVE-2010-0538
guava-18.0.jar: CVE-2018-10237
jackson-mapper-asl-1.9.2.jar: CVE-2017-7525, CVE-2019-10172
libthrift-0.9.2.jar: CVE-2016-5397, CVE-2018-1320, CVE-2015-3254,
CVE-2018-11798, CVE-2019-0205
netty-all-4.0.44.Final.jar: CVE-2019-16869, CVE-2019-20445, CVE-2019-20444,
CVE-2020-7238
snakeyaml-1.11.jar: CVE-2017-18640
snappy-java-1.1.8.4.jar: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453,
CVE-2023-43642
thrift-server-0.3.7.jar: CVE-2016-5397, CVE-2015-3254, CVE-2019-0205
{noformat}
4.1
{noformat}
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-core/pom.xml:
CVE-2010-0538
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-mapping/pom.xml:
CVE-2010-0538
guava-18.0.jar: CVE-2018-10237
jackson-mapper-asl-1.9.2.jar: CVE-2017-7525, CVE-2019-10172
libthrift-0.9.2.jar: CVE-2016-5397, CVE-2018-1320, CVE-2015-3254,
CVE-2018-11798, CVE-2019-0205
netty-all-4.0.44.Final.jar: CVE-2019-16869, CVE-2019-20445, CVE-2019-20444,
CVE-2020-7238
snakeyaml-1.11.jar: CVE-2017-18640
snappy-java-1.1.8.4.jar: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453,
CVE-2023-43642
thrift-server-0.3.7.jar: CVE-2016-5397, CVE-2015-3254, CVE-2019-0205
{noformat}
5.0
{noformat}
guava-18.0.jar: CVE-2020-8908, CVE-2018-10237, CVE-2023-2976
guava-27.0-jre.jar: CVE-2020-8908, CVE-2023-2976
jackson-mapper-asl-1.9.2.jar: CVE-2017-7525, CVE-2019-10172
libthrift-0.9.2.jar: CVE-2016-5397, CVE-2018-1320, CVE-2015-3254,
CVE-2018-11798, CVE-2019-0205
netty-all-4.0.44.Final.jar: CVE-2021-43797, CVE-2019-16869, CVE-2021-37136,
CVE-2021-37137, CVE-2019-20445, CVE-2019-20444, CVE-2021-21295, CVE-2023-34462,
CVE-2021-21290, CVE-2022-24823, CVE-2022-41881, CVE-2021-21409, CVE-2020-7238
netty-all-4.1.58.Final.jar: CVE-2021-43797, CVE-2021-37136, CVE-2021-37137,
CVE-2022-24823, CVE-2022-41881, CVE-2021-21295, CVE-2021-21409, CVE-2023-34462,
CVE-2021-21290
snakeyaml-1.11.jar: CVE-2017-18640
snappy-java-1.1.8.4.jar: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453,
CVE-2023-43642
thrift-server-0.3.7.jar: CVE-2016-5397, CVE-2015-3254, CVE-2019-0205
{noformat}
trunk
{noformat}
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-core/pom.xml:
CVE-2010-0538
cassandra-client-4.0.35.jar/META-INF/maven/com.apple.pie.cassandra/pie-cassandra-driver-mapping/pom.xml:
CVE-2010-0538
guava-18.0.jar: CVE-2020-8908, CVE-2018-10237, CVE-2023-2976
guava-27.0-jre.jar: CVE-2020-8908, CVE-2023-2976
jackson-databind-2.13.2.2.jar: CVE-2022-42003, CVE-2022-42004
jackson-mapper-asl-1.9.2.jar: CVE-2017-7525, CVE-2019-10172
libthrift-0.9.2.jar: CVE-2016-5397, CVE-2018-1320, CVE-2015-3254,
CVE-2018-11798, CVE-2019-0205
netty-all-4.0.44.Final.jar: CVE-2021-43797, CVE-2019-16869, CVE-2021-37136,
CVE-2021-37137, CVE-2019-20445, CVE-2019-20444, CVE-2021-21295, CVE-2023-34462,
CVE-2021-21290, CVE-2022-24823, CVE-2022-41881, CVE-2021-21409, CVE-2020-7238
netty-all-4.1.58.Final.jar: CVE-2021-43797, CVE-2021-37136, CVE-2021-37137,
CVE-2022-24823, CVE-2022-41881, CVE-2021-21295, CVE-2021-21409, CVE-2023-34462,
CVE-2021-21290
snakeyaml-1.11.jar: CVE-2017-18640, CVE-2022-38752, CVE-2022-38751,
CVE-2022-38750, CVE-2022-41854, CVE-2022-25857, CVE-2022-38749, CVE-2022-1471
snakeyaml-1.26.jar: CVE-2022-38752, CVE-2022-38751, CVE-2022-38750,
CVE-2022-41854, CVE-2022-25857, CVE-2022-38749, CVE-2022-1471
snappy-java-1.1.8.4.jar: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453,
CVE-2023-43642
thrift-server-0.3.7.jar: CVE-2016-5397, CVE-2015-3254, CVE-2019-0205
{noformat}
> Add support for providing nvdDatafeedUrl to OWASP
>
[jira] [Commented] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829617#comment-17829617
]
Ariel Weisberg commented on CASSANDRA-19484:
[~bereng] finished updating. If you are still +1 on the new version I will
merge.
I noticed there are lot of unsuppressed CVEs.
{code:java}
guava-18.0.jar: CVE-2020-8908, CVE-2018-10237, CVE-2023-2976
guava-27.0-jre.jar: CVE-2020-8908, CVE-2023-2976
jackson-databind-2.13.2.2.jar: CVE-2022-42003, CVE-2022-42004
jackson-mapper-asl-1.9.2.jar: CVE-2017-7525, CVE-2019-10172
libthrift-0.9.2.jar: CVE-2016-5397, CVE-2018-1320, CVE-2015-3254,
CVE-2018-11798, CVE-2019-0205
netty-all-4.0.44.Final.jar: CVE-2021-43797, CVE-2019-16869, CVE-2021-37136,
CVE-2021-37137, CVE-2019-20445, CVE-2019-20444, CVE-2021-21295, CVE-2023-34462,
CVE-2021-21290, CVE-2022-24823, CVE-2022-41881, CVE-2021-21409, CVE-2020-7238
netty-all-4.1.58.Final.jar: CVE-2021-43797, CVE-2021-37136, CVE-2021-37137,
CVE-2022-24823, CVE-2022-41881, CVE-2021-21295, CVE-2021-21409, CVE-2023-34462,
CVE-2021-21290
snakeyaml-1.11.jar: CVE-2017-18640, CVE-2022-38752, CVE-2022-38751,
CVE-2022-38750, CVE-2022-41854, CVE-2022-25857, CVE-2022-38749, CVE-2022-1471
snakeyaml-1.26.jar: CVE-2022-38752, CVE-2022-38751, CVE-2022-38750,
CVE-2022-41854, CVE-2022-25857, CVE-2022-38749, CVE-2022-1471
thrift-server-0.3.7.jar: CVE-2016-5397, CVE-2015-3254, CVE-2019-0205
{code}
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829608#comment-17829608
]
Ariel Weisberg commented on CASSANDRA-19484:
Ah, I tried that and it didn't work because in `ant` when you reference a
property that isn't set it doesn't resolve to the empty string it resolves to
the name of the property! Will update.
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829460#comment-17829460
]
Ariel Weisberg commented on CASSANDRA-19484:
Setting a property has no effect. At least none I can find. It has to be an
attribute on the task invocation.
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19484:
---
Source Control Link: (was: https://github.com/apache/cassandra/pull/3189,
https://github.com/apache/cassandra/pull/3187)
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19484:
---
Source Control Link: https://github.com/apache/cassandra/pull/3189,
https://github.com/apache/cassandra/pull/3187 (was:
https://github.com/apache/cassandra/pull/3189)
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19484:
---
Reviewers: Joshua McKenzie
Source Control Link: https://github.com/apache/cassandra/pull/3189
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19484:
---
Test and Documentation Plan: Run `ant dependency-check` on each branch
Status: Patch Available (was: Open)
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829318#comment-17829318
]
Ariel Weisberg commented on CASSANDRA-19484:
[~jlewandowski] [~brandon.williams] FYI
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19484:
---
Description:
This allows you to point to a mirror that is faster and doesn’t require an API
key.
This is kind of painful to make work in {{ant}} because you can't specify the
property at all if you want to use the API and I couldn't find a way to get
{{ant}} to conditionally supply the property without having a dedicated
invocation of the {{dependency-check}} task with/without the parameter
{{nvdDataFeedUrl}} specified.
was:
This allows you to point to a mirror that is faster and doesn’t require an API
key.
This is kind of painful to make work in `ant` because you can't specify the
property at all if you want to use the API and I couldn't find a way to get
`ant` to conditionally supply the property without having a dedicated
invocation of the `dependency-check` task with/without the parameter
{noformat}
nvdDataFeedUrl
{noformat}
specified.
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in {{ant}} because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> {{ant}} to conditionally supply the property without having a dedicated
> invocation of the {{dependency-check}} task with/without the parameter
> {{nvdDataFeedUrl}} specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19484) Add support for providing nvdDatafeedUrl to OWASP
[
https://issues.apache.org/jira/browse/CASSANDRA-19484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19484:
---
Change Category: Quality Assurance
Complexity: Low Hanging Fruit
Fix Version/s: 3.0.x
3.11.x
4.0.x
4.1.x
5.0.x
5.x
Status: Open (was: Triage Needed)
> Add support for providing nvdDatafeedUrl to OWASP
> -
>
> Key: CASSANDRA-19484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19484
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This allows you to point to a mirror that is faster and doesn’t require an
> API key.
> This is kind of painful to make work in `ant` because you can't specify the
> property at all if you want to use the API and I couldn't find a way to get
> `ant` to conditionally supply the property without having a dedicated
> invocation of the `dependency-check` task with/without the parameter
> {noformat}
> nvdDataFeedUrl
> {noformat}
> specified.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
