[jira] [Commented] (CASSANDRA-19697) Test failure: materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
[
https://issues.apache.org/jira/browse/CASSANDRA-19697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854476#comment-17854476
]
Brandon Williams commented on CASSANDRA-19697:
--
This appears to be the problematic thread:
{quote}
"Native-Transport-Requests-1" #61 daemon prio=5 os_prio=0 cpu=100.90ms
elapsed=693.13s tid=0x7f2dc1af34c0 nid=0x565f in Object.wait()
[0x7f2d8d69]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(java.base@11.0.18/Native Method)
- waiting on
at java.lang.Thread.join(java.base@11.0.18/Thread.java:1300)
- waiting to re-lock in wait() <0xe84c3fc8> (a
io.netty.util.concurrent.FastThreadLocalThread)
at java.lang.Thread.join(java.base@11.0.18/Thread.java:1375)
at
java.lang.ApplicationShutdownHooks.runHooks(java.base@11.0.18/ApplicationShutdownHooks.java:107)
at
java.lang.ApplicationShutdownHooks$1.run(java.base@11.0.18/ApplicationShutdownHooks.java:46)
at java.lang.Shutdown.runHooks(java.base@11.0.18/Shutdown.java:130)
at java.lang.Shutdown.exit(java.base@11.0.18/Shutdown.java:174)
- locked <0xfef18198> (a java.lang.Class for java.lang.Shutdown)
at java.lang.Runtime.exit(java.base@11.0.18/Runtime.java:116)
at java.lang.System.exit(java.base@11.0.18/System.java:1752)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.18/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.18/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.18/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@11.0.18/Method.java:566)
at
org.jboss.byteman.rule.expression.MethodExpression.interpret(MethodExpression.java:379)
at org.jboss.byteman.rule.Action.interpret(Action.java:144)
at
org.jboss.byteman.rule.helper.InterpretedHelper.fire(InterpretedHelper.java:170)
at
org.jboss.byteman.rule.helper.InterpretedHelper.execute0(InterpretedHelper.java:138)
at
org.jboss.byteman.rule.helper.InterpretedHelper.execute(InterpretedHelper.java:100)
at org.jboss.byteman.rule.Rule.execute(Rule.java:820)
at org.jboss.byteman.rule.Rule.execute(Rule.java:789)
at org.apache.cassandra.schema.Schema.merge(Schema.java:649)
{quote}
> Test failure:
> materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
> -
>
> Key: CASSANDRA-19697
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19697
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Attachments: shutdown_stuck.txt
>
>
> Breaking this out from CASSANDRA-19683. The byteman script fails to execute
> in 5.0/trunk after 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-19700) Disabling internode compression causes high CPU usage and load
[
https://issues.apache.org/jira/browse/CASSANDRA-19700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854472#comment-17854472
]
Brandon Williams commented on CASSANDRA-19700:
--
What I would do next to investigate further is produce a flamegraph for each to
see where the CPU is going.
> Disabling internode compression causes high CPU usage and load
> --
>
> Key: CASSANDRA-19700
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19700
> Project: Cassandra
> Issue Type: Task
>Reporter: Zbyszek Z
>Priority: Normal
> Attachments: image001.jpg
>
>
> I am not sure this is BUG or feature but cassandra is acting contrary to the
> belief that compression causes higher CPU usage. I have attached comparision
> graph - first part (left) is a identical cluster that have
> internode_compression={*}dc{*} and second part (right hand) is
> internode_compression={*}all.{*}
> Contrary to what one would thought, enabling compression causes signifficant
> drop in load and cpu usage.
> !image001.jpg|width=532,height=327!
> I am reporting it only becouse maybe there is different pipeline in cassandra
> that handles networking that is sub-optimal and does not handle high traffic
> well (just blind-shoot).
> Any thoughts?
--
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-19697) Test failure: materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
[
https://issues.apache.org/jira/browse/CASSANDRA-19697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854464#comment-17854464
]
Brandon Williams edited comment on CASSANDRA-19697 at 6/12/24 3:17 PM:
---
The mysterious commonality that connects this back to CASSANDRA-19534 despite
entirely different classes being targetted by byteman in 5.0 and trunk is that
the JVM does not exit in either branch, where in 4.1 it shuts down gracefully.
Here is where 5.0 and trunk stop:
{quote}INFO [Native-Transport-Requests-1] 2024-06-12 10:02:16,679
Keyspace.java:379 - Creating replication strategy bar params
KeyspaceParams\{durable_writes=true,
replication=ReplicationParams{class=org.apache.cassandra.locator.SimpleStrategy,
replication_factor=1}}
INFO [StorageServiceShutdownHook] 2024-06-12 10:02:16,686 HintsService.java:234
- Paused hints dispatch
{quote}
but 4.1 continues:
{quote}INFO [Native-Transport-Requests-1] 2024-06-12 09:59:04,474
Keyspace.java:394 - Creating replication strategy foo params
KeyspaceParams\{durable_writes=true,
replication=ReplicationParams{class=org.apache.cassandra.locator.SimpleStrategy,
replication_factor=1}}
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:04,481 HintsService.java:235
- Paused hints dispatch
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:04,483 Server.java:176 -
Stop listening for CQL clients
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:04,484 Gossiper.java:2139 -
Announcing shutdown
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:04,484
StorageService.java:3075 - Node localhost/127.0.0.1:7000 state jump to shutdown
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:04,485
StorageService.java:3075 - Node localhost/127.0.0.1:7000 state jump to shutdown
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:06,487
MessagingService.java:526 - Waiting for messaging service to quiesce
...
{quote}
In the thread dump I see some epoll threads still running, but I'm not sure if
that's typical. I don't immediately see anything from CASSANDRA-19534 that
would cause this, [~ifesdjeen] could you take a look? The [byteman
script|https://github.com/apache/cassandra-dtest/blob/trunk/byteman/merge_schema_failure_4x.btm]
is calling System.exit(0) inside Schema.merge.
[^shutdown_stuck.txt]
was (Author: brandon.williams):
The mysterious commonality that connects this back to CASSANDRA-19534 despite
entirely different classes being targetted by byteman in 5.0 and trunk is that
the JVM does not exit in either branch, where in 4.1 it shuts down gracefully.
Here is where 5.0 and trunk stop:
{quote}
INFO [Native-Transport-Requests-1] 2024-06-12 10:02:16,679 Keyspace.java:379 -
Creating replication strategy bar params KeyspaceParams{durable_writes=true,
replication=ReplicationParams{class=org.apache.cassandra.locator.SimpleStrategy,
replication_factor=1}}
INFO [StorageServiceShutdownHook] 2024-06-12 10:02:16,686
HintsService.java:234 - Paused hints dispatch
{quote}
but 4.1 continues:
{quote}
INFO [Native-Transport-Requests-1] 2024-06-12 09:59:04,474 Keyspace.java:394 -
Creating replication strategy foo params KeyspaceParams{durable_writes=true,
replication=ReplicationParams{class=org.apache.cassandra.locator.SimpleStrategy,
replication_factor=1}}
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:04,481
HintsService.java:235 - Paused hints dispatch
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:04,483 Server.java:176 -
Stop listening for CQL clients
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:04,484 Gossiper.java:2139 -
Announcing shutdown
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:04,484
StorageService.java:3075 - Node localhost/127.0.0.1:7000 state jump to shutdown
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:04,485
StorageService.java:3075 - Node localhost/127.0.0.1:7000 state jump to shutdown
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:06,487
MessagingService.java:526 - Waiting for messaging service to quiesce
...
{quote}
In the thread dump I see some epoll threads still running, but I'm not sure if
that's typical. I don't immediately see anything from CASSANDRA-19534 that
would cause this, [~ifesdjeen] could you take a look? The [byteman
script|https://github.com/apache/cassandra-dtest/blob/trunk/byteman/merge_schema_failure_4x.btm]
is calling System.exit(0) inside Schema.merge.
> Test failure:
> materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
> -
>
> Key: CASSANDRA-19697
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19697
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>
[jira] [Updated] (CASSANDRA-19697) Test failure: materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
[ https://issues.apache.org/jira/browse/CASSANDRA-19697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19697: - Attachment: shutdown_stuck.txt > Test failure: > materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity > - > > Key: CASSANDRA-19697 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19697 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: shutdown_stuck.txt > > > Breaking this out from CASSANDRA-19683. The byteman script fails to execute > in 5.0/trunk after 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-19697) Test failure: materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
[
https://issues.apache.org/jira/browse/CASSANDRA-19697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854464#comment-17854464
]
Brandon Williams commented on CASSANDRA-19697:
--
The mysterious commonality that connects this back to CASSANDRA-19534 despite
entirely different classes being targetted by byteman in 5.0 and trunk is that
the JVM does not exit in either branch, where in 4.1 it shuts down gracefully.
Here is where 5.0 and trunk stop:
{quote}
INFO [Native-Transport-Requests-1] 2024-06-12 10:02:16,679 Keyspace.java:379 -
Creating replication strategy bar params KeyspaceParams{durable_writes=true,
replication=ReplicationParams{class=org.apache.cassandra.locator.SimpleStrategy,
replication_factor=1}}
INFO [StorageServiceShutdownHook] 2024-06-12 10:02:16,686
HintsService.java:234 - Paused hints dispatch
{quote}
but 4.1 continues:
{quote}
INFO [Native-Transport-Requests-1] 2024-06-12 09:59:04,474 Keyspace.java:394 -
Creating replication strategy foo params KeyspaceParams{durable_writes=true,
replication=ReplicationParams{class=org.apache.cassandra.locator.SimpleStrategy,
replication_factor=1}}
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:04,481
HintsService.java:235 - Paused hints dispatch
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:04,483 Server.java:176 -
Stop listening for CQL clients
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:04,484 Gossiper.java:2139 -
Announcing shutdown
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:04,484
StorageService.java:3075 - Node localhost/127.0.0.1:7000 state jump to shutdown
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:04,485
StorageService.java:3075 - Node localhost/127.0.0.1:7000 state jump to shutdown
INFO [StorageServiceShutdownHook] 2024-06-12 09:59:06,487
MessagingService.java:526 - Waiting for messaging service to quiesce
...
{quote}
In the thread dump I see some epoll threads still running, but I'm not sure if
that's typical. I don't immediately see anything from CASSANDRA-19534 that
would cause this, [~ifesdjeen] could you take a look? The [byteman
script|https://github.com/apache/cassandra-dtest/blob/trunk/byteman/merge_schema_failure_4x.btm]
is calling System.exit(0) inside Schema.merge.
> Test failure:
> materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
> -
>
> Key: CASSANDRA-19697
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19697
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Breaking this out from CASSANDRA-19683. The byteman script fails to execute
> in 5.0/trunk after 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] [Comment Edited] (CASSANDRA-19697) Test failure: materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
[
https://issues.apache.org/jira/browse/CASSANDRA-19697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854436#comment-17854436
]
Brandon Williams edited comment on CASSANDRA-19697 at 6/12/24 1:45 PM:
---
{quote}
Checking rule inject node failure on merge schema exit against class
org.apache.cassandra.schema.Schema
Parsed rule "inject node failure on merge schema exit" for class
org.apache.cassandra.schema.Schema
Type checked rule "inject node failure on merge schema exit"
TestScript: no errors
{quote}
was (Author: brandon.williams):
Checking rule inject node failure on merge schema exit against class
org.apache.cassandra.schema.Schema
Parsed rule "inject node failure on merge schema exit" for class
org.apache.cassandra.schema.Schema
Type checked rule "inject node failure on merge schema exit"
TestScript: no errors
> Test failure:
> materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
> -
>
> Key: CASSANDRA-19697
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19697
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Breaking this out from CASSANDRA-19683. The byteman script fails to execute
> in 5.0/trunk after 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-19697) Test failure: materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
[ https://issues.apache.org/jira/browse/CASSANDRA-19697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854436#comment-17854436 ] Brandon Williams commented on CASSANDRA-19697: -- Checking rule inject node failure on merge schema exit against class org.apache.cassandra.schema.Schema Parsed rule "inject node failure on merge schema exit" for class org.apache.cassandra.schema.Schema Type checked rule "inject node failure on merge schema exit" TestScript: no errors > Test failure: > materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity > - > > Key: CASSANDRA-19697 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19697 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-rc, 5.x > > > Breaking this out from CASSANDRA-19683. The byteman script fails to execute > in 5.0/trunk after 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-19583) Make 0 work as 0+unit for all three config classes (DataStorageSpec, DurationSpec, DataRateSpec)
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854402#comment-17854402
]
Brandon Williams commented on CASSANDRA-19583:
--
Thanks for the patch, Arun!
bq. Also, should I add more tests
Always a welcome idea :)
bq. and change the exception's message to indicate "0" is now allowed?
I think that makes sense too.
> Make 0 work as 0+unit for all three config classes (DataStorageSpec,
> DurationSpec, DataRateSpec)
>
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Jon Haddad
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 without a unit attached for data, duration, and data spec
> config parameters, as 0 is always 0 no matter the unit.
--
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 ] Brandon Williams updated CASSANDRA-19656: - Fix Version/s: 5.0-beta2 5.0 5.1 (was: 5.x) (was: 5.0.x) Source Control Link: https://github.com/apache/cassandra/commit/531de93369ac35c18ec9479997c079388dd8d7f2 Resolution: Fixed Status: Resolved (was: Ready to Commit) Thanks for the review! Committed. > 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-beta2, 5.0, 5.1 > > > 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] [Comment Edited] (CASSANDRA-19656) Revisit disabling chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-19656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854105#comment-17854105 ] Brandon Williams edited comment on CASSANDRA-19656 at 6/11/24 3:51 PM: --- j11 CI should suffice here. ||Branch||CI|| |[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19656-5.0]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1661/workflows/351c1a67-d489-4f22-a61c-405672ad7845]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19656-trunk]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1660/workflows/45dd-9468-4d36-a6bd-87ef83681bc9]| was (Author: brandon.williams): j11 CI should suffice here. ||Branch||CI|| |[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19656-5.0]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1663/workflows/c835c912-74ed-49f4-945a-df9a36dfec94]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19656-trunk]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1662/workflows/a3e2a3c9-efb4-425a-aad4-68d774f517c5]| > 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-19683) Investigate dtest timeouts after CASSANDRA-19534
[ https://issues.apache.org/jira/browse/CASSANDRA-19683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19683: - Fix Version/s: 5.0-beta2 5.0 5.1 (was: 5.x) (was: 5.0-rc) Since Version: NA Source Control Link: https://github.com/apache/cassandra-dtest/commit/eb92fca7c38ae00879d4a3cd91896bf619bc2d94 Resolution: Fixed Status: Resolved (was: Ready to Commit) Thanks, committed. > 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-beta2, 5.0, 5.1 > > 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] [Updated] (CASSANDRA-19683) Investigate dtest timeouts after CASSANDRA-19534
[ https://issues.apache.org/jira/browse/CASSANDRA-19683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19683: - Status: Ready to Commit (was: Review In Progress) > 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] [Updated] (CASSANDRA-19683) Investigate dtest timeouts after CASSANDRA-19534
[ https://issues.apache.org/jira/browse/CASSANDRA-19683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19683: - Test and Documentation Plan: run CI Status: Patch Available (was: In Progress) > 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] [Updated] (CASSANDRA-19697) Test failure: materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
[ https://issues.apache.org/jira/browse/CASSANDRA-19697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19697: - Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Challenging Discovered By: DTest Fix Version/s: 5.0-rc 5.x Severity: Normal Assignee: Brandon Williams Status: Open (was: Triage Needed) > Test failure: > materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity > - > > Key: CASSANDRA-19697 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19697 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-rc, 5.x > > > Breaking this out from CASSANDRA-19683. The byteman script fails to execute > in 5.0/trunk after 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] [Created] (CASSANDRA-19697) Test failure: materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
Brandon Williams created CASSANDRA-19697: Summary: Test failure: materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity Key: CASSANDRA-19697 URL: https://issues.apache.org/jira/browse/CASSANDRA-19697 Project: Cassandra Issue Type: Bug Components: Feature/Materialized Views Reporter: Brandon Williams Breaking this out from CASSANDRA-19683. The byteman script fails to execute in 5.0/trunk after 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-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=17853826#comment-17853826
]
Brandon Williams commented on CASSANDRA-19661:
--
I see. Well if you are certain this only affected beta1 and no longer
reproduces then I think we can close this ticket.
> 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
>
> Attachments: upload_content.py
>
>
> 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', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.UnifiedCompactionStrategy',
> 'scaling_parameters': 'T4', 'target_sstable_size': '1GiB'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND
[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=17853725#comment-17853725
]
Brandon Williams commented on CASSANDRA-19661:
--
[~sergrua] is it possible to upload them? I think there must be something
endemic to the data that caused this, since your script alone is not enough to
reproduce against beta1.
> 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
>
> Attachments: upload_content.py
>
>
> 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', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.UnifiedCompactionStrategy',
> 'scaling_parameters': 'T4', 'target_sstable_size': '1GiB'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND
[jira] [Commented] (CASSANDRA-19696) Observed large number of Inbound / Outbound connection disconnect / reconnects in log
[ https://issues.apache.org/jira/browse/CASSANDRA-19696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853712#comment-17853712 ] Brandon Williams commented on CASSANDRA-19696: -- Problems with your network would explain these issues. 4.0 has been released for some time without any similar reports. > Observed large number of Inbound / Outbound connection disconnect / > reconnects in log > - > > Key: CASSANDRA-19696 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19696 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Kan Maung >Priority: Normal > > We are seeing hundreds of InboundConnection established / closed messages on > several of our clusters running Apache Cassandra 4.0.10. Looking at > 'nodetool tpstats' it seems gossip is close to the time out value. It > affects both the LargeMessage and UrgentMessage connections. > Gossiper uses MessagingService to send messages from the source to > destination using OutboundConnection. Depending on the message type > especially for LARGE_MESSAGES it is enqueued in a separate thread pool while > URGENT_MESSAGES are delivered with Verb.Priority.P0. > In the example below this happens just 20 seconds after it connected. These > two nodes are in the same datacenter, so there should be no geographical > latency between them. This cluster 111 has a very standard cassandra.yaml for > our environment. > > 127.10.20.88 cassandra.log: > 2024-05-13 02:06:13,805 [INFO ] [Messaging-EventLoop-3-2] cluster_id=111 > ip_address=127.10.20.88 InboundConnectionInitiator.java:529 - > /127.10.30.171:7000(/127.10.30.171:37404)->/127.10.20.88:7000-URGENT_MESSAGES-e039a471 > messaging connection established, version = 12, framing = CRC, encryption = > encrypted(...) > 2024-05-13 02:06:32,201 [INFO ] [Messaging-EventLoop-3-4] cluster_id=111 > ip_address=127.10.20.88 OutboundConnection.java:1059 - > /127.10.20.88:7000->/169.73.115.189:7000-LARGE_MESSAGES-70634968 channel > closed by provider > > 127.10.30.171 log: > 2024-05-13 02:05:00,300 [INFO ] [Messaging-EventLoop-3-2] cluster_id=111 > ip_address=127.10.30.171 OutboundConnection.java:1059 - > /127.10.30.171:7000->/169.102.147.87:7000-LARGE_MESSAGES-4b3ea69f channel > closed by provider > io.netty.channel.unix.Errors$NativeIoException: readAddress(..) failed: > Connection timed out > 2024-05-13 02:05:46,892 [INFO ] [Messaging-EventLoop-3-4] cluster_id=111 > ip_address=127.10.30.171 OutboundConnection.java:1059 - > /127.10.30.171:7000->/127.10.20.88:7000-URGENT_MESSAGES-8fd0dbf2 channel > closed by provider > io.netty.channel.unix.Errors$NativeIoException: readAddress(..) failed: > Connection timed out > 2024-05-13 02:06:13,804 [INFO ] [Messaging-EventLoop-3-4] cluster_id=111 > ip_address=127.10.30.171 OutboundConnection.java:1153 - > /127.10.30.171:7000(/127.10.30.171:37404)->/127.10.20.88:7000-URGENT_MESSAGES-155d9869 > successfully connected, version = 12, framing = CRC, encryption = > encrypted(...) > 2024-05-13 02:06:24,281 [INFO ] [Messaging-EventLoop-3-4] cluster_id=111 > ip_address=127.10.30.171 OutboundConnection.java:1153 - > /127.10.30.171:7000(/127.10.30.171:50046)->/169.73.137.223:7000-LARGE_MESSAGES-04b51284 > successfully connected, version = 12, framing = LZ4, encryption = > encrypted(...) -- 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-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=17853618#comment-17853618
]
Brandon Williams commented on CASSANDRA-19661:
--
[~sergrua] what documents are you loading from the ./data directory?
> 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
>
> Attachments: upload_content.py
>
>
> 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', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.UnifiedCompactionStrategy',
> 'scaling_parameters': 'T4', 'target_sstable_size': '1GiB'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
>
[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 ] Brandon Williams updated CASSANDRA-19656: - Status: Patch Available (was: Open) > 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=17853212#comment-17853212
]
Brandon Williams commented on CASSANDRA-19683:
--
[Here|https://app.circleci.com/pipelines/github/driftx/cassandra/1654/workflows/4f2370fa-3019-4e9a-8672-43dadd9e7ce3]
is a current CI run against my progress. Nothing left but the byteman mystery
with test_rename_column_atomicity. Adding {{-Dorg.jboss.byteman.verbose=true}}
didn't reveal anything.
> 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-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=17853210#comment-17853210
]
Brandon Williams commented on CASSANDRA-19445:
--
[~bdeggleston] can you review?
> 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-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:all-tabpanel
]
Brandon Williams updated CASSANDRA-19658:
-
Fix Version/s: 5.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.14, 4.1.6, 5.0-beta2, 5.0, 5.1
>
>
> 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] [Updated] (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:all-tabpanel
]
Brandon Williams updated CASSANDRA-19658:
-
Fix Version/s: 4.0.14
4.1.6
5.0-beta2
5.0
(was: 4.0.x)
(was: 4.1.x)
(was: 5.0.x)
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra-dtest/commit/259c997c6684dac70cd26f69fd0cc393945570e9
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks!
> 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.14, 4.1.6, 5.0-beta2, 5.0
>
>
> 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] [Updated] (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:all-tabpanel
]
Brandon Williams updated CASSANDRA-19658:
-
Reviewers: Stefan Miklosovic (was: Brandon Williams, Stefan Miklosovic)
> 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] [Updated] (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:all-tabpanel
]
Brandon Williams updated CASSANDRA-19658:
-
Status: Ready to Commit (was: Review In Progress)
> 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] [Updated] (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:all-tabpanel
]
Brandon Williams updated CASSANDRA-19658:
-
Reviewers: Stefan Miklosovic, Brandon Williams
Stefan Miklosovic, Brandon Williams (was: Brandon Williams,
Stefan Miklosovic)
Status: Review In Progress (was: Patch Available)
> 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-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853003#comment-17853003
]
Brandon Williams commented on CASSANDRA-19628:
--
I'm a
[ninja|https://github.com/apache/cassandra-website/commit/480930b67f6f4df34e48e7898075fbc429819a17]
but I didn't deploy the site.
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.31, 4.0.14, 4.1.6, 5.0-beta2, 5.0, 5.1
>
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
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=17852955#comment-17852955 ] Brandon Williams commented on CASSANDRA-19683: -- bq. they were probably near the cusp of timing out before and are crossing it now. We can increase the timeouts for those tests to resolve that. They were already modifying [other timeouts|https://github.com/apache/cassandra-dtest/blob/trunk/cql_tracing_test.py#L29] so adding native_transport_timeout makes sense which I did [here|https://github.com/driftx/cassandra-dtest/commit/c2e56e4e116b489f925fda1f68893a91b8f91c17] and ran [CI w/repeats here|https://app.circleci.com/pipelines/github/driftx/cassandra/1653/workflows/654c04aa-7030-4d0f-b1bb-354378ab82dd/jobs/91646]. > 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-19683) Investigate dtest timeouts after CASSANDRA-19534
[ https://issues.apache.org/jira/browse/CASSANDRA-19683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852936#comment-17852936 ] Brandon Williams commented on CASSANDRA-19683: -- The tracing tests that failed intermittently timeout for me on 4.1 and up; given it's tracing, they were probably near the cusp of timing out before and are crossing it now. We can increase the timeouts for those tests to resolve that. materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity fails with a timeout consistently on 5.0 and trunk, but not on 4.1. The problem is that the byteman script (which it shares with 4.1[here|https://github.com/apache/cassandra-dtest/blob/trunk/byteman/merge_schema_failure_4x.btm]) no longer seems to take effect and exit when Schema.merge is hit in 5.0, even though as far as I can tell CASSANDRA-19534 didn't change anything there. > 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-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=17852731#comment-17852731
]
Brandon Williams commented on CASSANDRA-19445:
--
I don't think we need to shave the bug/improvement yak for pushing down a log
statement, it should be fine in 4.1 and 5.0.
> 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-19683) Investigate dtest timeouts after CASSANDRA-19534
[ https://issues.apache.org/jira/browse/CASSANDRA-19683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19683: - Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Component/s: Test/dtest/python Discovered By: DTest Fix Version/s: 5.0-rc Severity: Normal Assignee: Brandon Williams Status: Open (was: Triage Needed) > 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/ -- 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-19681) Debian repository is missing 3.11.17 package
[
https://issues.apache.org/jira/browse/CASSANDRA-19681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19681:
-
Fix Version/s: 3.11.17
(was: NA)
> Debian repository is missing 3.11.17 package
>
>
> Key: CASSANDRA-19681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19681
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.17
>
>
> The Debian package for Cassandra 3.11.17 is missing from the JFrog
> artifactory. The [package
> index|https://apache.jfrog.io/artifactory/cassandra-deb/dists/311x/main/binary-amd64/Packages]
> is still referencing version 3.11.16:
> {code}
> Package: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra_3.11.16_all.deb
> ...
> Package: cassandra-tools
> Source: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra-tools_3.11.16_all.deb
> ...
> {code}
> When I tried to install the latest C* 3.11 version on Ubuntu, 3.11.16 got
> installed instead of 3.11.17.
> Note that this was originally reported by [Roman on Stack
> Exchange|https://dba.stackexchange.com/questions/340007/].
--
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-19681) Debian repository is missing 3.11.17 package
[
https://issues.apache.org/jira/browse/CASSANDRA-19681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19681:
-
Fix Version/s: NA
(was: 3.11.x)
> Debian repository is missing 3.11.17 package
>
>
> Key: CASSANDRA-19681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19681
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: NA
>
>
> The Debian package for Cassandra 3.11.17 is missing from the JFrog
> artifactory. The [package
> index|https://apache.jfrog.io/artifactory/cassandra-deb/dists/311x/main/binary-amd64/Packages]
> is still referencing version 3.11.16:
> {code}
> Package: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra_3.11.16_all.deb
> ...
> Package: cassandra-tools
> Source: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra-tools_3.11.16_all.deb
> ...
> {code}
> When I tried to install the latest C* 3.11 version on Ubuntu, 3.11.16 got
> installed instead of 3.11.17.
> Note that this was originally reported by [Roman on Stack
> Exchange|https://dba.stackexchange.com/questions/340007/].
--
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-19681) Debian repository is missing 3.11.17 package
[
https://issues.apache.org/jira/browse/CASSANDRA-19681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19681:
-
Resolution: Fixed
Status: Resolved (was: Open)
I resolved this and tested that 3.11.17 gets installed from the 311x repo.
I suspect the failure from CASSANDRA-19561 resulted in this being uploaded into
the wrong subdirectory, which I have corrected.
> Debian repository is missing 3.11.17 package
>
>
> Key: CASSANDRA-19681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19681
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x
>
>
> The Debian package for Cassandra 3.11.17 is missing from the JFrog
> artifactory. The [package
> index|https://apache.jfrog.io/artifactory/cassandra-deb/dists/311x/main/binary-amd64/Packages]
> is still referencing version 3.11.16:
> {code}
> Package: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra_3.11.16_all.deb
> ...
> Package: cassandra-tools
> Source: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra-tools_3.11.16_all.deb
> ...
> {code}
> When I tried to install the latest C* 3.11 version on Ubuntu, 3.11.16 got
> installed instead of 3.11.17.
> Note that this was originally reported by [Roman on Stack
> Exchange|https://dba.stackexchange.com/questions/340007/].
--
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-18762) Repair triggers OOM with direct buffer memory
[
https://issues.apache.org/jira/browse/CASSANDRA-18762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852388#comment-17852388
]
Brandon Williams commented on CASSANDRA-18762:
--
Does CASSANDRA-19336 not solve this?
> Repair triggers OOM with direct buffer memory
> -
>
> Key: CASSANDRA-18762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18762
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brad Schoening
>Priority: Normal
> Labels: OutOfMemoryError
> Attachments: Cluster-dm-metrics-1.PNG,
> image-2023-12-06-15-28-05-459.png, image-2023-12-06-15-29-31-491.png,
> image-2023-12-06-15-58-55-007.png
>
>
> We are seeing repeated failures of nodes with 16GB of heap on a VM with 32GB
> of physical RAM due to direct memory. This seems to be related to
> CASSANDRA-15202 which moved Merkel trees off-heap in 4.0. Using Cassandra
> 4.0.6 with Java 11.
> {noformat}
> 2023-08-09 04:30:57,470 [INFO ] [AntiEntropyStage:1] cluster_id=101
> ip_address=169.0.0.1 RepairSession.java:202 - [repair
> #5e55a3b0-366d-11ee-a644-d91df26add5e] Received merkle tree for table_a from
> /169.102.200.241:7000
> 2023-08-09 04:30:57,567 [INFO ] [AntiEntropyStage:1] cluster_id=101
> ip_address=169.0.0.1 RepairSession.java:202 - [repair
> #5e0d2900-366d-11ee-a644-d91df26add5e] Received merkle tree for table_b from
> /169.93.192.29:7000
> 2023-08-09 04:30:57,568 [INFO ] [AntiEntropyStage:1] cluster_id=101
> ip_address=169.0.0.1 RepairSession.java:202 - [repair
> #5e1dcad0-366d-11ee-a644-d91df26add5e] Received merkle tree for table_c from
> /169.104.171.134:7000
> 2023-08-09 04:30:57,591 [INFO ] [AntiEntropyStage:1] cluster_id=101
> ip_address=169.0.0.1 RepairSession.java:202 - [repair
> #5e69a0e0-366d-11ee-a644-d91df26add5e] Received merkle tree for table_b from
> /169.79.232.67:7000
> 2023-08-09 04:30:57,876 [INFO ] [Service Thread] cluster_id=101
> ip_address=169.0.0.1 GCInspector.java:294 - G1 Old Generation GC in 282ms.
> Compressed Class Space: 8444560 -> 8372152; G1 Eden Space: 7809794048 -> 0;
> G1 Old Gen: 1453478400 -> 820942800; G1 Survivor Space: 419430400 -> 0;
> Metaspace: 80411136 -> 80176528
> 2023-08-09 04:30:58,387 [ERROR] [AntiEntropyStage:1] cluster_id=101
> ip_address=169.0.0.1 JVMStabilityInspector.java:102 - OutOfMemory error
> letting the JVM handle the error:
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
> at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:118)
> at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:318)
> at org.apache.cassandra.utils.MerkleTree.allocate(MerkleTree.java:742)
> at
> org.apache.cassandra.utils.MerkleTree.deserializeOffHeap(MerkleTree.java:780)
> at org.apache.cassandra.utils.MerkleTree.deserializeTree(MerkleTree.java:751)
> at org.apache.cassandra.utils.MerkleTree.deserialize(MerkleTree.java:720)
> at org.apache.cassandra.utils.MerkleTree.deserialize(MerkleTree.java:698)
> at
> org.apache.cassandra.utils.MerkleTrees$MerkleTreesSerializer.deserialize(MerkleTrees.java:416)
> at
> org.apache.cassandra.repair.messages.ValidationResponse$1.deserialize(ValidationResponse.java:100)
> at
> org.apache.cassandra.repair.messages.ValidationResponse$1.deserialize(ValidationResponse.java:84)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePost40(Message.java:782)
> at org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:642)
> at
> org.apache.cassandra.net.InboundMessageHandler$LargeMessage.deserialize(InboundMessageHandler.java:364)
> at
> org.apache.cassandra.net.InboundMessageHandler$LargeMessage.access$1100(InboundMessageHandler.java:317)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessLargeMessage.provideMessage(InboundMessageHandler.java:504)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:429)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)no* further _formatting_ is
> done here{noformat}
>
> -XX:+AlwaysPreTouch
> -XX:+CrashOnOutOfMemoryError
> -XX:+ExitOnOutOfMemoryError
> -XX:+HeapDumpOnOutOfMemoryError
> -XX:+ParallelRefProcEnabled
> -XX:+PerfDisableSharedMem
> -XX:+ResizeTLAB
> -XX:+UseG1GC
> -XX:+UseNUMA
> -XX:+UseTLAB
> -XX:+UseThreadPriorities
>
[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=17852379#comment-17852379 ] Brandon Williams edited comment on CASSANDRA-19679 at 6/5/24 10:48 AM: --- It looks good to me, happy to take a look when we have CI. was (Author: brandon.williams): Looks like this should just apply to 5.0. It looks good to me, happy to take a look when we have CI. > 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=17852379#comment-17852379 ] Brandon Williams commented on CASSANDRA-19679: -- Looks like this should just apply to 5.0. It looks good to me, happy to take a look when we have CI. > 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] [Assigned] (CASSANDRA-19681) Debian repository is missing 3.11.17 package
[
https://issues.apache.org/jira/browse/CASSANDRA-19681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-19681:
Assignee: Brandon Williams
> Debian repository is missing 3.11.17 package
>
>
> Key: CASSANDRA-19681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19681
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x
>
>
> The Debian package for Cassandra 3.11.17 is missing from the JFrog
> artifactory. The [package
> index|https://apache.jfrog.io/artifactory/cassandra-deb/dists/311x/main/binary-amd64/Packages]
> is still referencing version 3.11.16:
> {code}
> Package: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra_3.11.16_all.deb
> ...
> Package: cassandra-tools
> Source: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra-tools_3.11.16_all.deb
> ...
> {code}
> When I tried to install the latest C* 3.11 version on Ubuntu, 3.11.16 got
> installed instead of 3.11.17.
> Note that this was originally reported by [Roman on Stack
> Exchange|https://dba.stackexchange.com/questions/340007/].
--
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-19022) Nodetool gcstats correctly displays Direct Memory usage and supports printing in table format
[
https://issues.apache.org/jira/browse/CASSANDRA-19022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19022:
-
Fix Version/s: 5.x
(was: 5.1)
> Nodetool gcstats correctly displays Direct Memory usage and supports printing
> in table format
> -
>
> Key: CASSANDRA-19022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19022
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>
> If {{io.netty.maxDirectMemory}} is not specified, Netty defaults the limit to
> the max heap size. Thus, direct memory in use can be significant.
> However, trying this on two different platform and the result returned in
> gcstats is always -1:
> {noformat}
> Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed (ms)
> GC Reclaimed (MB) Collections Direct Memory Bytes
> 2792770717 274 665186 54
> 412762880890246120 -1{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-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852210#comment-17852210 ] Brandon Williams commented on CASSANDRA-19676: -- I'm +1 on 5.0 > 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=17852104#comment-17852104 ] Brandon Williams commented on CASSANDRA-19676: -- I ran a 5.0 build [here|https://app.circleci.com/pipelines/github/driftx/cassandra/1650/workflows/35a6dff8-a82b-4313-9040-0bee58106498] and got similar results, so I ran a 5.0 baseline [here|https://app.circleci.com/pipelines/github/driftx/cassandra/1651/workflows/738d1c92-0ffe-45e7-8ad4-f2646170ba76] and it looks like these tests were recently broken before this patch. > 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-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=17852101#comment-17852101
]
Brandon Williams commented on CASSANDRA-19661:
--
I was hoping I could drive this forward by running through
https://docs.llamaindex.ai/en/stable/examples/vector_stores/CassandraIndexDemo/
and getting a reproduction against beta1 or HEAD, but it does not reproduce.
Adding all the text files from test/resources/tokenization/ does not help
either.
> 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', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.UnifiedCompactionStrategy',
> 'scaling_parameters': 'T4', 'target_sstable_size': '1GiB'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
>
[jira] [Updated] (CASSANDRA-19375) Link in docs to Achilles Java Driver links to malicious site
[ https://issues.apache.org/jira/browse/CASSANDRA-19375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19375: - Status: Ready to Commit (was: Review In Progress) > Link in docs to Achilles Java Driver links to malicious site > > > Key: CASSANDRA-19375 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19375 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: PJ Fanning >Assignee: Brad Schoening >Priority: Normal > > https://cassandra.apache.org/doc/4.1/cassandra/getting_started/drivers.html#java > The Achilles link looks dangerous. I tried it and it looked like the link has > been taken over by a malicious user. -- 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-19375) Link in docs to Achilles Java Driver links to malicious site
[ https://issues.apache.org/jira/browse/CASSANDRA-19375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19375: - Reviewers: Brandon Williams Status: Review In Progress (was: Patch Available) > Link in docs to Achilles Java Driver links to malicious site > > > Key: CASSANDRA-19375 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19375 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: PJ Fanning >Assignee: Brad Schoening >Priority: Normal > > https://cassandra.apache.org/doc/4.1/cassandra/getting_started/drivers.html#java > The Achilles link looks dangerous. I tried it and it looked like the link has > been taken over by a malicious user. -- 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-19375) Link in docs to Achilles Java Driver links to malicious site
[ https://issues.apache.org/jira/browse/CASSANDRA-19375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851843#comment-17851843 ] Brandon Williams commented on CASSANDRA-19375: -- Looks good to me, +1. If you need help deploying the site (see https://github.com/apache/cassandra-website) let me know. > Link in docs to Achilles Java Driver links to malicious site > > > Key: CASSANDRA-19375 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19375 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: PJ Fanning >Assignee: Brad Schoening >Priority: Normal > > https://cassandra.apache.org/doc/4.1/cassandra/getting_started/drivers.html#java > The Achilles link looks dangerous. I tried it and it looked like the link has > been taken over by a malicious user. -- 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-19217) Test failure: auth_test.TestAuthUnavailable
[ https://issues.apache.org/jira/browse/CASSANDRA-19217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19217: - Status: Ready to Commit (was: Review In Progress) > Test failure: auth_test.TestAuthUnavailable > --- > > Key: CASSANDRA-19217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19217 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 5.x > > > https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1233/workflows/bb617340-f1da-4550-9c87-5541469972c4/jobs/62551/tests -- 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-19217) Test failure: auth_test.TestAuthUnavailable
[ https://issues.apache.org/jira/browse/CASSANDRA-19217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19217: - Reviewers: Brandon Williams, Brandon Williams Brandon Williams, Brandon Williams (was: Brandon Williams) Status: Review In Progress (was: Patch Available) > Test failure: auth_test.TestAuthUnavailable > --- > > Key: CASSANDRA-19217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19217 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 5.x > > > https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1233/workflows/bb617340-f1da-4550-9c87-5541469972c4/jobs/62551/tests -- 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-19217) Test failure: auth_test.TestAuthUnavailable
[ https://issues.apache.org/jira/browse/CASSANDRA-19217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851723#comment-17851723 ] Brandon Williams commented on CASSANDRA-19217: -- Looks good to me; +1 > Test failure: auth_test.TestAuthUnavailable > --- > > Key: CASSANDRA-19217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19217 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 5.x > > > https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1233/workflows/bb617340-f1da-4550-9c87-5541469972c4/jobs/62551/tests -- 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=17851703#comment-17851703 ] Brandon Williams commented on CASSANDRA-19676: -- I think 5.0.0 is probably a good place for this; it shouldn't cause a regression and is a performance boost, but if it does happen to regress then catching it in a new release is the best scenario. > 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-19672) some unit tests should generate files in the tmp directory
[
https://issues.apache.org/jira/browse/CASSANDRA-19672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19672:
-
Fix Version/s: 5.x
(was: 5.1)
> some unit tests should generate files in the tmp directory
> --
>
> Key: CASSANDRA-19672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19672
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>
> I run "{*}_ant test_{*}" to fire the whole test suit cases in my local
> machine, and found some UTs had generated files in current directory,
> otherwise the tmp directory.
>
> {code:java}
> [root@vm-24-5-centos cassandra]# git status
> # audit/
> # compaction.log
> #
> import_cql_test_keyspace_table_testcopyonlythoserowsthatmatchvectortyp_04.err
> {code}
>
> These problematic UTs are
>
> {code:java}
> ant testsome
> -Dtest.name=org.apache.cassandra.service.StorageServiceServerTest
> -Dtest.methods=testAuditLogEnableLoggerNotFound
> ant testsome
> -Dtest.name=org.apache.cassandra.service.StorageServiceServerTest
> -Dtest.methods=testAuditLogEnableLoggerTransitions
> ant testsome -Dtest.name=org.apache.cassandra.tools.CompactionStressTest
> -Dtest.methods=testWriteAndCompact
> ant testsome -Dtest.name=org.apache.cassandra.tools.cqlsh.CqlshTest
> -Dtest.methods=testCopyOnlyThoseRowsThatMatchVectorTypeSize
> {code}
>
> The patch is aimed to generate files in the tmp directory to fix 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-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850143#comment-17850143
]
Brandon Williams commented on CASSANDRA-17667:
--
I converted it to pytest in CASSANDRA-18088,
[here|https://github.com/driftx/cassandra/commit/62c94ccf4cb2432fde954bf4c12db1325b3a62a1].
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
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-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850139#comment-17850139
]
Brandon Williams commented on CASSANDRA-17667:
--
bq. 4.0.x uses nosetests
Can you show me where?
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
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-19663) trunk fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849392#comment-17849392
]
Brandon Williams commented on CASSANDRA-19663:
--
Try removing the ~/.m2 directory if it has one, since that is outside of what
is cloned.
> trunk fails to start
>
>
> Key: CASSANDRA-19663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19663
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jon Haddad
>Priority: Normal
>
> On commit {{6701259bce91672a7c3ca9fb77ea7b040e9c}}, I get errors on
> startup.
> Verified the build was successful:
> {noformat}
> easy-cass-lab.amazon-ebs.ubuntu: BUILD SUCCESSFUL
> easy-cass-lab.amazon-ebs.ubuntu: Total time: 1 minute 41 seconds
> {noformat}
> Running on a new Ubuntu instance:
> {noformat}
> INFO [main] 2024-05-24 18:31:16,397 YamlConfigurationLoader.java:103 -
> Configuration location: file:/usr/local/cassandra/trunk/conf/cassandra.yaml
> ERROR [main] 2024-05-24 18:31:16,470 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.NoSuchMethodError: 'void
> org.yaml.snakeyaml.LoaderOptions.setCodePointLimit(int)'
> at
> org.apache.cassandra.config.YamlConfigurationLoader.getDefaultLoaderOptions(YamlConfigurationLoader.java:433)
> at
> org.apache.cassandra.config.YamlConfigurationLoader$CustomConstructor.(YamlConfigurationLoader.java:278)
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:135)
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:116)
> at
> org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:403)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:265)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:250)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:781)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:724)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)
> {noformat}
> Running on Java 17:
> {noformat}
> ubuntu@cassandra0:~$ java -version
> openjdk version "17.0.10" 2024-01-16
> OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
> OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04.1, mixed mode,
> sharing)
> {noformat}
> Built with 11.
> The only configs I changed:
> {noformat}
> cluster_name: "system_views"
> num_tokens: 4
> seed_provider:
> class_name: "org.apache.cassandra.locator.SimpleSeedProvider"
> parameters:
> seeds: "10.0.0.225"
> hints_directory: "/mnt/cassandra/hints"
> data_file_directories:
> - "/mnt/cassandra/data"
> commitlog_directory: "/mnt/cassandra/commitlog"
> concurrent_reads: 64
> concurrent_writes: 64
> trickle_fsync: true
> endpoint_snitch: "Ec2Snitch"
> {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-19663) trunk fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849378#comment-17849378
]
Brandon Williams commented on CASSANDRA-19663:
--
This looks like some kind of build problem and doesn't repro for me, maybe try
a realclean?
> trunk fails to start
>
>
> Key: CASSANDRA-19663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19663
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jon Haddad
>Priority: Normal
>
> On commit {{6701259bce91672a7c3ca9fb77ea7b040e9c}}, I get errors on
> startup.
> Verified the build was successful:
> {noformat}
> easy-cass-lab.amazon-ebs.ubuntu: BUILD SUCCESSFUL
> easy-cass-lab.amazon-ebs.ubuntu: Total time: 1 minute 41 seconds
> {noformat}
> Running on a new Ubuntu instance:
> {noformat}
> INFO [main] 2024-05-24 18:31:16,397 YamlConfigurationLoader.java:103 -
> Configuration location: file:/usr/local/cassandra/trunk/conf/cassandra.yaml
> ERROR [main] 2024-05-24 18:31:16,470 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.NoSuchMethodError: 'void
> org.yaml.snakeyaml.LoaderOptions.setCodePointLimit(int)'
> at
> org.apache.cassandra.config.YamlConfigurationLoader.getDefaultLoaderOptions(YamlConfigurationLoader.java:433)
> at
> org.apache.cassandra.config.YamlConfigurationLoader$CustomConstructor.(YamlConfigurationLoader.java:278)
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:135)
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:116)
> at
> org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:403)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:265)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:250)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:781)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:724)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)
> {noformat}
> Running on Java 17:
> {noformat}
> ubuntu@cassandra0:~$ java -version
> openjdk version "17.0.10" 2024-01-16
> OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
> OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04.1, mixed mode,
> sharing)
> {noformat}
> Built with 11.
> The only configs I changed:
> {noformat}
> cluster_name: "system_views"
> num_tokens: 4
> seed_provider:
> class_name: "org.apache.cassandra.locator.SimpleSeedProvider"
> parameters:
> seeds: "10.0.0.225"
> hints_directory: "/mnt/cassandra/hints"
> data_file_directories:
> - "/mnt/cassandra/data"
> commitlog_directory: "/mnt/cassandra/commitlog"
> concurrent_reads: 64
> concurrent_writes: 64
> trickle_fsync: true
> endpoint_snitch: "Ec2Snitch"
> {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-19241) Upgrade ci-cassandra.a.o agents to Ubuntu 22.04.3
[ https://issues.apache.org/jira/browse/CASSANDRA-19241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849375#comment-17849375 ] Brandon Williams commented on CASSANDRA-19241: -- 41 and 42 in INFRA-25820. It looks like 43 may need to be replaced like 39 was. > Upgrade ci-cassandra.a.o agents to Ubuntu 22.04.3 > - > > Key: CASSANDRA-19241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19241 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Michael Semb Wever >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > All agents are currently Ubuntu 18.04 LTS per the > [docs|https://github.com/apache/cassandra-builds/blob/trunk/ASF-jenkins-agents.md#server-requirements]. > All agents need to be upgraded to Ubuntu 22.04.3 LTS. -- 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-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849368#comment-17849368
]
Brandon Williams commented on CASSANDRA-17667:
--
That looks good to me [~bschoeni] if you want to prepare the branches.
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
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-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:all-tabpanel
]
Brandon Williams updated CASSANDRA-19661:
-
Bug Category: Parent values: Availability(12983)Level 1 values:
Unavailable(12994)
Complexity: Normal
Component/s: Feature/SAI
Discovered By: User Report
Fix Version/s: 5.0-rc
5.x
Severity: Normal
Status: Open (was: Triage Needed)
The schema alone is not enough to reproduce, but it looks like this should
block 5.0-rc.
> 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', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.UnifiedCompactionStrategy',
> 'scaling_parameters': 'T4', 'target_sstable_size': '1GiB'}
> AND compression =
[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=17849305#comment-17849305 ] Brandon Williams commented on CASSANDRA-19632: -- The auth failure looks like CASSANDRA-19217 and durable writes is CASSANDRA-19601. +1 > 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] [Updated] (CASSANDRA-19217) Test failure: auth_test.TestAuthUnavailable
[ https://issues.apache.org/jira/browse/CASSANDRA-19217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19217: - Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Test failure: auth_test.TestAuthUnavailable > --- > > Key: CASSANDRA-19217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19217 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1233/workflows/bb617340-f1da-4550-9c87-5541469972c4/jobs/62551/tests -- 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-19217) Test failure: auth_test.TestAuthUnavailable
[ https://issues.apache.org/jira/browse/CASSANDRA-19217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849304#comment-17849304 ] Brandon Williams commented on CASSANDRA-19217: -- Also here: https://app.circleci.com/pipelines/github/instaclustr/cassandra/4344/workflows/f9410f3a-9af4-4924-a2c8-44fc3d7384c0/jobs/237001/tests > Test failure: auth_test.TestAuthUnavailable > --- > > Key: CASSANDRA-19217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19217 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1233/workflows/bb617340-f1da-4550-9c87-5541469972c4/jobs/62551/tests -- 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-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=17849268#comment-17849268 ] Brandon Williams commented on CASSANDRA-19654: -- We're already [suppressing|https://github.com/apache/cassandra/blob/trunk/.build/owasp/dependency-check-suppressions.xml] some jackson-databind and netty CVEs, if this isn't tripping OWASP then I'm not sure it's a problem. > 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-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 ] Brandon Williams updated CASSANDRA-19632: - Reviewers: Brandon Williams Status: Review In Progress (was: Needs Committer) > 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] [Updated] (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:all-tabpanel
]
Brandon Williams updated CASSANDRA-19658:
-
Test and Documentation Plan: run CI
Status: Patch Available (was: Open)
> 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-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=17849089#comment-17849089
]
Brandon Williams commented on CASSANDRA-19658:
--
bq. Looks like fallout from CASSANDRA-15439
Indeed it was, patch
[here|https://github.com/driftx/cassandra-dtest/commit/b6a87433bfb37a00fe195fb838581864d66dee35]
to set the timeout to match the test.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19658-4.0]|[repeats|https://app.circleci.com/pipelines/github/driftx/cassandra/1646/workflows/1d6dccad-7313-43f9-83a6-8fad2d592a38]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-19658-4.1]|[repeats|https://app.circleci.com/pipelines/github/driftx/cassandra/1647/workflows/944ecc10-0573-4c64-a180-db4006db30b1]|
|[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19658-5.0]|[repeats|https://app.circleci.com/pipelines/github/driftx/cassandra/1648/workflows/2b5d5e3f-614a-4f02-b43c-b3efd345d2f1]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19658-trunk]|[repeats|https://app.circleci.com/pipelines/github/driftx/cassandra/1649/workflows/01e57f68-f196-4986-b51c-2e90c4e1058a]|
> 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-19660) Support for netty-tcnative 2.0.62+
[ https://issues.apache.org/jira/browse/CASSANDRA-19660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849002#comment-17849002 ] Brandon Williams commented on CASSANDRA-19660: -- 2.0.62 for trunk sounds reasonable to me. > Support for netty-tcnative 2.0.62+ > -- > > Key: CASSANDRA-19660 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19660 > Project: Cassandra > Issue Type: Improvement >Reporter: Zbyszek Z >Priority: Normal > > Hello, > Are there plans to support netty-tcnative in version 2.0.62? Current version > 2.0.36 does not work with openssl3.x. Motivation is that openssl 3.0.9+ is > FIPS certified. > Currently i am able to replace library default boringSSL implementation with > openssl by recompiling netty-tcnative but cassandra fails to load 2.0.62 > regardless if it is compiled with 1.1.1 or 3.0. > Or is there other way to implement openssl3.x ? > Thank you -- 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-19660) Support for netty-tcnative 2.0.62+
[ https://issues.apache.org/jira/browse/CASSANDRA-19660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848982#comment-17848982 ] Brandon Williams commented on CASSANDRA-19660: -- Trunk is already at 2.0.61: https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml#L802 We won't be upgrading libs in released majors (including 5.0 at this point since it is so close.) > Support for netty-tcnative 2.0.62+ > -- > > Key: CASSANDRA-19660 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19660 > Project: Cassandra > Issue Type: Improvement >Reporter: Zbyszek Z >Priority: Normal > > Hello, > Are there plans to support netty-tcnative in version 2.0.62? Current version > 2.0.36 does not work with openssl3.x. Motivation is that openssl 3.0.9+ is > FIPS certified. > Currently i am able to replace library default boringSSL implementation with > openssl by recompiling netty-tcnative but cassandra fails to load 2.0.62 > regardless if it is compiled with 1.1.1 or 3.0. > Or is there other way to implement openssl3.x ? > Thank you -- 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=17848784#comment-17848784
]
Brandon Williams commented on CASSANDRA-19658:
--
Looks like fallout from CASSANDRA-15439
> 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] [Updated] (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:all-tabpanel
]
Brandon Williams updated CASSANDRA-19658:
-
Fix Version/s: 5.0.x
(was: 5.0-rc)
> 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] [Updated] (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:all-tabpanel
]
Brandon Williams updated CASSANDRA-19658:
-
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Cluster/Membership
Discovered By: DTest
Fix Version/s: 4.0.x
4.1.x
5.0-rc
Severity: Normal
Status: Open (was: Triage Needed)
> 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-rc
>
>
> 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] [Assigned] (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:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-19658:
Assignee: Brandon Williams
> 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
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> 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] [Created] (CASSANDRA-19658) Test failure: replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
Brandon Williams created CASSANDRA-19658:
Summary: 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
Reporter: Brandon Williams
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] [Updated] (CASSANDRA-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19648: - Fix Version/s: 5.1 > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.1-alpha1, 5.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- 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 ] Brandon Williams updated CASSANDRA-19656: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > 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=17848742#comment-17848742 ] Brandon Williams commented on CASSANDRA-19656: -- bq. Would be supportive of revisiting alternate libs in a future major to avoid the need to explicitly disable as well. I am in agreement there, it would be best to not have to do this again. For now, I have again confirmed nothing is phoning home while capturing packets during manual tests, unit tests, in-jvm dtests, and the fql and auditlog python dtests. [Here|https://github.com/driftx/cassandra/tree/CASSANDRA-19656-5.0] is a branch that revives my patch from CASSANDRA-18538 to disable in the server options, and takes [~aweisberg]'s suggestion of also disabling in static init in DatabaseDescriptor. If that looks agreeable I will merge up and run CI. > 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-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=17848634#comment-17848634 ] Brandon Williams commented on CASSANDRA-19632: -- I think we should check some microbenchmarks around this. My understanding is the trace function will call isTraceEnabled itself, so wrapping this purely for trace logging calls shouldn't be beneficial, only if the flag is used to prevent other execution from occurring. > 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: 10m > 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] [Updated] (CASSANDRA-19656) Revisit disabling chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-19656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19656: - Change Category: Quality Assurance Complexity: Normal Component/s: Local/Other Fix Version/s: 5.0.x 5.x Assignee: Brandon Williams Status: Open (was: Triage Needed) > 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] [Created] (CASSANDRA-19656) Revisit disabling chronicle analytics
Brandon Williams created CASSANDRA-19656: Summary: Revisit disabling chronicle analytics Key: CASSANDRA-19656 URL: https://issues.apache.org/jira/browse/CASSANDRA-19656 Project: Cassandra Issue Type: Task Reporter: Brandon Williams 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-19652) ShallowInfoRetriever: cache offsets to void resetting of RandomAccessReader buffer
[ https://issues.apache.org/jira/browse/CASSANDRA-19652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19652: - Change Category: Performance Complexity: Normal Status: Open (was: Triage Needed) > ShallowInfoRetriever: cache offsets to void resetting of RandomAccessReader > buffer > -- > > Key: CASSANDRA-19652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19652 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Dmitry Konstantinov >Assignee: Dmitry Konstantinov >Priority: Normal > Fix For: 5.x > > > Currently in > org.apache.cassandra.io.sstable.format.big.RowIndexEntry.ShallowInfoRetriever#fetchIndex > we do 2 seek/read operations: 1st is to find the offset for IndexInfo and > the 2nd to read it. These are two quite distant regions of the file and for > standard disk access mode we do not use a benefit from a buffer in > RandomAccessReader due to jumping between the regions and reseting this > buffer again and again. A possible improvement here can be to read and cache > N first offsets (to limit the amount of memory to use) on the first read and > do later only sequential reads of IndexInfo data. By caching of less than 1Kb > we can reduce the number of syscalls even more, in my case: from few hundred > to less than 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-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19651:
-
Fix Version/s: 5.0.x
5.x
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19651:
-
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Component/s: Legacy/Observability
Severity: Normal
Status: Open (was: Triage Needed)
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x
>
>
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19651:
-
Fix Version/s: 4.1.x
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x
>
>
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19649) add absurdfarce's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-19649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19649: - Resolution: Fixed Status: Resolved (was: Triage Needed) Done in r69303. > add absurdfarce's gpg key to project's KEYS file > > > Key: CASSANDRA-19649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19649 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Bret McGuire >Assignee: Brandon Williams >Priority: Normal > Attachments: absurdfarce_keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > [https://dist.apache.org/repos/dist/release/cassandra/KEYS] > My gpg public key here has the fingerprint > 498AAC354AA5CB36FAAB7608B6E83A2D2E447E56 > References: > - [https://www.apache.org/dev/release-signing#keys-policy] > - [http://www.apache.org/legal/release-policy.html] -- 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-19649) add absurdfarce's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-19649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-19649: Assignee: Brandon Williams > add absurdfarce's gpg key to project's KEYS file > > > Key: CASSANDRA-19649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19649 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Bret McGuire >Assignee: Brandon Williams >Priority: Normal > Attachments: absurdfarce_keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > [https://dist.apache.org/repos/dist/release/cassandra/KEYS] > My gpg public key here has the fingerprint > 498AAC354AA5CB36FAAB7608B6E83A2D2E447E56 > References: > - [https://www.apache.org/dev/release-signing#keys-policy] > - [http://www.apache.org/legal/release-policy.html] -- 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-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19648: - Status: Needs Committer (was: Patch Available) > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- 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-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847910#comment-17847910 ] Brandon Williams commented on CASSANDRA-19648: -- Simple enough, looks good to me. +1 > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- 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-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19648: - Test and Documentation Plan: none Status: Patch Available (was: Open) > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- 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-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19648: - Fix Version/s: 5.x (was: 5.1) > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- 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-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19648: - Change Category: Operability Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- 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-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19645: - Reviewers: Brandon Williams, Stefan Miklosovic (was: Brandon Williams) > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.1-alpha1 > > Time Spent: 20m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- 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-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19645: - Fix Version/s: 5.1 > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.1-alpha1, 5.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- 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-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847689#comment-17847689 ] Brandon Williams commented on CASSANDRA-19645: -- I'm +1 on doing that on commit, I don't think we need to rerun CI now that we know no tests rely on these log messages. > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- 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-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19645: - Status: Needs Committer (was: Patch Available) > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- 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-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19645: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- 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-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847674#comment-17847674 ] Brandon Williams commented on CASSANDRA-19645: -- Failures are known or timeouts, +1 from me. > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- 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-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847549#comment-17847549 ] Brandon Williams commented on CASSANDRA-19645: -- Looks good to me, checking CI. [!https://ci-cassandra.apache.org/job/Cassandra-devbranch-5/32/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch-5/detail/Cassandra-devbranch/32/pipeline] > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- 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-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19645: - Reviewers: Brandon Williams > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- 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-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19645: - Bug Category: Parent values: Correctness(12982) Complexity: Low Hanging Fruit Component/s: Local/Other Discovered By: User Report Fix Version/s: 5.x Severity: Low Status: Open (was: Triage Needed) > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- 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-16364) Joining nodes simultaneously with auto_bootstrap:false can cause token collision
[
https://issues.apache.org/jira/browse/CASSANDRA-16364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847505#comment-17847505
]
Brandon Williams commented on CASSANDRA-16364:
--
bq. Does this apply in trunk with tcm? Think we should be removing fixVersion
5.x
I removed it, I'm the one who errantly added it when I added 5.0.x (muscle
memory or something)
> Joining nodes simultaneously with auto_bootstrap:false can cause token
> collision
>
>
> Key: CASSANDRA-16364
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16364
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Paulo Motta
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> While raising a 6-node ccm cluster to test 4.0-beta4, 2 nodes chosen the same
> tokens using the default {{allocate_tokens_for_local_rf}}. However they both
> succeeded bootstrap with colliding tokens.
> We were familiar with this issue from CASSANDRA-13701 and CASSANDRA-16079,
> and the workaround to fix this is to avoid parallel bootstrap when using
> {{allocate_tokens_for_local_rf}}.
> However, since this is the default behavior, we should try to detect and
> prevent this situation when possible, since it can break users relying on
> parallel bootstrap behavior.
> I think we could prevent this as following:
> 1. announce intent to bootstrap via gossip (ie. add node on gossip without
> token information)
> 2. wait for gossip to settle for a longer period (ie. ring delay)
> 3. allocate tokens (if multiple bootstrap attempts are detected, tie break
> via node-id)
> 4. broadcast tokens and move on with bootstrap
--
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-16364) Joining nodes simultaneously with auto_bootstrap:false can cause token collision
[
https://issues.apache.org/jira/browse/CASSANDRA-16364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16364:
-
Fix Version/s: (was: 5.x)
> Joining nodes simultaneously with auto_bootstrap:false can cause token
> collision
>
>
> Key: CASSANDRA-16364
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16364
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Paulo Motta
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> While raising a 6-node ccm cluster to test 4.0-beta4, 2 nodes chosen the same
> tokens using the default {{allocate_tokens_for_local_rf}}. However they both
> succeeded bootstrap with colliding tokens.
> We were familiar with this issue from CASSANDRA-13701 and CASSANDRA-16079,
> and the workaround to fix this is to avoid parallel bootstrap when using
> {{allocate_tokens_for_local_rf}}.
> However, since this is the default behavior, we should try to detect and
> prevent this situation when possible, since it can break users relying on
> parallel bootstrap behavior.
> I think we could prevent this as following:
> 1. announce intent to bootstrap via gossip (ie. add node on gossip without
> token information)
> 2. wait for gossip to settle for a longer period (ie. ring delay)
> 3. allocate tokens (if multiple bootstrap attempts are detected, tie break
> via node-id)
> 4. broadcast tokens and move on with bootstrap
--
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
