[jira] [Updated] (CASSANDRA-19656) Revisit disabling chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-19656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19656: -- Status: Ready to Commit (was: Review In Progress) > Revisit disabling chronicle analytics > - > > Key: CASSANDRA-19656 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19656 > Project: Cassandra > Issue Type: Task > Components: Local/Other >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0.x, 5.x > > > We first considered this in CASSANDRA-18538 but determined it wasn't a > problem. We have upgraded chronicle in CASSANDRA-18049 so we should > reconfirm with packet analysis that nothing is phoning home, and perhaps > consider taking further precautions by proactively disabling it. -- 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-19656) Revisit disabling chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-19656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854129#comment-17854129 ] Stefan Miklosovic commented on CASSANDRA-19656: --- +1 > Revisit disabling chronicle analytics > - > > Key: CASSANDRA-19656 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19656 > Project: Cassandra > Issue Type: Task > Components: Local/Other >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0.x, 5.x > > > We first considered this in CASSANDRA-18538 but determined it wasn't a > problem. We have upgraded chronicle in CASSANDRA-18049 so we should > reconfirm with packet analysis that nothing is phoning home, and perhaps > consider taking further precautions by proactively disabling it. -- 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-19656) Revisit disabling chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-19656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19656: -- Reviewers: Stefan Miklosovic Status: Review In Progress (was: Patch Available) > Revisit disabling chronicle analytics > - > > Key: CASSANDRA-19656 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19656 > Project: Cassandra > Issue Type: Task > Components: Local/Other >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0.x, 5.x > > > We first considered this in CASSANDRA-18538 but determined it wasn't a > problem. We have upgraded chronicle in CASSANDRA-18049 so we should > reconfirm with packet analysis that nothing is phoning home, and perhaps > consider taking further precautions by proactively disabling it. -- 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-19683) Investigate dtest timeouts after CASSANDRA-19534
[ https://issues.apache.org/jira/browse/CASSANDRA-19683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854063#comment-17854063 ] Stefan Miklosovic commented on CASSANDRA-19683: --- +1 > Investigate dtest timeouts after CASSANDRA-19534 > > > Key: CASSANDRA-19683 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19683 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > We have seen increased dtest timeouts that don't appear to be environmental: > https://app.circleci.com/pipelines/github/driftx/cassandra/1651/workflows/738d1c92-0ffe-45e7-8ad4-f2646170ba76 > https://ci-cassandra.apache.org/job/Cassandra-5.0/238/ > I have confirmed these don't occur before CASSANDRA-19534 -- 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-19683) Investigate dtest timeouts after CASSANDRA-19534
[ https://issues.apache.org/jira/browse/CASSANDRA-19683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854059#comment-17854059 ] Stefan Miklosovic commented on CASSANDRA-19683: --- Thanks for the creation of CASSANDRA-19697. I think what you have for now might be merged as it is already an improvement ... > Investigate dtest timeouts after CASSANDRA-19534 > > > Key: CASSANDRA-19683 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19683 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-rc > > > We have seen increased dtest timeouts that don't appear to be environmental: > https://app.circleci.com/pipelines/github/driftx/cassandra/1651/workflows/738d1c92-0ffe-45e7-8ad4-f2646170ba76 > https://ci-cassandra.apache.org/job/Cassandra-5.0/238/ > I have confirmed these don't occur before CASSANDRA-19534 -- 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-19656) Revisit disabling chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-19656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854058#comment-17854058 ] Stefan Miklosovic commented on CASSANDRA-19656: --- +1 > Revisit disabling chronicle analytics > - > > Key: CASSANDRA-19656 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19656 > Project: Cassandra > Issue Type: Task > Components: Local/Other >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0.x, 5.x > > > We first considered this in CASSANDRA-18538 but determined it wasn't a > problem. We have upgraded chronicle in CASSANDRA-18049 so we should > reconfirm with packet analysis that nothing is phoning home, and perhaps > consider taking further precautions by proactively disabling it. -- 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-19692) ClassCastException on selection with where clause from system.local_metadata_log
[
https://issues.apache.org/jira/browse/CASSANDRA-19692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853688#comment-17853688
]
Stefan Miklosovic commented on CASSANDRA-19692:
---
+1
> ClassCastException on selection with where clause from
> system.local_metadata_log
>
>
> Key: CASSANDRA-19692
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19692
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: Stefan Miklosovic
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> {code}
> select * from system.local_metadata_log where epoch = 1;
> NoHostAvailable: ('Unable to complete the operation against any hosts',
> {: message="java.lang.ClassCastException: class
> org.apache.cassandra.dht.Murmur3Partitioner$LongToken cannot be cast to class
> org.apache.cassandra.dht.ReversedLongLocalPartitioner$ReversedLongLocalToken
> (org.apache.cassandra.dht.Murmur3Partitioner$LongToken and
> org.apache.cassandra.dht.ReversedLongLocalPartitioner$ReversedLongLocalToken
> are in unnamed module of loader 'app')">})
> {code}
> same select but with "limit" works.
--
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-19445) Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
[
https://issues.apache.org/jira/browse/CASSANDRA-19445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19445:
--
Fix Version/s: 4.1.6
5.0-beta2
5.1-alpha1
(was: 5.x)
(was: 4.1.x)
(was: 5.0.x)
Since Version: 4.1.0
Source Control Link:
https://github.com/apache/cassandra/commit/a17e4fc49768794adf471f35506647596f962ca1
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
> --
>
> Key: CASSANDRA-19445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19445
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Zbyszek Z
>Assignee: Tommy Stendahl
>Priority: Normal
> Fix For: 4.1.6, 5.0-beta2, 5.1-alpha1
>
> Attachments: patch-4.1.txt, patch-5.0.txt, patch-trunk.txt,
> paxos-entry.txt, paxos-multiple.txt
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hello,
> On our cluster logs are flooded with:
> {code:java}
> INFO [OptionalTasks:1] 2024-02-27 14:27:51,213
> PaxosCleanupLocalCoordinator.java:185 - Completed 0 uncommitted paxos
> instances for X on ranges
> [(9210458530128018597,-9222146739399525061],
> (-9222146739399525061,-9174246180597321488],
> (-9174246180597321488,-9155837684527496840],
> (-9155837684527496840,-9148981328078890812],
> (-9148981328078890812,-9141853035919151700],
> (-9141853035919151700,-9138872620588476741], {code}
> I cannot find anything in doc regarding this longline. Also this are huge log
> payloads that heavy flood system.log.
--
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-19445) Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
[
https://issues.apache.org/jira/browse/CASSANDRA-19445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19445:
--
Reviewers: Blake Eggleston, Stefan Miklosovic (was: Stefan Miklosovic)
> Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
> --
>
> Key: CASSANDRA-19445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19445
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Zbyszek Z
>Assignee: Tommy Stendahl
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: patch-4.1.txt, patch-5.0.txt, patch-trunk.txt,
> paxos-entry.txt, paxos-multiple.txt
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hello,
> On our cluster logs are flooded with:
> {code:java}
> INFO [OptionalTasks:1] 2024-02-27 14:27:51,213
> PaxosCleanupLocalCoordinator.java:185 - Completed 0 uncommitted paxos
> instances for X on ranges
> [(9210458530128018597,-9222146739399525061],
> (-9222146739399525061,-9174246180597321488],
> (-9174246180597321488,-9155837684527496840],
> (-9155837684527496840,-9148981328078890812],
> (-9148981328078890812,-9141853035919151700],
> (-9141853035919151700,-9138872620588476741], {code}
> I cannot find anything in doc regarding this longline. Also this are huge log
> payloads that heavy flood system.log.
--
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-19445) Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
[
https://issues.apache.org/jira/browse/CASSANDRA-19445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19445:
--
Status: Needs Committer (was: Review In Progress)
> Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
> --
>
> Key: CASSANDRA-19445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19445
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Zbyszek Z
>Assignee: Tommy Stendahl
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: patch-4.1.txt, patch-5.0.txt, patch-trunk.txt,
> paxos-entry.txt, paxos-multiple.txt
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hello,
> On our cluster logs are flooded with:
> {code:java}
> INFO [OptionalTasks:1] 2024-02-27 14:27:51,213
> PaxosCleanupLocalCoordinator.java:185 - Completed 0 uncommitted paxos
> instances for X on ranges
> [(9210458530128018597,-9222146739399525061],
> (-9222146739399525061,-9174246180597321488],
> (-9174246180597321488,-9155837684527496840],
> (-9155837684527496840,-9148981328078890812],
> (-9148981328078890812,-9141853035919151700],
> (-9141853035919151700,-9138872620588476741], {code}
> I cannot find anything in doc regarding this longline. Also this are huge log
> payloads that heavy flood system.log.
--
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-19445) Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
[
https://issues.apache.org/jira/browse/CASSANDRA-19445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853182#comment-17853182
]
Stefan Miklosovic commented on CASSANDRA-19445:
---
not bad ... tracing stuff is CASSANDRA-19683
[CASSANDRA-19445-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19445-5.0]
{noformat}
java17_pre-commit_tests
java17_separate_tests
java11_pre-commit_tests
✓ j11_build 8m 1s
✓ j11_cqlsh_dtests_py38_vnode 9m 37s
✓ j11_cqlshlib_cython_tests 11m 21s
✓ j11_cqlshlib_tests 6m 34s
✓ j11_jvm_dtests 26m 8s
✓ j11_jvm_dtests_latest_vnode 16m 15s
✓ j11_simulator_dtests 5m 47s
✓ j11_utests_oa 15m 25s
✓ j11_utests_system_keyspace_directory18m 47s
✓ j17_cqlsh_dtests_py311 6m 22s
✓ j17_cqlsh_dtests_py311_vnode 6m 16s
✓ j17_cqlsh_dtests_py38_vnode 6m 28s
✓ j17_cqlshlib_cython_tests7m 12s
✓ j17_cqlshlib_tests 6m 24s
✓ j17_jvm_dtests 25m 46s
✓ j17_jvm_dtests_latest_vnode 16m 1s
✓ j17_unit_tests 14m 47s
✓ j17_utests_latest 14m 40s
✓ j17_utests_oa 14m 31s
✕ j11_cqlsh_dtests_py311 9m 32s
cql_tracing_test.TestCqlTracing test_tracing_default_impl
cql_tracing_test.TestCqlTracing test_tracing_simple
✕ j11_cqlsh_dtests_py311_vnode 6m 32s
cql_tracing_test.TestCqlTracing test_tracing_simple
✕ j11_cqlsh_dtests_py389m 26s
cql_tracing_test.TestCqlTracing test_tracing_default_impl
✕ j11_dtests 36m 18s
materialized_views_test.TestMaterializedViews test_rename_column_atomicity
✕ j11_dtests_latest 36m 21s
materialized_views_test.TestMaterializedViews test_rename_column_atomicity
read_repair_test.TestReadRepair
test_tracing_does_not_interfere_with_digest_calculation
✕ j11_dtests_vnode42m 30s
materialized_views_test.TestMaterializedViews test_rename_column_atomicity
read_repair_test.TestReadRepair
test_tracing_does_not_interfere_with_digest_calculation
✕ j11_unit_tests 15m 43s
org.apache.cassandra.tools.TopPartitionsTest
testServiceTopPartitionsSingleTable
✕ j11_utests_latest 16m 46s
org.apache.cassandra.cql3.validation.entities.SecondaryIndexOnStaticColumnTest
testIndexOnCompoundRowKey
✕ j17_cqlsh_dtests_py38 6m 5s
cql_tracing_test.TestCqlTracing test_tracing_unknown_impl
✕ j17_dtests 35m 22s
materialized_views_test.TestMaterializedViews test_rename_column_atomicity
✕ j17_dtests_latest 31m 46s
materialized_views_test.TestMaterializedViews test_rename_column_atomicity
✕ j17_dtests_vnode32m 58s
materialized_views_test.TestMaterializedViews test_rename_column_atomicity
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4374/workflows/b6f12eff-661a-48c1-bd8f-84fea006982b]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4374/workflows/979bca10-145f-4a2c-b36f-9fe144a5bb41]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4374/workflows/e46c1335-1bd3-4665-93be-a65039f89b9c]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4374/workflows/49be6bd5-5e73-4b31-8de9-020c7fc83b21]
> Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
> --
>
> Key: CASSANDRA-19445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19445
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Zbyszek Z
>Assignee: Tommy Stendahl
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: patch-4.1.txt, patch-5.0.txt, patch-trunk.txt,
> paxos-entry.txt, paxos-multiple.txt
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hello,
> On our cluster logs are flooded with:
> {code:java}
[jira] [Updated] (CASSANDRA-19692) ClassCastException on selection with where clause from system.local_metadata_log
[
https://issues.apache.org/jira/browse/CASSANDRA-19692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19692:
--
Bug Category: Parent values: Code(13163)
Complexity: Normal
Discovered By: Adhoc Test
Fix Version/s: 5.x
Severity: Normal
Status: Open (was: Triage Needed)
> ClassCastException on selection with where clause from
> system.local_metadata_log
>
>
> Key: CASSANDRA-19692
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19692
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> {code}
> select * from system.local_metadata_log where epoch = 1;
> NoHostAvailable: ('Unable to complete the operation against any hosts',
> {: message="java.lang.ClassCastException: class
> org.apache.cassandra.dht.Murmur3Partitioner$LongToken cannot be cast to class
> org.apache.cassandra.dht.ReversedLongLocalPartitioner$ReversedLongLocalToken
> (org.apache.cassandra.dht.Murmur3Partitioner$LongToken and
> org.apache.cassandra.dht.ReversedLongLocalPartitioner$ReversedLongLocalToken
> are in unnamed module of loader 'app')">})
> {code}
> same select but with "limit" works.
--
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-19692) ClassCastException on selection with where clause from system.local_metadata_log
Stefan Miklosovic created CASSANDRA-19692:
-
Summary: ClassCastException on selection with where clause from
system.local_metadata_log
Key: CASSANDRA-19692
URL: https://issues.apache.org/jira/browse/CASSANDRA-19692
Project: Cassandra
Issue Type: Bug
Components: Transactional Cluster Metadata
Reporter: Stefan Miklosovic
{code}
select * from system.local_metadata_log where epoch = 1;
NoHostAvailable: ('Unable to complete the operation against any hosts', {: })
{code}
same select but with "limit" works.
--
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-19658) Test failure: replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
[
https://issues.apache.org/jira/browse/CASSANDRA-19658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853144#comment-17853144
]
Stefan Miklosovic commented on CASSANDRA-19658:
---
+1
> Test failure:
> replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
> --
>
> Key: CASSANDRA-19658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19658
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> This can be seen failing in butler:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-5.0/failure/replace_address_test/TestReplaceAddress/test_restart_failed_replace
> {noformat}
> ccmlib.node.TimeoutError: 14 May 2024 18:19:08 [node1] after 120.13/120
> seconds Missing: ['FatClient /127.0.0.4:7000 has been silent for 3ms,
> removing from gossip'] not found in system.log:
> {noformat}
--
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-19445) Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
[
https://issues.apache.org/jira/browse/CASSANDRA-19445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853034#comment-17853034
]
Stefan Miklosovic commented on CASSANDRA-19445:
---
5.0 failed the build quite spectacularly, I am rerunning it all to see if it
improves.
> Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
> --
>
> Key: CASSANDRA-19445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19445
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Zbyszek Z
>Assignee: Tommy Stendahl
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: patch-4.1.txt, patch-5.0.txt, patch-trunk.txt,
> paxos-entry.txt, paxos-multiple.txt
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hello,
> On our cluster logs are flooded with:
> {code:java}
> INFO [OptionalTasks:1] 2024-02-27 14:27:51,213
> PaxosCleanupLocalCoordinator.java:185 - Completed 0 uncommitted paxos
> instances for X on ranges
> [(9210458530128018597,-9222146739399525061],
> (-9222146739399525061,-9174246180597321488],
> (-9174246180597321488,-9155837684527496840],
> (-9155837684527496840,-9148981328078890812],
> (-9148981328078890812,-9141853035919151700],
> (-9141853035919151700,-9138872620588476741], {code}
> I cannot find anything in doc regarding this longline. Also this are huge log
> payloads that heavy flood system.log.
--
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-19445) Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
[
https://issues.apache.org/jira/browse/CASSANDRA-19445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853031#comment-17853031
]
Stefan Miklosovic commented on CASSANDRA-19445:
---
[CASSANDRA-19445-trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19445-trunk]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 17s
✓ j17_cqlsh_dtests_py311 6m 51s
✓ j17_cqlsh_dtests_py311_vnode 7m 12s
✓ j17_cqlsh_dtests_py386m 56s
✓ j17_cqlsh_dtests_py38_vnode 7m 13s
✓ j17_cqlshlib_cython_tests9m 29s
✓ j17_cqlshlib_tests 8m 33s
✓ j17_unit_tests 13m 59s
✓ j17_utests_latest16m 5s
✓ j17_utests_oa18m 5s
✕ j17_dtests 37m 5s
materialized_views_test.TestMaterializedViews test_rename_column_atomicity
pushed_notifications_test.TestPushedNotifications
test_move_single_node_localhost
✕ j17_dtests_latest 36m 14s
materialized_views_test.TestMaterializedViews test_rename_column_atomicity
read_repair_test.TestReadRepair
test_tracing_does_not_interfere_with_digest_calculation
✕ j17_dtests_vnode34m 44s
materialized_views_test.TestMaterializedViews test_rename_column_atomicity
read_repair_test.TestReadRepair
test_tracing_does_not_interfere_with_digest_calculation
✕ j17_jvm_dtests 25m 48s
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN TIMEOUTED
org.apache.cassandra.distributed.test.ReadSpeculationTest speculateTest
org.apache.cassandra.fuzz.sai.MultiNodeSAITest basicSaiTest TIMEOUTED
org.apache.cassandra.distributed.test.log.BounceIndexRebuildTest
bounceTest
✕ j17_jvm_dtests_latest_vnode 24m 55s
org.apache.cassandra.fuzz.sai.MultiNodeSAITest basicSaiTest TIMEOUTED
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4372/workflows/846bd7ad-f4dc-4d02-85a0-0328bec127bb]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4372/workflows/630e15c2-b2d1-4147-8e09-9250b7cf0d26]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4372/workflows/dce303ec-b529-4309-8586-aede9db15a8c]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4372/workflows/32ce14c9-ec59-4b9d-a3b1-604b3fa7d0bc]
> Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
> --
>
> Key: CASSANDRA-19445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19445
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Zbyszek Z
>Assignee: Tommy Stendahl
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: patch-4.1.txt, patch-5.0.txt, patch-trunk.txt,
> paxos-entry.txt, paxos-multiple.txt
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hello,
> On our cluster logs are flooded with:
> {code:java}
> INFO [OptionalTasks:1] 2024-02-27 14:27:51,213
> PaxosCleanupLocalCoordinator.java:185 - Completed 0 uncommitted paxos
> instances for X on ranges
> [(9210458530128018597,-9222146739399525061],
> (-9222146739399525061,-9174246180597321488],
> (-9174246180597321488,-9155837684527496840],
> (-9155837684527496840,-9148981328078890812],
> (-9148981328078890812,-9141853035919151700],
> (-9141853035919151700,-9138872620588476741], {code}
> I cannot find anything in doc regarding this longline. Also this are huge log
> payloads that heavy flood system.log.
--
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-19445) Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
[
https://issues.apache.org/jira/browse/CASSANDRA-19445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853030#comment-17853030
]
Stefan Miklosovic commented on CASSANDRA-19445:
---
[CASSANDRA-19445-4.1|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19445-4.1]
{noformat}
java11_pre-commit_tests
✓ j11_build1m 48s
✓ j11_cqlsh_dtests_py3_vnode 5m 38s
✓ j11_cqlshlib_cython_tests7m 35s
✓ j11_cqlshlib_tests 6m 30s
✓ j11_jvm_dtests_vnode11m 10s
✕ j11_cqlsh_dtests_py3 5m 44s
cql_tracing_test.TestCqlTracing test_tracing_default_impl
✕ j11_cqlsh_dtests_py311 5m 41s
cql_tracing_test.TestCqlTracing test_tracing_simple
✕ j11_cqlsh_dtests_py311_vnode 6m 0s
cql_tracing_test.TestCqlTracing test_tracing_simple
✕ j11_cqlsh_dtests_py385m 49s
cql_tracing_test.TestCqlTracing test_tracing_default_impl
✕ j11_cqlsh_dtests_py38_vnode 6m 20s
cql_tracing_test.TestCqlTracing test_tracing_simple
✕ j11_dtests 32m 33s
read_repair_test.TestReadRepair
test_tracing_does_not_interfere_with_digest_calculation
largecolumn_test.TestLargeColumn test_cleanup
✕ j11_dtests_vnode36m 28s
largecolumn_test.TestLargeColumn test_cleanup
read_repair_test.TestReadRepair
test_tracing_does_not_interfere_with_digest_calculation
✕ j11_jvm_dtests 14m 34s
org.apache.cassandra.distributed.test.ReadRepairTest
readRepairRTRangeMovementTest
✕ j11_unit_tests9m 4s
org.apache.cassandra.cql3.MemtableSizeTest testSize[skiplist]
java11_separate_tests
java8_pre-commit_tests
java8_separate_tests
{noformat}
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4370/workflows/72a479a4-107d-4813-ab91-26a95acb8569]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4370/workflows/b0dc421d-954e-4d4e-ad5c-d68e3f41aebf]
[java8_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4370/workflows/a13ff079-2ec3-452e-b57c-39d6526c0d47]
[java8_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4370/workflows/7828a5f4-f488-44de-be82-c7ab2901cb70]
> Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
> --
>
> Key: CASSANDRA-19445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19445
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Zbyszek Z
>Assignee: Tommy Stendahl
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: patch-4.1.txt, patch-5.0.txt, patch-trunk.txt,
> paxos-entry.txt, paxos-multiple.txt
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hello,
> On our cluster logs are flooded with:
> {code:java}
> INFO [OptionalTasks:1] 2024-02-27 14:27:51,213
> PaxosCleanupLocalCoordinator.java:185 - Completed 0 uncommitted paxos
> instances for X on ranges
> [(9210458530128018597,-9222146739399525061],
> (-9222146739399525061,-9174246180597321488],
> (-9174246180597321488,-9155837684527496840],
> (-9155837684527496840,-9148981328078890812],
> (-9148981328078890812,-9141853035919151700],
> (-9141853035919151700,-9138872620588476741], {code}
> I cannot find anything in doc regarding this longline. Also this are huge log
> payloads that heavy flood system.log.
--
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-19593) Transactional Guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-19593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852844#comment-17852844 ] Stefan Miklosovic commented on CASSANDRA-19593: --- Well, I completely forgot to actually bootstrap this stuff. The first node should commit all guardrails transformations to have some baseline for all other nodes to be added. > Transactional Guardrails > > > Key: CASSANDRA-19593 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19593 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails, Transactional Cluster Metadata >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > I think it is time to start to think about this more seriously. TCM is > getting into pretty nice shape and we might start to investigate how to do > this. -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19679: -- Fix Version/s: 5.1 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/87ee1ac7d291d64c08f7724c343a51f4e883b123 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.1 > > Attachments: after.png, alloc_after.html, alloc_after_fori.html, > alloc_before.html, image-2024-06-04-21-55-34-457.png, > image-2024-06-05-16-05-59-870.png > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). > The 'after' profile for a 50/50 workload shows a reduction from 4.58% > allocations down to 1.37%. For a 90/10 (w/r) workload we see 4.28% decrease > to 1.10%. -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19679: -- Status: Ready to Commit (was: Review In Progress) > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, alloc_after.html, alloc_after_fori.html, > alloc_before.html, image-2024-06-04-21-55-34-457.png, > image-2024-06-05-16-05-59-870.png > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). > The 'after' profile for a 50/50 workload shows a reduction from 4.58% > allocations down to 1.37%. For a 90/10 (w/r) workload we see 4.28% decrease > to 1.10%. -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19679: -- Reviewers: Benjamin Lerer, Stefan Miklosovic (was: Stefan Miklosovic) Status: Review In Progress (was: Needs Committer) > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, alloc_after.html, alloc_after_fori.html, > alloc_before.html, image-2024-06-04-21-55-34-457.png, > image-2024-06-05-16-05-59-870.png > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). > The 'after' profile for a 50/50 workload shows a reduction from 4.58% > allocations down to 1.37%. For a 90/10 (w/r) workload we see 4.28% decrease > to 1.10%. -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852744#comment-17852744 ] Stefan Miklosovic commented on CASSANDRA-19679: --- [~blerer] I noticed your comment about "MultiCBuilder". Could we target that later? Let's have this ticket dedicated to one logical change only. I have also created CASSANDRA-19673 a while ago. You could add all your ideas what to do there so it is easier to track? > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, alloc_after.html, alloc_after_fori.html, > alloc_before.html, image-2024-06-04-21-55-34-457.png, > image-2024-06-05-16-05-59-870.png > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). > The 'after' profile for a 50/50 workload shows a reduction from 4.58% > allocations down to 1.37%. For a 90/10 (w/r) workload we see 4.28% decrease > to 1.10%. -- 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-19445) Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
[
https://issues.apache.org/jira/browse/CASSANDRA-19445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852739#comment-17852739
]
Stefan Miklosovic commented on CASSANDRA-19445:
---
okay ... btw [~tommy_s], there is a typo in your patches
{code}
private final boolean autoReoair;
{code}
Anyway, I can fix that on commit.
Let's build this first.
> Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
> --
>
> Key: CASSANDRA-19445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19445
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Zbyszek Z
>Assignee: Tommy Stendahl
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: patch-4.1.txt, patch-5.0.txt, patch-trunk.txt,
> paxos-entry.txt, paxos-multiple.txt
>
>
> Hello,
> On our cluster logs are flooded with:
> {code:java}
> INFO [OptionalTasks:1] 2024-02-27 14:27:51,213
> PaxosCleanupLocalCoordinator.java:185 - Completed 0 uncommitted paxos
> instances for X on ranges
> [(9210458530128018597,-9222146739399525061],
> (-9222146739399525061,-9174246180597321488],
> (-9174246180597321488,-9155837684527496840],
> (-9155837684527496840,-9148981328078890812],
> (-9148981328078890812,-9141853035919151700],
> (-9141853035919151700,-9138872620588476741], {code}
> I cannot find anything in doc regarding this longline. Also this are huge log
> payloads that heavy flood system.log.
--
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-19686) ALTER KEYSPACE should cleanup available_ranges_v2 when removing a DC
[ https://issues.apache.org/jira/browse/CASSANDRA-19686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned CASSANDRA-19686: - Assignee: Stefan Miklosovic > ALTER KEYSPACE should cleanup available_ranges_v2 when removing a DC > > > Key: CASSANDRA-19686 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19686 > Project: Cassandra > Issue Type: Bug >Reporter: Jon Haddad >Assignee: Stefan Miklosovic >Priority: Normal > > The scenario: > New DC is added > Data is replicated to new DC for keyspace "mykeyspace" via a rebuild > DC is dropped in replication > DC is re-added to "mykeyspace" > When this happens, the user is unable to rebuild as available_ranges_v2 > thinks it's unnecessary. > We should remove mykeyspace from system.available_ranges_v2 when removing a > DC. > Found in 4.1 -- 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-19686) ALTER KEYSPACE should cleanup available_ranges_v2 when removing a DC
[ https://issues.apache.org/jira/browse/CASSANDRA-19686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852730#comment-17852730 ] Stefan Miklosovic commented on CASSANDRA-19686: --- I can take a look, thanks for reporting! > ALTER KEYSPACE should cleanup available_ranges_v2 when removing a DC > > > Key: CASSANDRA-19686 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19686 > Project: Cassandra > Issue Type: Bug >Reporter: Jon Haddad >Assignee: Stefan Miklosovic >Priority: Normal > > The scenario: > New DC is added > Data is replicated to new DC for keyspace "mykeyspace" via a rebuild > DC is dropped in replication > DC is re-added to "mykeyspace" > When this happens, the user is unable to rebuild as available_ranges_v2 > thinks it's unnecessary. > We should remove mykeyspace from system.available_ranges_v2 when removing a > DC. > Found in 4.1 -- 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-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[
https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852729#comment-17852729
]
Stefan Miklosovic edited comment on CASSANDRA-19671 at 6/6/24 11:06 AM:
[~arkn98]
this
{code}
if (!this.isTestTableStatsHolder())
this.initializeKeyspaces(probe, ignore, tableNames);
{code}
looks into
{code}
protected boolean isTestTableStatsHolder() {
return false;
}
{code}
in TableStatsHolder.
However, TableStatsPrinterTest uses "TestTableStatsHolder" (at the bottom of
the class) where "isTestTableStatsHolder" is overriden and it returns true.
Hence, to call initializeKeyspaces, you need "isTestTableStatsHolder" to return
false (so it is evaluated as true and initializeKeyspaces is called). You
probably achieve that by creating similar class to TestTableStatsHolder where
"isTestTableStatsHolder" returns false and you use that one in a test instead
of TestTableStatsHolder.
was (Author: smiklosovic):
[~arkn98]
this
{code}
if (!this.isTestTableStatsHolder())
this.initializeKeyspaces(probe, ignore, tableNames);
{code}
looks into
{code}
protected boolean isTestTableStatsHolder() {
return false;
}
{code}
in TableStatsHolder.
However, TableStatsPrinterTest uses "TestTableStatsHolder" (at the bottom of
the class) where "isTestTableStatsHolder" is overriden and it returns true.
Hence, to call initializeKeyspaces, you need "isTestTableStatsHolder" to return
false (so if is evaluated as true and initializeKeyspaces is called). You
probably achieve that by creating similar class to TestTableStatsHolder where
"isTestTableStatsHolder" returns false and you use that one in a test instead
of TestTableStatsHolder.
> Nodetool tabestats: add keyspace space used and table r/w ratio
> ---
>
> Key: CASSANDRA-19671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19671
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
> Attachments: plaintext-humanreadable.txt, plaintext.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Nodetool tabestats reports the space used live and total per table, but not
> for the entire keyspace. This would be useful information.
> Also, in the table level stats, it would be useful to have the read/write
> ratio. This metric is important in choosing compaction strategies such as
> LCS.
--
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-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[
https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852729#comment-17852729
]
Stefan Miklosovic edited comment on CASSANDRA-19671 at 6/6/24 11:06 AM:
[~arkn98]
this
{code}
if (!this.isTestTableStatsHolder())
this.initializeKeyspaces(probe, ignore, tableNames);
{code}
looks into
{code}
protected boolean isTestTableStatsHolder() {
return false;
}
{code}
in TableStatsHolder.
However, TableStatsPrinterTest uses "TestTableStatsHolder" (at the bottom of
the class) where "isTestTableStatsHolder" is overriden and it returns true.
Hence, to call initializeKeyspaces, you need "isTestTableStatsHolder" to return
false (so it is evaluated as true and initializeKeyspaces is called). You
probably achieve that by creating similar class to TestTableStatsHolder where
"isTestTableStatsHolder" returns false and you use that one in a test instead
of TestTableStatsHolder. Actually, as it returns "false" by default, you do not
need to override it at all.
was (Author: smiklosovic):
[~arkn98]
this
{code}
if (!this.isTestTableStatsHolder())
this.initializeKeyspaces(probe, ignore, tableNames);
{code}
looks into
{code}
protected boolean isTestTableStatsHolder() {
return false;
}
{code}
in TableStatsHolder.
However, TableStatsPrinterTest uses "TestTableStatsHolder" (at the bottom of
the class) where "isTestTableStatsHolder" is overriden and it returns true.
Hence, to call initializeKeyspaces, you need "isTestTableStatsHolder" to return
false (so it is evaluated as true and initializeKeyspaces is called). You
probably achieve that by creating similar class to TestTableStatsHolder where
"isTestTableStatsHolder" returns false and you use that one in a test instead
of TestTableStatsHolder.
> Nodetool tabestats: add keyspace space used and table r/w ratio
> ---
>
> Key: CASSANDRA-19671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19671
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
> Attachments: plaintext-humanreadable.txt, plaintext.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Nodetool tabestats reports the space used live and total per table, but not
> for the entire keyspace. This would be useful information.
> Also, in the table level stats, it would be useful to have the read/write
> ratio. This metric is important in choosing compaction strategies such as
> LCS.
--
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-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[
https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852729#comment-17852729
]
Stefan Miklosovic commented on CASSANDRA-19671:
---
[~arkn98]
this
{code}
if (!this.isTestTableStatsHolder())
this.initializeKeyspaces(probe, ignore, tableNames);
{code}
looks into
{code}
protected boolean isTestTableStatsHolder() {
return false;
}
{code}
in TableStatsHolder.
However, TableStatsPrinterTest uses "TestTableStatsHolder" (at the bottom of
the class) where "isTestTableStatsHolder" is overriden and it returns true.
Hence, to call initializeKeyspaces, you need "isTestTableStatsHolder" to return
false (so if is evaluated as true and initializeKeyspaces is called). You
probably achieve that by creating similar class to TestTableStatsHolder where
"isTestTableStatsHolder" returns false and you use that one in a test instead
of TestTableStatsHolder.
> Nodetool tabestats: add keyspace space used and table r/w ratio
> ---
>
> Key: CASSANDRA-19671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19671
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
> Attachments: plaintext-humanreadable.txt, plaintext.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Nodetool tabestats reports the space used live and total per table, but not
> for the entire keyspace. This would be useful information.
> Also, in the table level stats, it would be useful to have the read/write
> ratio. This metric is important in choosing compaction strategies such as
> LCS.
--
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-19445) Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
[
https://issues.apache.org/jira/browse/CASSANDRA-19445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19445:
--
Reviewers: Stefan Miklosovic, Stefan Miklosovic
Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic)
Status: Review In Progress (was: Patch Available)
> Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
> --
>
> Key: CASSANDRA-19445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19445
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Zbyszek Z
>Assignee: Tommy Stendahl
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: patch-4.1.txt, patch-5.0.txt, patch-trunk.txt,
> paxos-entry.txt, paxos-multiple.txt
>
>
> Hello,
> On our cluster logs are flooded with:
> {code:java}
> INFO [OptionalTasks:1] 2024-02-27 14:27:51,213
> PaxosCleanupLocalCoordinator.java:185 - Completed 0 uncommitted paxos
> instances for X on ranges
> [(9210458530128018597,-9222146739399525061],
> (-9222146739399525061,-9174246180597321488],
> (-9174246180597321488,-9155837684527496840],
> (-9155837684527496840,-9148981328078890812],
> (-9148981328078890812,-9141853035919151700],
> (-9141853035919151700,-9138872620588476741], {code}
> I cannot find anything in doc regarding this longline. Also this are huge log
> payloads that heavy flood system.log.
--
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-19445) Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
[
https://issues.apache.org/jira/browse/CASSANDRA-19445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19445:
--
Test and Documentation Plan: ci
Status: Patch Available (was: In Progress)
> Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
> --
>
> Key: CASSANDRA-19445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19445
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Zbyszek Z
>Assignee: Tommy Stendahl
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: patch-4.1.txt, patch-5.0.txt, patch-trunk.txt,
> paxos-entry.txt, paxos-multiple.txt
>
>
> Hello,
> On our cluster logs are flooded with:
> {code:java}
> INFO [OptionalTasks:1] 2024-02-27 14:27:51,213
> PaxosCleanupLocalCoordinator.java:185 - Completed 0 uncommitted paxos
> instances for X on ranges
> [(9210458530128018597,-9222146739399525061],
> (-9222146739399525061,-9174246180597321488],
> (-9174246180597321488,-9155837684527496840],
> (-9155837684527496840,-9148981328078890812],
> (-9148981328078890812,-9141853035919151700],
> (-9141853035919151700,-9138872620588476741], {code}
> I cannot find anything in doc regarding this longline. Also this are huge log
> payloads that heavy flood system.log.
--
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-19445) Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
[
https://issues.apache.org/jira/browse/CASSANDRA-19445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852725#comment-17852725
]
Stefan Miklosovic commented on CASSANDRA-19445:
---
I think this ticket is not "a bug". Strictly speaking it is an improvement. We
are not putting improvements into anything but trunk (under normal
circumstances). So I think that the best chance of success here is that we do
it for debug just for trunk.
[~bdeggleston] [~benedict] are you both OK with an improvement to trunk only?
> Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
> --
>
> Key: CASSANDRA-19445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19445
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Zbyszek Z
>Assignee: Tommy Stendahl
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: patch-4.1.txt, patch-5.0.txt, patch-trunk.txt,
> paxos-entry.txt, paxos-multiple.txt
>
>
> Hello,
> On our cluster logs are flooded with:
> {code:java}
> INFO [OptionalTasks:1] 2024-02-27 14:27:51,213
> PaxosCleanupLocalCoordinator.java:185 - Completed 0 uncommitted paxos
> instances for X on ranges
> [(9210458530128018597,-9222146739399525061],
> (-9222146739399525061,-9174246180597321488],
> (-9174246180597321488,-9155837684527496840],
> (-9155837684527496840,-9148981328078890812],
> (-9148981328078890812,-9141853035919151700],
> (-9141853035919151700,-9138872620588476741], {code}
> I cannot find anything in doc regarding this longline. Also this are huge log
> payloads that heavy flood system.log.
--
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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852724#comment-17852724 ] Stefan Miklosovic commented on CASSANDRA-19679: --- [~blerer] [~brandon.williams] are you ok with the build and the patch? > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, alloc_after.html, alloc_after_fori.html, > alloc_before.html, image-2024-06-04-21-55-34-457.png, > image-2024-06-05-16-05-59-870.png > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). > The 'after' profile for a 50/50 workload shows a reduction from 4.58% > allocations down to 1.37%. For a 90/10 (w/r) workload we see 4.28% decrease > to 1.10%. -- 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-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19676: -- Fix Version/s: 5.0-beta2 5.1 (was: 5.x) (was: 5.0-rc) Source Control Link: https://github.com/apache/cassandra/commit/1b4f898c32a8f882767f44d69b38ff85d85090ba Resolution: Fixed Status: Resolved (was: Ready to Commit) > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.0-beta2, 5.1 > > Attachments: after.png, image-2024-06-02-17-25-25-071.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. > easy-cass-stress command: > $ bin/easy-cass-stress run KeyValue -n 10m --maxwlat 10 -r 0.1 --rate 2 > --compaction twcs > -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852545#comment-17852545 ] Stefan Miklosovic edited comment on CASSANDRA-19679 at 6/5/24 7:55 PM: --- the build I posted above looks just fine, same failed tests as for the similar patch, I am +1 on that, looking for the second ack. was (Author: smiklosovic): the build I posted above looks just fine, same failed test as for the similar patch, I am +1 on that, looking for the second ack. > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, alloc_after.html, alloc_after_fori.html, > alloc_before.html, image-2024-06-04-21-55-34-457.png, > image-2024-06-05-16-05-59-870.png > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). > The 'after' profile for a 50/50 workload shows a reduction from 4.58% > allocations down to 1.37%. For a 90/10 (w/r) workload we see 4.28% decrease > to 1.10%. -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852545#comment-17852545 ] Stefan Miklosovic commented on CASSANDRA-19679: --- the build I posted above looks just fine, same failed test as for the similar patch, I am +1 on that, looking for the second ack. > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, alloc_after.html, alloc_after_fori.html, > alloc_before.html, image-2024-06-04-21-55-34-457.png, > image-2024-06-05-16-05-59-870.png > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). > The 'after' profile for a 50/50 workload shows a reduction from 4.58% > allocations down to 1.37%. For a 90/10 (w/r) workload we see 4.28% decrease > to 1.10%. -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852407#comment-17852407 ] Stefan Miklosovic commented on CASSANDRA-19679: --- working on it here https://app.circleci.com/pipelines/github/instaclustr/cassandra/4365/workflows/ca621f0a-56c1-4be2-a317-ce9b972bb59b > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, alloc_after.html, alloc_before.html, > image-2024-06-04-21-55-34-457.png > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). > The 'after' profile for a 50/50 workload shows a reduction from 4.58% > allocations down to 1.69%. For a 90/10 (w/r) workload we see 4.28% decrease > to 1.10%. -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852371#comment-17852371 ] Stefan Miklosovic commented on CASSANDRA-19679: --- [~samueldlightfoot] can you please prepare the PR for 5.0 branch? > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, alloc_after.html, alloc_before.html, > image-2024-06-04-21-55-34-457.png > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). > The 'after' profile for a 50/50 workload shows a reduction from 4.58% > allocations down to 1.69%. For a 90/10 (w/r) workload we see 4.28% decrease > to 1.10%. -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852359#comment-17852359 ] Stefan Miklosovic commented on CASSANDRA-19679: --- [~brandon.williams] would you mind to go over this one as well, please? [~samueldlightfoot] btw how does it look like in 5.0? Is this applicable there or not? > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, alloc_after.html, alloc_before.html, > image-2024-06-04-21-55-34-457.png > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). > The 'after' profile shows a reduction from 4.58% allocations down to 1.69% -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852358#comment-17852358 ] Stefan Miklosovic commented on CASSANDRA-19679: --- [~samueldlightfoot] thanks! I think it is time to invite another committer to take a look. > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, alloc_after.html, alloc_before.html, > image-2024-06-04-21-55-34-457.png > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). > The 'after' profile shows a reduction from 4.58% allocations down to 1.69% -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19679: -- Status: Review In Progress (was: Changes Suggested) > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, alloc_after.html, alloc_before.html, > image-2024-06-04-21-55-34-457.png > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). > The 'after' profile shows a reduction from 4.58% allocations down to 1.69% -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19679: -- Status: Needs Committer (was: Review In Progress) > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, alloc_after.html, alloc_before.html, > image-2024-06-04-21-55-34-457.png > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). > The 'after' profile shows a reduction from 4.58% allocations down to 1.69% -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852349#comment-17852349 ] Stefan Miklosovic commented on CASSANDRA-19679: --- [~samueldlightfoot] could you please benchmark it / profile it again to check that what we did in the review is still an improvement? > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: image-2024-06-04-21-55-34-457.png > > Time Spent: 2h > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19679: -- Status: Review In Progress (was: Patch Available) > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: image-2024-06-04-21-55-34-457.png > > Time Spent: 40m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19679: -- Status: Open (was: Triage Needed) > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: image-2024-06-04-21-55-34-457.png > > Time Spent: 40m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19679: -- Status: Patch Available (was: In Progress) > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: image-2024-06-04-21-55-34-457.png > > Time Spent: 40m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). -- 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-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19679: -- Status: Changes Suggested (was: Review In Progress) > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: image-2024-06-04-21-55-34-457.png > > Time Spent: 40m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). -- 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-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852321#comment-17852321 ] Stefan Miklosovic commented on CASSANDRA-19676: --- No worries [~samueldlightfoot], keep it delivering! I am planning to take a more holistic approach for this whole streams issue in a foreseeable future, you are very welcome to participate in that. > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: after.png, image-2024-06-02-17-25-25-071.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. > easy-cass-stress command: > $ bin/easy-cass-stress run KeyValue -n 10m --maxwlat 10 -r 0.1 --rate 2 > --compaction twcs > -- 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-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19676: -- Fix Version/s: 5.0-rc > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: after.png, image-2024-06-02-17-25-25-071.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. > easy-cass-stress command: > $ bin/easy-cass-stress run KeyValue -n 10m --maxwlat 10 -r 0.1 --rate 2 > --compaction twcs > -- 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-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19676: -- Status: Ready to Commit (was: Review In Progress) > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, image-2024-06-02-17-25-25-071.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. > easy-cass-stress command: > $ bin/easy-cass-stress run KeyValue -n 10m --maxwlat 10 -r 0.1 --rate 2 > --compaction twcs > -- 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-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852209#comment-17852209 ] Stefan Miklosovic edited comment on CASSANDRA-19676 at 6/4/24 9:59 PM: --- OK. I will merge this likely tomorrow or on Thursday and then I move to CASSANDRA-19679. Are we all ok with this one? I am. This shall go to 5.0 as I understand it, correct? was (Author: smiklosovic): OK. I will merge this likely tomorrow or on Thursday and then I move to CASSANDRA-19679. Are we all ok with this one? I am. > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, image-2024-06-02-17-25-25-071.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. > easy-cass-stress command: > $ bin/easy-cass-stress run KeyValue -n 10m --maxwlat 10 -r 0.1 --rate 2 > --compaction twcs > -- 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-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852209#comment-17852209 ] Stefan Miklosovic commented on CASSANDRA-19676: --- OK. I will merge this likely tomorrow or on Thursday and then I move to CASSANDRA-19679. Are we all ok with this one? I am. > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, image-2024-06-02-17-25-25-071.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. > easy-cass-stress command: > $ bin/easy-cass-stress run KeyValue -n 10m --maxwlat 10 -r 0.1 --rate 2 > --compaction twcs > -- 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-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[ https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851902#comment-17851902 ] Stefan Miklosovic edited comment on CASSANDRA-19671 at 6/4/24 7:20 AM: --- I think it is good time to introduce more tests which would primarily test what you have done here and ideally tested more stats tablestats gives on keyspace level. Look into test/unit/org/apache/cassandra/tools/nodetool was (Author: smiklosovic): I think it is good time to introduce more tests which would primarily test what you have done here and ideally tested more stats tablestats gives on keyspace level. > Nodetool tabestats: add keyspace space used and table r/w ratio > --- > > Key: CASSANDRA-19671 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19671 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Arun Ganesh >Priority: Low > Attachments: plaintext-humanreadable.txt, plaintext.txt > > Time Spent: 10m > Remaining Estimate: 0h > > Nodetool tabestats reports the space used live and total per table, but not > for the entire keyspace. This would be useful information. > Also, in the table level stats, it would be useful to have the read/write > ratio. This metric is important in choosing compaction strategies such as > LCS. -- 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-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[ https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851902#comment-17851902 ] Stefan Miklosovic commented on CASSANDRA-19671: --- I think it is good time to introduce more tests which would primarily test what you have done here and ideally tested more stats tablestats gives on keyspace level. > Nodetool tabestats: add keyspace space used and table r/w ratio > --- > > Key: CASSANDRA-19671 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19671 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Arun Ganesh >Priority: Low > Attachments: plaintext-humanreadable.txt, plaintext.txt > > Time Spent: 10m > Remaining Estimate: 0h > > Nodetool tabestats reports the space used live and total per table, but not > for the entire keyspace. This would be useful information. > Also, in the table level stats, it would be useful to have the read/write > ratio. This metric is important in choosing compaction strategies such as > LCS. -- 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-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[ https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19671: -- Reviewers: Stefan Miklosovic Status: Review In Progress (was: Patch Available) > Nodetool tabestats: add keyspace space used and table r/w ratio > --- > > Key: CASSANDRA-19671 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19671 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Arun Ganesh >Priority: Low > Attachments: plaintext-humanreadable.txt, plaintext.txt > > Time Spent: 10m > Remaining Estimate: 0h > > Nodetool tabestats reports the space used live and total per table, but not > for the entire keyspace. This would be useful information. > Also, in the table level stats, it would be useful to have the read/write > ratio. This metric is important in choosing compaction strategies such as > LCS. -- 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-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851901#comment-17851901 ] Stefan Miklosovic edited comment on CASSANDRA-19676 at 6/4/24 6:01 AM: --- 5.0 build [https://app.circleci.com/pipelines/github/instaclustr/cassandra/4364/workflows/09dc15ac-31a1-41bf-90d4-319c0650304b] basically the same tests as in trunk failed. I have not tried to dig into that yet. On the other hand, they are "just" timeouts. was (Author: smiklosovic): 5.0 build [https://app.circleci.com/pipelines/github/instaclustr/cassandra/4364/workflows/09dc15ac-31a1-41bf-90d4-319c0650304b] basically the same tests as in trunk failed > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, image-2024-06-02-17-25-25-071.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. > easy-cass-stress command: > $ bin/easy-cass-stress run KeyValue -n 2000k --maxwlat 10 -r 0.1 --rate 5000 > --compaction twcs > -- 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-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851901#comment-17851901 ] Stefan Miklosovic commented on CASSANDRA-19676: --- 5.0 build [https://app.circleci.com/pipelines/github/instaclustr/cassandra/4364/workflows/09dc15ac-31a1-41bf-90d4-319c0650304b] basically the same tests as in trunk failed > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, image-2024-06-02-17-25-25-071.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. > easy-cass-stress command: > $ bin/easy-cass-stress run KeyValue -n 2000k --maxwlat 10 -r 0.1 --rate 5000 > --compaction twcs > -- 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-19462) cqlsh does not autocomplete table names in MacOS
[
https://issues.apache.org/jira/browse/CASSANDRA-19462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851819#comment-17851819
]
Stefan Miklosovic commented on CASSANDRA-19462:
---
I uninstall pyreadline from pip and it does not work anyway.
> cqlsh does not autocomplete table names in MacOS
>
>
> Key: CASSANDRA-19462
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19462
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
>
> I am on MacBook with Sonoma
> {code}
> $ uname -a
> Darwin stefanm-mac-0 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:59
> PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T6030 arm64
> {code}
> What is interesting is that ./bin/cqlsh works but when I am tabbing like
> {code}
> select * from system_auth.
> {code}
> This does not work.
> It does work when I install cqlsh from pip though.
> I have pyreadline installed,
> I have two pythons 3.10 and 3.9.6. I installed 3.10 from brew and 3.9.6 is
> from Sonoma itself.
> Could somebody with Mac verify that tab completion works (or does not) when
> invoking ./bin/cqlsh from Cassandra?
--
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-19462) cqlsh does not autocomplete table names in MacOS
[
https://issues.apache.org/jira/browse/CASSANDRA-19462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851817#comment-17851817
]
Stefan Miklosovic commented on CASSANDRA-19462:
---
[~bschoeni] it does work with pip installed cqlsh, I can verify that. But it
does not work doing ./bin/cqlsh (at least for me)
{noformat}
23:22 $ brew list
==> Formulae
bash docker-compose gnu-getopt libassuan libidn2
libtasn1 nettle p11-kit qrencode unbound
bash-git-prompt gettext gnupg libevent libksba
libunistring npth pass readline wget
ca-certificates git gnutls libgcrypt libnghttp2
libusb openldap pcre2 tig zsh-git-prompt
circleci gmp htop libgpg-error libpng
ncurses openssl@3 pinentry tree
{noformat}
{noformat}
$ python3 --version
Python 3.9.6
{noformat}
> cqlsh does not autocomplete table names in MacOS
>
>
> Key: CASSANDRA-19462
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19462
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
>
> I am on MacBook with Sonoma
> {code}
> $ uname -a
> Darwin stefanm-mac-0 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:59
> PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T6030 arm64
> {code}
> What is interesting is that ./bin/cqlsh works but when I am tabbing like
> {code}
> select * from system_auth.
> {code}
> This does not work.
> It does work when I install cqlsh from pip though.
> I have pyreadline installed,
> I have two pythons 3.10 and 3.9.6. I installed 3.10 from brew and 3.9.6 is
> from Sonoma itself.
> Could somebody with Mac verify that tab completion works (or does not) when
> invoking ./bin/cqlsh from Cassandra?
--
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-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851804#comment-17851804 ] Stefan Miklosovic commented on CASSANDRA-19676: --- let's build 5.0 patch too, working on it ... > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, image-2024-06-02-17-25-25-071.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. > easy-cass-stress command: > $ bin/easy-cass-stress run KeyValue -n 2000k --maxwlat 10 -r 0.1 --rate 5000 > --compaction twcs > -- 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-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851686#comment-17851686 ] Stefan Miklosovic commented on CASSANDRA-19676: --- well, I have mixed feelings here [https://app.circleci.com/pipelines/github/instaclustr/cassandra/4363/workflows/6ae88ab4-cb21-4643-8450-2cd533a6ebd3] mostly looks fine but I have never seen these tests failing and so consistently over multiple different jobs > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: image-2024-06-02-17-25-25-071.png > > Time Spent: 20m > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. -- 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-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19676: -- Status: Review In Progress (was: Patch Available) > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: image-2024-06-02-17-25-25-071.png > > Time Spent: 20m > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. -- 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-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851453#comment-17851453 ] Stefan Miklosovic commented on CASSANDRA-19676: --- It is very tempting to include this into 5.0.0 too but just trunk is also fine ... > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: image-2024-06-02-17-25-25-071.png > > Time Spent: 20m > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. -- 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-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19676: -- Test and Documentation Plan: ci Status: Patch Available (was: In Progress) > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: image-2024-06-02-17-25-25-071.png > > Time Spent: 20m > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. -- 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-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19676: -- Change Category: Performance Complexity: Low Hanging Fruit Fix Version/s: 5.x Reviewers: Stefan Miklosovic Status: Open (was: Triage Needed) > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: image-2024-06-02-17-25-25-071.png > > Time Spent: 20m > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. -- 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-19673) Investigate stream pipelines in hot paths
Stefan Miklosovic created CASSANDRA-19673: - Summary: Investigate stream pipelines in hot paths Key: CASSANDRA-19673 URL: https://issues.apache.org/jira/browse/CASSANDRA-19673 Project: Cassandra Issue Type: Task Reporter: Stefan Miklosovic Assignee: Stefan Miklosovic As per discussion in (1), map where we are at with stream pipelines api. Based on that, the next step should be to get rid of them and replace it with "for-s" but we are not there yet. https://lists.apache.org/thread/65glsjzkmpktzmns6j9wvr4nczvskx36 -- 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-19673) Investigate stream pipelines in hot paths
[ https://issues.apache.org/jira/browse/CASSANDRA-19673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19673: -- Change Category: Performance Complexity: Normal Component/s: Legacy/Core Fix Version/s: 5.x Status: Open (was: Triage Needed) > Investigate stream pipelines in hot paths > - > > Key: CASSANDRA-19673 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19673 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > > As per discussion in (1), map where we are at with stream pipelines api. > Based on that, the next step should be to get rid of them and replace it with > "for-s" but we are not there yet. > > https://lists.apache.org/thread/65glsjzkmpktzmns6j9wvr4nczvskx36 -- 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-19670) Add documentation about logging on the website
[ https://issues.apache.org/jira/browse/CASSANDRA-19670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19670: -- Source Control Link: https://github.com/apache/cassandra-website/commit/2884dab5e0d03aed2941a72adc69f2ef4e032e89 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Add documentation about logging on the website > -- > > Key: CASSANDRA-19670 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19670 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Labels: pull-request-available > Fix For: NA > > -- 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-19670) Add documentation about logging on the website
[ https://issues.apache.org/jira/browse/CASSANDRA-19670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19670: -- Status: Ready to Commit (was: Review In Progress) > Add documentation about logging on the website > -- > > Key: CASSANDRA-19670 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19670 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Labels: pull-request-available > Fix For: NA > > -- 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-19670) Add documentation about logging on the website
[ https://issues.apache.org/jira/browse/CASSANDRA-19670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19670: -- Reviewers: Michael Semb Wever Status: Review In Progress (was: Needs Committer) > Add documentation about logging on the website > -- > > Key: CASSANDRA-19670 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19670 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Labels: pull-request-available > Fix For: NA > > -- 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-19670) Add documentation about logging on the website
[ https://issues.apache.org/jira/browse/CASSANDRA-19670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19670: -- Test and Documentation Plan: local preview Status: Patch Available (was: In Progress) https://github.com/apache/cassandra-website/pull/272 > Add documentation about logging on the website > -- > > Key: CASSANDRA-19670 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19670 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Labels: pull-request-available > Fix For: NA > > -- 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-19670) Add documentation about logging on the website
[ https://issues.apache.org/jira/browse/CASSANDRA-19670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19670: -- Status: Needs Committer (was: Patch Available) > Add documentation about logging on the website > -- > > Key: CASSANDRA-19670 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19670 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Labels: pull-request-available > Fix For: NA > > -- 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-19670) Add documentation about logging on the website
Stefan Miklosovic created CASSANDRA-19670: - Summary: Add documentation about logging on the website Key: CASSANDRA-19670 URL: https://issues.apache.org/jira/browse/CASSANDRA-19670 Project: Cassandra Issue Type: Task Components: Documentation/Website Reporter: Stefan Miklosovic -- 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-19670) Add documentation about logging on the website
[ https://issues.apache.org/jira/browse/CASSANDRA-19670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19670: -- Change Category: Code Clarity Complexity: Low Hanging Fruit Fix Version/s: NA Assignee: Stefan Miklosovic Status: Open (was: Triage Needed) > Add documentation about logging on the website > -- > > Key: CASSANDRA-19670 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19670 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: NA > > -- 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-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19632: -- Fix Version/s: 5.1 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/8ba2f9e8c00cbb68cc1f30fc10de9212458c5756 Resolution: Fixed Status: Resolved (was: Ready to Commit) > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.1 > > Time Spent: 40m > Remaining Estimate: 0h > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- 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-19661) Cannot restart Cassandra 5 after creating a vector table and index
[
https://issues.apache.org/jira/browse/CASSANDRA-19661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850316#comment-17850316
]
Stefan Miklosovic edited comment on CASSANDRA-19661 at 5/29/24 9:57 AM:
I think I saw something like this very early in 5.0 development cycle but I can
not reproduce that anymore.
I wrote this trainer / prompt (1) which takes the sources or Cassandra, trains
them and one can ask questions against Cassandra codebase. It uses cassio and
langchain. I can not replicate the issue. After the training I can just restart
it fine.
If you want to try that, you need to pay to OpenAI to train it and put the
token into .env file where that script is like "OPENAI_API_KEY=..."
[https://gist.github.com/smiklosovic/98b52502df8061ec1d8c3546cf489628]
I am using the latest 5.0 branch.
I am *not* saying this is not an issue. I am just saying that what I tried it
on has not produced that error.
was (Author: smiklosovic):
I think I saw something like this very early in 5.0 development cycle but I can
not reproduce that anymore.
I wrote this trainer / prompt (1) which takes the sources or Cassandra, trains
them and one can ask questions against Cassandra codebase. It uses cassio and
langchain. I can not replicate the issue. After the training I can just restart
it fine.
If you want to try that, you need to pay to OpenAI to train it and put the
token into .env file where that script is like "OPENAI_API_KEY=..."
[https://gist.github.com/smiklosovic/98b52502df8061ec1d8c3546cf489628]
I am using the latest 5.0 branch.
> Cannot restart Cassandra 5 after creating a vector table and index
> --
>
> Key: CASSANDRA-19661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19661
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Sergio Rua
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> I'm using llama-index and llama3 to train a model. I'm using a very simple
> code that reads some *.txt files from local and uploads them to Cassandra and
> then creates the index:
>
> {code:java}
> # Create the index from documents
> index = VectorStoreIndex.from_documents(
> documents,
> service_context=vector_store.service_context,
> storage_context=storage_context,
> show_progress=True,
> ) {code}
> This works well and I'm able to use a Chat app to get responses from the
> Cassandra data. however, right after, I cannot restart Cassandra. It'll break
> with the following error:
>
> {code:java}
> INFO [PerDiskMemtableFlushWriter_0:7] 2024-05-23 08:23:20,102
> Flushing.java:179 - Completed flushing
> /data/cassandra/data/gpt/docs_20240523-10c8eaa018d811ef8dadf75182f3e2b4/da-6-bti-Data.db
> (124.236MiB) for commitlog position
> CommitLogPosition(segmentId=1716452305636, position=15336)
> [...]
> WARN [MemtableFlushWriter:1] 2024-05-23 08:28:29,575
> MemtableIndexWriter.java:92 - [gpt.docs.idx_vector_docs] Aborting index
> memtable flush for
> /data/cassandra/data/gpt/docs-aea77a80184b11ef8dadf75182f3e2b4/da-3-bti...{code}
> {code:java}
> java.lang.IllegalStateException: null
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:496)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.VectorPostings.computeRowIds(VectorPostings.java:76)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.OnHeapGraph.writeData(OnHeapGraph.java:313)
> at
> org.apache.cassandra.index.sai.memory.VectorMemoryIndex.writeDirect(VectorMemoryIndex.java:272)
> at
> org.apache.cassandra.index.sai.memory.MemtableIndex.writeDirect(MemtableIndex.java:110)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.flushVectorIndex(MemtableIndexWriter.java:192)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.complete(MemtableIndexWriter.java:117)
> at
> org.apache.cassandra.index.sai.disk.StorageAttachedIndexWriter.complete(StorageAttachedIndexWriter.java:185)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at
> java.base/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.cassandra.io.sstable.format.SSTableWriter.commit(SSTableWriter.java:289)
> at
> org.apache.cassandra.db.compaction.unified.ShardedMultiWriter.commit(ShardedMultiWriter.java:219)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1323)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1222)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at
>
[jira] [Commented] (CASSANDRA-19661) Cannot restart Cassandra 5 after creating a vector table and index
[
https://issues.apache.org/jira/browse/CASSANDRA-19661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850316#comment-17850316
]
Stefan Miklosovic commented on CASSANDRA-19661:
---
I think I saw something like this very early in 5.0 development cycle but I can
not reproduce that anymore.
I wrote this trainer / prompt (1) which takes the sources or Cassandra, trains
them and one can ask questions against Cassandra codebase. It uses cassio and
langchain. I can not replicate the issue. After the training I can just restart
it fine.
If you want to try that, you need to pay to OpenAI to train it and put the
token into .env file where that script is like "OPENAI_API_KEY=..."
[https://gist.github.com/smiklosovic/98b52502df8061ec1d8c3546cf489628]
I am using the latest 5.0 branch.
> Cannot restart Cassandra 5 after creating a vector table and index
> --
>
> Key: CASSANDRA-19661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19661
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Sergio Rua
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> I'm using llama-index and llama3 to train a model. I'm using a very simple
> code that reads some *.txt files from local and uploads them to Cassandra and
> then creates the index:
>
> {code:java}
> # Create the index from documents
> index = VectorStoreIndex.from_documents(
> documents,
> service_context=vector_store.service_context,
> storage_context=storage_context,
> show_progress=True,
> ) {code}
> This works well and I'm able to use a Chat app to get responses from the
> Cassandra data. however, right after, I cannot restart Cassandra. It'll break
> with the following error:
>
> {code:java}
> INFO [PerDiskMemtableFlushWriter_0:7] 2024-05-23 08:23:20,102
> Flushing.java:179 - Completed flushing
> /data/cassandra/data/gpt/docs_20240523-10c8eaa018d811ef8dadf75182f3e2b4/da-6-bti-Data.db
> (124.236MiB) for commitlog position
> CommitLogPosition(segmentId=1716452305636, position=15336)
> [...]
> WARN [MemtableFlushWriter:1] 2024-05-23 08:28:29,575
> MemtableIndexWriter.java:92 - [gpt.docs.idx_vector_docs] Aborting index
> memtable flush for
> /data/cassandra/data/gpt/docs-aea77a80184b11ef8dadf75182f3e2b4/da-3-bti...{code}
> {code:java}
> java.lang.IllegalStateException: null
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:496)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.VectorPostings.computeRowIds(VectorPostings.java:76)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.OnHeapGraph.writeData(OnHeapGraph.java:313)
> at
> org.apache.cassandra.index.sai.memory.VectorMemoryIndex.writeDirect(VectorMemoryIndex.java:272)
> at
> org.apache.cassandra.index.sai.memory.MemtableIndex.writeDirect(MemtableIndex.java:110)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.flushVectorIndex(MemtableIndexWriter.java:192)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.complete(MemtableIndexWriter.java:117)
> at
> org.apache.cassandra.index.sai.disk.StorageAttachedIndexWriter.complete(StorageAttachedIndexWriter.java:185)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at
> java.base/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.cassandra.io.sstable.format.SSTableWriter.commit(SSTableWriter.java:289)
> at
> org.apache.cassandra.db.compaction.unified.ShardedMultiWriter.commit(ShardedMultiWriter.java:219)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1323)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1222)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
> The table created by the script is as follows:
>
> {noformat}
> CREATE TABLE gpt.docs (
> partition_id text,
> row_id text,
> attributes_blob text,
> body_blob text,
> vector vector,
> metadata_s map,
> PRIMARY KEY (partition_id, row_id)
> ) WITH CLUSTERING ORDER BY (row_id ASC)
> AND additional_write_policy = '99p'
> AND allow_auto_snapshot = true
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL',
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850196#comment-17850196
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
[~mck] [~jlewandowski] [~claude] is (1) fine with you?
I am looking for final approval. I know Mick has approved on the PR but that
was a long time ago without CASSANDRA-19592 and cassandra.yaml configuration
embedding into "sstable" section.
(1) https://github.com/apache/cassandra/pull/3330
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-12937:
--
Status: Needs Committer (was: Patch Available)
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-12937:
--
Status: Patch Available (was: In Progress)
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850195#comment-17850195
]
Stefan Miklosovic edited comment on CASSANDRA-12937 at 5/28/24 10:12 PM:
-
I've hardened the path little bit and added few tests.
[CASSANDRA-12937-squashed|https://github.com/instaclustr/cassandra/tree/CASSANDRA-12937-squashed]
{noformat}
java17_pre-commit_tests
✓ j17_build 4m 3s
✓ j17_cqlsh_dtests_py311 7m 13s
✓ j17_cqlsh_dtests_py311_vnode 7m 37s
✓ j17_cqlsh_dtests_py386m 52s
✓ j17_cqlsh_dtests_py38_vnode 7m 21s
✓ j17_cqlshlib_cython_tests7m 56s
✓ j17_cqlshlib_tests 6m 46s
✓ j17_jvm_dtests_latest_vnode 27m 54s
✓ j17_unit_tests 14m 44s
✓ j17_utests_latest15m 3s
✕ j17_dtests 37m 42s
scrub_test.TestScrub test_standalone_scrub_essential_files_only
topology_test.TestTopology test_movement
✕ j17_dtests_latest 35m 24s
offline_tools_test.TestOfflineTools test_sstableverify
scrub_test.TestScrub test_standalone_scrub_essential_files_only
✕ j17_dtests_vnode36m 15s
scrub_test.TestScrub test_standalone_scrub_essential_files_only
✕ j17_jvm_dtests 29m 10s
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testOptionalMtlsModeDoNotAllowNonSSLConnections
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN
✕ j17_utests_oa17m 8s
org.apache.cassandra.db.compaction.CompactionStrategyManagerTest
testAutomaticUpgradeConcurrency
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4358/workflows/9fbc3590-1168-41f8-a7c8-a3fbb3dfc0b0]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4358/workflows/d2e65942-b99e-4927-bd65-85800e9d94e9]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4358/workflows/df51197e-c92e-454f-9c75-2f5eaee43bb8]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4358/workflows/6df36e29-d2cd-4838-b3b8-69e9113b295f]
was (Author: smiklosovic):
[CASSANDRA-12937-squashed|https://github.com/instaclustr/cassandra/tree/CASSANDRA-12937-squashed]
{noformat}
java17_pre-commit_tests
✓ j17_build 4m 3s
✓ j17_cqlsh_dtests_py311 7m 13s
✓ j17_cqlsh_dtests_py311_vnode 7m 37s
✓ j17_cqlsh_dtests_py386m 52s
✓ j17_cqlsh_dtests_py38_vnode 7m 21s
✓ j17_cqlshlib_cython_tests7m 56s
✓ j17_cqlshlib_tests 6m 46s
✓ j17_jvm_dtests_latest_vnode 27m 54s
✓ j17_unit_tests 14m 44s
✓ j17_utests_latest15m 3s
✕ j17_dtests 37m 42s
scrub_test.TestScrub test_standalone_scrub_essential_files_only
topology_test.TestTopology test_movement
✕ j17_dtests_latest 35m 24s
offline_tools_test.TestOfflineTools test_sstableverify
scrub_test.TestScrub test_standalone_scrub_essential_files_only
✕ j17_dtests_vnode36m 15s
scrub_test.TestScrub test_standalone_scrub_essential_files_only
✕ j17_jvm_dtests 29m 10s
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testOptionalMtlsModeDoNotAllowNonSSLConnections
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN
✕ j17_utests_oa17m 8s
org.apache.cassandra.db.compaction.CompactionStrategyManagerTest
testAutomaticUpgradeConcurrency
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4358/workflows/9fbc3590-1168-41f8-a7c8-a3fbb3dfc0b0]
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850195#comment-17850195
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
[CASSANDRA-12937-squashed|https://github.com/instaclustr/cassandra/tree/CASSANDRA-12937-squashed]
{noformat}
java17_pre-commit_tests
✓ j17_build 4m 3s
✓ j17_cqlsh_dtests_py311 7m 13s
✓ j17_cqlsh_dtests_py311_vnode 7m 37s
✓ j17_cqlsh_dtests_py386m 52s
✓ j17_cqlsh_dtests_py38_vnode 7m 21s
✓ j17_cqlshlib_cython_tests7m 56s
✓ j17_cqlshlib_tests 6m 46s
✓ j17_jvm_dtests_latest_vnode 27m 54s
✓ j17_unit_tests 14m 44s
✓ j17_utests_latest15m 3s
✕ j17_dtests 37m 42s
scrub_test.TestScrub test_standalone_scrub_essential_files_only
topology_test.TestTopology test_movement
✕ j17_dtests_latest 35m 24s
offline_tools_test.TestOfflineTools test_sstableverify
scrub_test.TestScrub test_standalone_scrub_essential_files_only
✕ j17_dtests_vnode36m 15s
scrub_test.TestScrub test_standalone_scrub_essential_files_only
✕ j17_jvm_dtests 29m 10s
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testOptionalMtlsModeDoNotAllowNonSSLConnections
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN
✕ j17_utests_oa17m 8s
org.apache.cassandra.db.compaction.CompactionStrategyManagerTest
testAutomaticUpgradeConcurrency
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4358/workflows/9fbc3590-1168-41f8-a7c8-a3fbb3dfc0b0]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4358/workflows/d2e65942-b99e-4927-bd65-85800e9d94e9]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4358/workflows/df51197e-c92e-454f-9c75-2f5eaee43bb8]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4358/workflows/6df36e29-d2cd-4838-b3b8-69e9113b295f]
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-19445) Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
[
https://issues.apache.org/jira/browse/CASSANDRA-19445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850194#comment-17850194
]
Stefan Miklosovic commented on CASSANDRA-19445:
---
[~tommy_s] could you git blame who has added it on INFO and ask them if DEBUG
is enough?
> Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
> --
>
> Key: CASSANDRA-19445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19445
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Zbyszek Z
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: paxos-entry.txt, paxos-multiple.txt
>
>
> Hello,
> On our cluster logs are flooded with:
> {code:java}
> INFO [OptionalTasks:1] 2024-02-27 14:27:51,213
> PaxosCleanupLocalCoordinator.java:185 - Completed 0 uncommitted paxos
> instances for X on ranges
> [(9210458530128018597,-9222146739399525061],
> (-9222146739399525061,-9174246180597321488],
> (-9174246180597321488,-9155837684527496840],
> (-9155837684527496840,-9148981328078890812],
> (-9148981328078890812,-9141853035919151700],
> (-9141853035919151700,-9138872620588476741], {code}
> I cannot find anything in doc regarding this longline. Also this are huge log
> payloads that heavy flood system.log.
--
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-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19632: -- Status: Ready to Commit (was: Review In Progress) > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 40m > Remaining Estimate: 0h > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- 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-19593) Transactional Guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-19593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849717#comment-17849717 ] Stefan Miklosovic commented on CASSANDRA-19593: --- I am formally stopping the progress on this as I do not look into it any further as we need to tackle the "general case". On the other hand, I would definitely appreciate if this work is just integrated to whatever will be proposed / implemented for general transactional configuration. Basically all which needs to be done is to read default_keyspace_rf from it plus add more tests and probably remove some functionality which I do not consider to be necessary (in terms of cep 24) > Transactional Guardrails > > > Key: CASSANDRA-19593 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19593 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails, Transactional Cluster Metadata >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > I think it is time to start to think about this more seriously. TCM is > getting into pretty nice shape and we might start to investigate how to do > this. -- 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-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849653#comment-17849653
]
Stefan Miklosovic commented on CASSANDRA-19632:
---
I have also changed the logging level to INFO and run the bench to see the
times as if trace was enabled (because it just logs on INFO by default)
Without wrapping it in isInfoEnabled, it takes around 41 microseconds to log.
With the check it takes around 46 microseconds. So the check takes around 5
microseconds and wrapping it makes it about 13% slower.
{noformat}
Result "org.apache.cassandra.test.microbench.LoggingBench.threeObjects":
N = 12306865
mean = 41340.392 ±(99.9%) 864.269 ns/op
Histogram, ns/op:
[ 0.000, 1250.000) = 12305828
[ 1250.000, 2500.000) = 0
[ 2500.000, 3750.000) = 0
[ 3750.000, 5000.000) = 0
[ 5000.000, 6250.000) = 0
[ 6250.000, 7500.000) = 0
[ 7500.000, 8750.000) = 0
[ 8750.000, 1.000) = 620
[1.000, 11250.000) = 375
[11250.000, 12500.000) = 34
[12500.000, 13750.000) = 8
[13750.000, 15000.000) = 0
[15000.000, 16250.000) = 0
[16250.000, 17500.000) = 0
[17500.000, 18750.000) = 0
Percentiles, ns/op:
p(0.) = 6640.000 ns/op
p(50.) = 23648.000 ns/op
p(90.) = 69760.000 ns/op
p(95.) = 90496.000 ns/op
p(99.) = 151296.000 ns/op
p(99.9000) = 381440.000 ns/op
p(99.9900) = 1861632.000 ns/op
p(99.9990) = 102760448.000 ns/op
p(99.) = 117178368.000 ns/op
p(100.) = 127401984.000 ns/op
# Run complete. Total time: 00:02:04
REMEMBER: The numbers below are just data. To gain reusable insights, you need
to follow up on
why the numbers are the way they are. Use profilers (see -prof, -lprof), design
factorial
experiments, perform baseline and negative tests that provide experimental
control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from
the domain experts.
Do not assume the numbers tell you what you want them to tell.
Benchmark Mode Cnt Score Error
Units
LoggingBench.threeObjects sample 12306865 41340.392 ± 864.269
ns/op
LoggingBench.threeObjects:p0.00 sample 6640.000
ns/op
LoggingBench.threeObjects:p0.50 sample 23648.000
ns/op
LoggingBench.threeObjects:p0.90 sample 69760.000
ns/op
LoggingBench.threeObjects:p0.95 sample 90496.000
ns/op
LoggingBench.threeObjects:p0.99 sample 151296.000
ns/op
LoggingBench.threeObjects:p0.999 sample 381440.000
ns/op
LoggingBench.threeObjects:p0. sample 1861632.000
ns/op
LoggingBench.threeObjects:p1.00 sample 127401984.000
ns/op
Process finished with exit code 0
Result
"org.apache.cassandra.test.microbench.LoggingBench.threeObjectsWithCheck":
N = 11186868
mean = 46985.745 ±(99.9%) 1093.366 ns/op
Histogram, ns/op:
[ 0.000, 1250.000) = 11185771
[ 1250.000, 2500.000) = 3
[ 2500.000, 3750.000) = 0
[ 3750.000, 5000.000) = 0
[ 5000.000, 6250.000) = 0
[ 6250.000, 7500.000) = 0
[ 7500.000, 8750.000) = 0
[ 8750.000, 1.000) = 0
[1.000, 11250.000) = 712
[11250.000, 12500.000) = 326
[12500.000, 13750.000) = 48
[13750.000, 15000.000) = 8
[15000.000, 16250.000) = 0
[16250.000, 17500.000) = 0
[17500.000, 18750.000) = 0
Percentiles, ns/op:
p(0.) = 6680.000 ns/op
p(50.) = 25952.000 ns/op
p(90.) = 77312.000 ns/op
p(95.) = 100608.000 ns/op
p(99.) = 171520.000 ns/op
p(99.9000) = 422400.000 ns/op
p(99.9900) = 5999162.162 ns/op
p(99.9990) = 117833728.000 ns/op
p(99.) = 131203072.000 ns/op
p(100.) = 138936320.000 ns/op
# Run complete. Total time: 00:02:04
REMEMBER: The numbers below are just data. To gain reusable insights, you need
to follow up on
why the numbers are the way they are. Use profilers (see -prof, -lprof), design
factorial
experiments, perform baseline and negative tests that provide experimental
control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from
the domain experts.
Do not assume the numbers tell you what you want them to tell.
Benchmark Mode Cnt Score
Error Units
LoggingBench.threeObjectsWithCheck sample 11186868 46985.745 ±
1093.366 ns/op
[jira] [Commented] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849647#comment-17849647
]
Stefan Miklosovic commented on CASSANDRA-19632:
---
I tried to benchmark this, I was tracing three-param message with and without
isTraceEnabled check.
{noformat}
package org.apache.cassandra.test.microbench;
import java.util.concurrent.TimeUnit;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Fork;
import org.openjdk.jmh.annotations.Measurement;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.annotations.Threads;
import org.openjdk.jmh.annotations.Warmup;
@BenchmarkMode(Mode.SampleTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 3, time = 1)
@Measurement(iterations = 6, time = 20)
@Fork(value = 1, jvmArgsAppend = { "-Xmx256M", "-Djmh.executor=CUSTOM",
"-Djmh.executor.class=org.apache.cassandra.test.microbench.FastThreadExecutor"})
@Threads(8)
@State(Scope.Benchmark)
public class LoggingBench
{
private static final Logger logger =
LoggerFactory.getLogger(LoggingBench.class);
private static final MyObject myObject = new MyObject();
@Benchmark
public void threeObjects()
{
logger.trace("this is a message with one parameter {}, {}, {}",
myObject, myObject, myObject);
}
@Benchmark
public void threeObjectsWithCheck()
{
if (logger.isTraceEnabled())
logger.trace("this is a message with one parameter {}, {}, {}",
myObject, myObject, myObject);
}
public static class MyObject
{
@Override
public String toString()
{
return "MyObject{}";
}
}
}
{noformat}
Results:
{noformat}
# JMH version: 1.37
# VM version: JDK 11.0.12, OpenJDK 64-Bit Server VM, 11.0.12+7
# VM invoker: /home/fermat/.sdkman/candidates/java/11.0.12-open/bin/java
# VM options:
-javaagent:/home/fermat/.local/share/JetBrains/Toolbox/apps/IDEA-U/ch-0/233.15026.9/lib/idea_rt.jar=40847:/home/fermat/.local/share/JetBrains/Toolbox/apps/IDEA-U/ch-0/233.15026.9/bin
-Dfile.encoding=UTF-8 -Xmx256M -Djmh.executor=CUSTOM
-Djmh.executor.class=org.apache.cassandra.test.microbench.FastThreadExecutor
# Blackhole mode: full + dont-inline hint (auto-detected, use
-Djmh.blackhole.autoDetect=false to disable)
# Warmup: 3 iterations, 1 s each
# Measurement: 6 iterations, 20 s each
# Timeout: 10 min per iteration
# Threads: 8 threads, will synchronize iterations
# Benchmark mode: Sampling time
# Benchmark: org.apache.cassandra.test.microbench.LoggingBench.threeObjects
# Run progress: 0.00% complete, ETA 00:04:06
# Fork: 1 of 1
# Warmup Iteration 1: DEBUG [main] 2024-05-27 09:10:02,600
InternalLoggerFactory.java:63 - Using SLF4J as the default logging framework
44.788 ±(99.9%) 10.007 ns/op
# Warmup Iteration 2: 34.661 ±(99.9%) 1.355 ns/op
# Warmup Iteration 3: 26.908 ±(99.9%) 0.543 ns/op
Iteration 1: 26.945 ±(99.9%) 0.113 ns/op
p0.00: 20.000 ns/op
p0.50: 30.000 ns/op
p0.90: 30.000 ns/op
p0.95: 30.000 ns/op
p0.99: 31.000 ns/op
p0.999: 50.000 ns/op
p0.: 1857.329 ns/op
p1.00: 53312.000 ns/op
Iteration 2: 27.736 ±(99.9%) 0.136 ns/op
p0.00: 20.000 ns/op
p0.50: 30.000 ns/op
p0.90: 30.000 ns/op
p0.95: 30.000 ns/op
p0.99: 31.000 ns/op
p0.999: 50.000 ns/op
p0.: 2592.000 ns/op
p1.00: 29376.000 ns/op
Iteration 3: 28.188 ±(99.9%) 0.088 ns/op
p0.00: 20.000 ns/op
p0.50: 30.000 ns/op
p0.90: 30.000 ns/op
p0.95: 31.000 ns/op
p0.99: 40.000 ns/op
p0.999: 60.000 ns/op
p0.: 170.000 ns/op
p1.00: 94720.000 ns/op
Iteration 4: 28.113 ±(99.9%) 0.099 ns/op
p0.00: 20.000 ns/op
p0.50: 30.000 ns/op
p0.90: 30.000 ns/op
p0.95: 31.000 ns/op
p0.99: 31.000 ns/op
p0.999: 50.000 ns/op
p0.: 330.000 ns/op
p1.00: 41216.000 ns/op
Iteration 5: 28.349 ±(99.9%) 0.071 ns/op
p0.00: 20.000 ns/op
p0.50: 30.000 ns/op
p0.90: 30.000 ns/op
p0.95: 31.000 ns/op
p0.99: 40.000 ns/op
p0.999: 60.000 ns/op
p0.: 181.000 ns/op
[jira] [Commented] (CASSANDRA-19654) Update bundled Cassandra cassandra-driver-core dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-19654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849228#comment-17849228 ] Stefan Miklosovic commented on CASSANDRA-19654: --- I am not sure if we are going to bump the versions in a patch releases. We should carefully evaluate what impact it has because people bumping a patch release in their integrations do not expect that their dependency tree would be changed suddenly and substantially. cc [~brandon.williams] > Update bundled Cassandra cassandra-driver-core dependency > - > > Key: CASSANDRA-19654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19654 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Jackson Fleming >Priority: Normal > > There's a dependency in Cassandra project on an old version of the Java > driver cassandra-driver-core - 3.11.0 in the 4.0 and later releases of > Cassandra > > (For example on the 4.1 branch > [https://github.com/apache/cassandra/blob/cassandra-4.1/build.xml#L691)] > > It appears that this dependency may have some security vulnerabilities in > transitive dependencies. > But also this is a very old version of the driver, ideally it would be > aligned to a newer version, I would suggest either 3.11.5 which is the latest > in that line of driver versions > [https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core|https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core)] > or this gets updated to the latest 4.x driver (as of writing that's 4.18.1 in > [https://mvnrepository.com/artifact/org.apache.cassandra/java-driver-core] ) > but this seems like a larger undertaking. -- 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-19654) Update bundled Cassandra cassandra-driver-core dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-19654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849228#comment-17849228 ] Stefan Miklosovic edited comment on CASSANDRA-19654 at 5/24/24 9:25 AM: I am not sure if we are going to bump the versions in a patch release. We should carefully evaluate what impact it has because people bumping a patch release in their integrations do not expect that their dependency tree would be changed suddenly and substantially. cc [~brandon.williams] was (Author: smiklosovic): I am not sure if we are going to bump the versions in a patch releases. We should carefully evaluate what impact it has because people bumping a patch release in their integrations do not expect that their dependency tree would be changed suddenly and substantially. cc [~brandon.williams] > Update bundled Cassandra cassandra-driver-core dependency > - > > Key: CASSANDRA-19654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19654 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Jackson Fleming >Priority: Normal > > There's a dependency in Cassandra project on an old version of the Java > driver cassandra-driver-core - 3.11.0 in the 4.0 and later releases of > Cassandra > > (For example on the 4.1 branch > [https://github.com/apache/cassandra/blob/cassandra-4.1/build.xml#L691)] > > It appears that this dependency may have some security vulnerabilities in > transitive dependencies. > But also this is a very old version of the driver, ideally it would be > aligned to a newer version, I would suggest either 3.11.5 which is the latest > in that line of driver versions > [https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core|https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core)] > or this gets updated to the latest 4.x driver (as of writing that's 4.18.1 in > [https://mvnrepository.com/artifact/org.apache.cassandra/java-driver-core] ) > but this seems like a larger undertaking. -- 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-19450) Hygiene updates for warnings and pytests
[ https://issues.apache.org/jira/browse/CASSANDRA-19450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19450: -- Fix Version/s: 5.1 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/6701259bce91672a7c3ca9fb77ea7b040e9c Resolution: Fixed Status: Resolved (was: Ready to Commit) > Hygiene updates for warnings and pytests > > > Key: CASSANDRA-19450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19450 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Low > Fix For: 5.1 > > > > * -Update 'Warning' message to write to stderr- > * -Replace TimeoutError Exception with builtin (since Python 3.3)- > * -Remove re.pattern_type (removed since Python 3.7)- > * Fix mutable arg [] in test/run_cqlsh.py read_until() > * Remove redirect of stderr to stdout in pytest fixture with tty=false; > Deprecation warnings can otherwise fail unit tests when stdout & stderr > output is combined. > * Fix several pycodestyle issues -- 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-19450) Hygiene updates for warnings and pytests
[
https://issues.apache.org/jira/browse/CASSANDRA-19450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849221#comment-17849221
]
Stefan Miklosovic edited comment on CASSANDRA-19450 at 5/24/24 8:51 AM:
I think this just looks fine. Going to ship it.
[CASSANDRA-19450|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19450]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 14s
✓ j17_cqlsh_dtests_py311 6m 57s
✓ j17_cqlsh_dtests_py311_vnode 7m 22s
✓ j17_cqlsh_dtests_py386m 55s
✓ j17_cqlsh_dtests_py38_vnode 7m 17s
✓ j17_cqlshlib_cython_tests7m 16s
✓ j17_cqlshlib_tests 6m 23s
✓ j17_dtests 36m 35s
✓ j17_dtests_vnode 35m 1s
✓ j17_unit_tests 14m 20s
✓ j17_utests_oa13m 2s
✕ j17_dtests_latest 35m 19s
streaming_test.TestStreaming test_zerocopy_streaming_no_replication
✕ j17_jvm_dtests 24m 34s
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
testRepair TIMEOUTED
✕ j17_jvm_dtests_latest_vnode 24m 15s
org.apache.cassandra.distributed.test.jmx.JMXFeatureTest
testOneNetworkInterfaceProvisioning
✕ j17_utests_latest 15m 50s
org.apache.cassandra.tcm.DiscoverySimulationTest discoveryTest
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/5f522c11-aae5-4915-8102-f79807d661d6]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/87429218-e1e2-4589-b879-09f9e80ef3b6]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/222ad871-683e-4a14-919d-9e3e92def96c]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/3cd71329-9b0f-4f48-ae2b-33fd057520c9]
streaming_test.py::TestStreaming::test_zerocopy_streaming_no_replication was
verified to work locally
was (Author: smiklosovic):
I think this just looks fine. Going to ship it.
[CASSANDRA-19450|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19450]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 14s
✓ j17_cqlsh_dtests_py311 6m 57s
✓ j17_cqlsh_dtests_py311_vnode 7m 22s
✓ j17_cqlsh_dtests_py386m 55s
✓ j17_cqlsh_dtests_py38_vnode 7m 17s
✓ j17_cqlshlib_cython_tests7m 16s
✓ j17_cqlshlib_tests 6m 23s
✓ j17_dtests 36m 35s
✓ j17_dtests_vnode 35m 1s
✓ j17_unit_tests 14m 20s
✓ j17_utests_oa13m 2s
✕ j17_dtests_latest 35m 19s
streaming_test.TestStreaming test_zerocopy_streaming_no_replication
✕ j17_jvm_dtests 24m 34s
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
testRepair TIMEOUTED
✕ j17_jvm_dtests_latest_vnode 24m 15s
org.apache.cassandra.distributed.test.jmx.JMXFeatureTest
testOneNetworkInterfaceProvisioning
✕ j17_utests_latest 15m 50s
org.apache.cassandra.tcm.DiscoverySimulationTest discoveryTest
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/5f522c11-aae5-4915-8102-f79807d661d6]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/87429218-e1e2-4589-b879-09f9e80ef3b6]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/222ad871-683e-4a14-919d-9e3e92def96c]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/3cd71329-9b0f-4f48-ae2b-33fd057520c9]
> Hygiene updates for warnings and pytests
>
>
> Key: CASSANDRA-19450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19450
>
[jira] [Commented] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849222#comment-17849222 ] Stefan Miklosovic commented on CASSANDRA-19632: --- [~brandon.williams] any feedback on the second patch I just provided CI for above? > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 40m > Remaining Estimate: 0h > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- 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-19450) Hygiene updates for warnings and pytests
[
https://issues.apache.org/jira/browse/CASSANDRA-19450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849221#comment-17849221
]
Stefan Miklosovic commented on CASSANDRA-19450:
---
I think this just looks fine. Going to ship it.
[CASSANDRA-19450|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19450]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 14s
✓ j17_cqlsh_dtests_py311 6m 57s
✓ j17_cqlsh_dtests_py311_vnode 7m 22s
✓ j17_cqlsh_dtests_py386m 55s
✓ j17_cqlsh_dtests_py38_vnode 7m 17s
✓ j17_cqlshlib_cython_tests7m 16s
✓ j17_cqlshlib_tests 6m 23s
✓ j17_dtests 36m 35s
✓ j17_dtests_vnode 35m 1s
✓ j17_unit_tests 14m 20s
✓ j17_utests_oa13m 2s
✕ j17_dtests_latest 35m 19s
streaming_test.TestStreaming test_zerocopy_streaming_no_replication
✕ j17_jvm_dtests 24m 34s
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
testRepair TIMEOUTED
✕ j17_jvm_dtests_latest_vnode 24m 15s
org.apache.cassandra.distributed.test.jmx.JMXFeatureTest
testOneNetworkInterfaceProvisioning
✕ j17_utests_latest 15m 50s
org.apache.cassandra.tcm.DiscoverySimulationTest discoveryTest
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/5f522c11-aae5-4915-8102-f79807d661d6]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/87429218-e1e2-4589-b879-09f9e80ef3b6]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/222ad871-683e-4a14-919d-9e3e92def96c]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/3cd71329-9b0f-4f48-ae2b-33fd057520c9]
> Hygiene updates for warnings and pytests
>
>
> Key: CASSANDRA-19450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19450
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Low
> Fix For: 5.x
>
>
>
> * -Update 'Warning' message to write to stderr-
> * -Replace TimeoutError Exception with builtin (since Python 3.3)-
> * -Remove re.pattern_type (removed since Python 3.7)-
> * Fix mutable arg [] in test/run_cqlsh.py read_until()
> * Remove redirect of stderr to stdout in pytest fixture with tty=false;
> Deprecation warnings can otherwise fail unit tests when stdout & stderr
> output is combined.
> * Fix several pycodestyle issues
--
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-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849220#comment-17849220
]
Stefan Miklosovic commented on CASSANDRA-19632:
---
Looks fine, I think that cqlsh_tests.test_cqlsh.TestCqlsh test_describe is the
result of CASSANDRA-19592 and this build was not rebased againt the current
trunk
[CASSANDRA-19632-2|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19632-2]
{noformat}
java17_pre-commit_tests
✓ j17_build5m 12s
✓ j17_cqlsh_dtests_py311_vnode 7m 45s
✓ j17_cqlsh_dtests_py386m 56s
✓ j17_cqlsh_dtests_py38_vnode 7m 20s
✓ j17_cqlshlib_cython_tests9m 35s
✓ j17_cqlshlib_tests 9m 30s
✓ j17_dtests 35m 34s
✓ j17_dtests_vnode36m 38s
✓ j17_jvm_dtests_latest_vnode 20m 44s
✓ j17_unit_tests 14m 15s
✓ j17_utests_latest 14m 27s
✓ j17_utests_oa 14m 21s
✕ j17_cqlsh_dtests_py311 6m 41s
cqlsh_tests.test_cqlsh.TestCqlsh test_describe
✕ j17_dtests_latest 36m 44s
auth_test.TestAuthUnavailable test_authorization_handle_unavailable
configuration_test.TestConfiguration test_change_durable_writes
✕ j17_jvm_dtests 22m 46s
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4344/workflows/f9410f3a-9af4-4924-a2c8-44fc3d7384c0]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4344/workflows/5a2470b3-7dee-4b50-98c7-1a5f9b50e650]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4344/workflows/7263d3ca-ef7f-4499-9fff-fbb77617b613]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4344/workflows/91f98de5-c3e5-45bb-9737-a6d98922fedf]
> wrap tracing logs in isTraceEnabled across the codebase
> ---
>
> Key: CASSANDRA-19632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19632
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Our usage of logger.isTraceEnabled across the codebase is inconsistent. This
> would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade]
> suggested.
> We should fix this at least in trunk and 5.0 (not critical though) and
> probably come up with a checkstyle rule to prevent not calling isTraceEnabled
> while logging with TRACE level.
--
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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849218#comment-17849218
]
Stefan Miklosovic edited comment on CASSANDRA-12937 at 5/24/24 8:36 AM:
Seems reasonably clean ...
What I have not done is that the idea [~jlewandowski] had with "if some config
parameter is not in cql statement just merge the values from cassandra.yaml"
because it is quite tricky to get that right. We would need to know what values
were specfied and then diffing what is not there and then validating that such
combination makes sense (and if it does not, should we fail otherwise valid CQL
statement just because we happened to merge values from cassandra.yaml and that
combination was not right? I do not think so).
Let's just go with a simple case of "if compression is not specified just take
the defaults from cassandra.yaml" rather then trying to merge the configs ...
Too much of a hassle, might come as an improvement if somebody is really after
that.
I will try to come up with more tests and I think that sometimes next week this
should be all completed and ready for review again.
[CASSANDRA-12937-squashed|https://github.com/instaclustr/cassandra/tree/CASSANDRA-12937-squashed]
{noformat}
java17_pre-commit_tests
✓ j17_build 4m 7s
✓ j17_cqlsh_dtests_py311 7m 11s
✓ j17_cqlsh_dtests_py311_vnode 7m 18s
✓ j17_cqlsh_dtests_py386m 58s
✓ j17_cqlsh_dtests_py38_vnode 7m 1s
✓ j17_cqlshlib_cython_tests7m 26s
✓ j17_cqlshlib_tests 6m 50s
✓ j17_unit_tests 17m 36s
✓ j17_utests_oa 15m 39s
✕ j17_dtests 37m 48s
scrub_test.TestScrub test_standalone_scrub_essential_files_only
topology_test.TestTopology test_movement
✕ j17_dtests_latest 35m 36s
offline_tools_test.TestOfflineTools test_sstableverify
scrub_test.TestScrub test_standalone_scrub_essential_files_only
configuration_test.TestConfiguration test_change_durable_writes
✕ j17_dtests_vnode35m 11s
scrub_test.TestScrub test_standalone_scrub_essential_files_only
✕ j17_jvm_dtests 28m 15s
✕ j17_jvm_dtests_latest_vnode 27m 59s
org.apache.cassandra.fuzz.harry.integration.model.ConcurrentQuiescentCheckerIntegrationTest
testConcurrentReadWriteWorkload
✕ j17_utests_latest 14m 34s
org.apache.cassandra.tcm.DiscoverySimulationTest discoveryTest
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/a68e4fb0-bd7a-4758-841c-6b4b0fe22865]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/fa57a86d-d120-4304-bbdf-a6cf8fefc4d2]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/91afc77c-54fe-4369-9cb9-ababa3568e16]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/71add260-9c68-4d87-9d5a-99863a01bb3f]
was (Author: smiklosovic):
Seems reasonably clean ...
What I have not done is that the idea Jacek had with "if some config parameter
is not in cql statement just merge the values from cassandra.yaml" because it
is quite tricky to get that right. We would need to know what values were
specfied and then diffing what is not there and then validating that such
combination makes sense (and if it does not, should we fail otherwise valid CQL
statement just because we happened to merge values from cassandra.yaml and that
combination was not right? I do not think so).
Let's just go with a simple case of "if compression is not specified just take
the defaults from cassandra.yaml" rather then trying to merge the configs ...
Too much of a hassle, might come as an improvement if somebody is really after
that.
I will try to come up with more tests and I think that sometimes next week this
should be all completed and ready for review again.
[CASSANDRA-12937-squashed|https://github.com/instaclustr/cassandra/tree/CASSANDRA-12937-squashed]
{noformat}
java17_pre-commit_tests
✓ j17_build 4m 7s
✓ j17_cqlsh_dtests_py311 7m 11s
✓ j17_cqlsh_dtests_py311_vnode 7m 18s
✓ j17_cqlsh_dtests_py386m 58s
✓
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849218#comment-17849218
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
Seems reasonably clean ...
What I have not done is that the idea Jacek had with "if some config parameter
is not in cql statement just merge the values from cassandra.yaml" because it
is quite tricky to get that right. We would need to know what values were
specfied and then diffing what is not there and then validating that such
combination makes sense (and if it does not, should we fail otherwise valid CQL
statement just because we happened to merge values from cassandra.yaml and that
combination was not right? I do not think so).
Let's just go with a simple case of "if compression is not specified just take
the defaults from cassandra.yaml" rather then trying to merge the configs ...
Too much of a hassle, might come as an improvement if somebody is really after
that.
I will try to come up with more tests and I think that sometimes next week this
should be all completed and ready for review again.
[CASSANDRA-12937-squashed|https://github.com/instaclustr/cassandra/tree/CASSANDRA-12937-squashed]
{noformat}
java17_pre-commit_tests
✓ j17_build 4m 7s
✓ j17_cqlsh_dtests_py311 7m 11s
✓ j17_cqlsh_dtests_py311_vnode 7m 18s
✓ j17_cqlsh_dtests_py386m 58s
✓ j17_cqlsh_dtests_py38_vnode 7m 1s
✓ j17_cqlshlib_cython_tests7m 26s
✓ j17_cqlshlib_tests 6m 50s
✓ j17_unit_tests 17m 36s
✓ j17_utests_oa 15m 39s
✕ j17_dtests 37m 48s
scrub_test.TestScrub test_standalone_scrub_essential_files_only
topology_test.TestTopology test_movement
✕ j17_dtests_latest 35m 36s
offline_tools_test.TestOfflineTools test_sstableverify
scrub_test.TestScrub test_standalone_scrub_essential_files_only
configuration_test.TestConfiguration test_change_durable_writes
✕ j17_dtests_vnode35m 11s
scrub_test.TestScrub test_standalone_scrub_essential_files_only
✕ j17_jvm_dtests 28m 15s
✕ j17_jvm_dtests_latest_vnode 27m 59s
org.apache.cassandra.fuzz.harry.integration.model.ConcurrentQuiescentCheckerIntegrationTest
testConcurrentReadWriteWorkload
✕ j17_utests_latest 14m 34s
org.apache.cassandra.tcm.DiscoverySimulationTest discoveryTest
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/a68e4fb0-bd7a-4758-841c-6b4b0fe22865]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/fa57a86d-d120-4304-bbdf-a6cf8fefc4d2]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/91afc77c-54fe-4369-9cb9-ababa3568e16]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/71add260-9c68-4d87-9d5a-99863a01bb3f]
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
>
[jira] [Updated] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-12937:
--
Status: In Progress (was: Patch Available)
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849018#comment-17849018
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
I consolidated the links for PR's as it was getting confusing.
Claude's PR: [https://github.com/apache/cassandra/pull/3168]
mine which is same as his but squashed:
[https://github.com/apache/cassandra/pull/3330]
I rebased mine against current trunk where CASSANDRA-19592 was merged and I see
that the problematic test (SSTableCompressionTest#configChangeIsolation) passes
now which is indeed good news.
I will run a CI to see if something else is broken.
btw [~jlewandowski] mentioned me privately that it would be nice if we had the
configuration like this:
{code}
sstable:
selected_format: big
default_compression: lz4 check this
format:
big:
option1: abc
option2: 123
bti:
option3: xyz
option4: 999
compression: check this
lz4:
enabled: true
chunk_length: 16KiB
max_compressed_length: 16KiB
snappy:
enabled: true
chunk_length: 16KiB
max_compressed_length: 16KiB
deflate:
enabled: false
chunk_length: 16KiB
max_compressed_length: 16KiB
{code}
instead of what we have now:
{code}
sstable_compression:
- class_name: lz4
parameters:
- enabled: "true"
chunk_length: 16KiB
max_compressed_length: 16KiB
{code}
The reasoning behind that is that we are just enriching existing configuration
section, we are not inventing anything new. Plus it would be cool to have
predefined compression options so if we just use lz4 in CQL then all parameters
will be automatically taken into consideration as well. If we provide some
parameters on CQL, these will be merged into what is in cassandra.yaml.
[~claude] I can take a look into this.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-19592) Expand CREATE TABLE CQL on a coordinating node before submitting to CMS
[ https://issues.apache.org/jira/browse/CASSANDRA-19592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848969#comment-17848969 ] Stefan Miklosovic commented on CASSANDRA-19592: --- Does anything else need to be done except merging? This would unblock CASSANDRA-12937 as you are for sure aware of. > Expand CREATE TABLE CQL on a coordinating node before submitting to CMS > --- > > Key: CASSANDRA-19592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19592 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Attachments: ci_summary-1.html, ci_summary.html > > > This is done to unblock CASSANDRA-12937 and allow preserving defaults with > which the table was created between node bounces and between nodes with > different configurations. For now, we are preserving 5.0 behaviour. -- 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-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19632: -- Status: Needs Committer (was: Patch Available) > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- 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-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848940#comment-17848940
]
Stefan Miklosovic edited comment on CASSANDRA-19632 at 5/23/24 12:59 PM:
-
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first PR.
[https://github.com/apache/cassandra/pull/3329]
The perception I got by going through all of that is that people were already
following the rule of "if it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logged like this:
{code:java}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code:java}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
as per [https://www.slf4j.org/faq.html#string_contents]
{quote}The logging system will invoke complexObject.toString() method only
after it has ascertained that the log statement was enabled. Otherwise, the
cost of complexObject.toString() conversion will be advantageously avoided.
{quote}
was (Author: smiklosovic):
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logged like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
as per https://www.slf4j.org/faq.html#string_contents
{quote}
The logging system will invoke complexObject.toString() method only after it
has ascertained that the log statement was enabled. Otherwise, the cost of
complexObject.toString() conversion will be advantageously avoided.
{quote}
> wrap tracing logs in isTraceEnabled across the codebase
> ---
>
> Key: CASSANDRA-19632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19632
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Our usage of logger.isTraceEnabled across the codebase is inconsistent. This
> would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade]
> suggested.
> We should fix this at least in trunk and 5.0 (not critical though) and
> probably come up with a checkstyle rule to prevent not calling isTraceEnabled
> while logging with TRACE level.
--
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
