[jira] [Updated] (CASSANDRA-19554) Website - Download section - Update / remove EOL dates
[ https://issues.apache.org/jira/browse/CASSANDRA-19554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19554: --- Status: Ready to Commit (was: Review In Progress) > Website - Download section - Update / remove EOL dates > -- > > Key: CASSANDRA-19554 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19554 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Thomas Steinmaurer >Assignee: Himanshu Jindal >Priority: Normal > Attachments: image-2024-04-11-13-15-52-317.png > > > Enterprise customers with on-prem Cassandra usage can be pretty nitpicking in > terms of EOL, running unsupported Cassandra versions and they often refer to > what is stated in https://cassandra.apache.org/_/download.html (as the only > source available?) and don't really think about the dependency to 5.0 GA, but > just reflecting EOL date information there. > As of April 11, 2024, the download section states the following information: > !image-2024-04-11-13-15-52-317.png! > According to that, 3.x is unmaintained, 4.0 soon to be EOL etc ... > Either remove these EOL estimates or keep them strongly maintained aligned > with an updated 5.0 GA timeline. > Thanks! -- This message was sent by Atlassian Jira (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-19554) Website - Download section - Update / remove EOL dates
[ https://issues.apache.org/jira/browse/CASSANDRA-19554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19554: --- Reviewers: Bernardo Botella, Michael Semb Wever Status: Review In Progress (was: Patch Available) > Website - Download section - Update / remove EOL dates > -- > > Key: CASSANDRA-19554 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19554 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Thomas Steinmaurer >Assignee: Himanshu Jindal >Priority: Normal > Attachments: image-2024-04-11-13-15-52-317.png > > > Enterprise customers with on-prem Cassandra usage can be pretty nitpicking in > terms of EOL, running unsupported Cassandra versions and they often refer to > what is stated in https://cassandra.apache.org/_/download.html (as the only > source available?) and don't really think about the dependency to 5.0 GA, but > just reflecting EOL date information there. > As of April 11, 2024, the download section states the following information: > !image-2024-04-11-13-15-52-317.png! > According to that, 3.x is unmaintained, 4.0 soon to be EOL etc ... > Either remove these EOL estimates or keep them strongly maintained aligned > with an updated 5.0 GA timeline. > Thanks! -- This message was sent by Atlassian Jira (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-19554) Website - Download section - Update / remove EOL dates
[ https://issues.apache.org/jira/browse/CASSANDRA-19554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19554: --- Fix Version/s: NA Source Control Link: https://github.com/apache/cassandra-website/commit/f313e9f866051fb767c7006012df5f089fc9bd3c Resolution: Fixed Status: Resolved (was: Ready to Commit) > Website - Download section - Update / remove EOL dates > -- > > Key: CASSANDRA-19554 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19554 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Thomas Steinmaurer >Assignee: Himanshu Jindal >Priority: Normal > Fix For: NA > > Attachments: image-2024-04-11-13-15-52-317.png > > > Enterprise customers with on-prem Cassandra usage can be pretty nitpicking in > terms of EOL, running unsupported Cassandra versions and they often refer to > what is stated in https://cassandra.apache.org/_/download.html (as the only > source available?) and don't really think about the dependency to 5.0 GA, but > just reflecting EOL date information there. > As of April 11, 2024, the download section states the following information: > !image-2024-04-11-13-15-52-317.png! > According to that, 3.x is unmaintained, 4.0 soon to be EOL etc ... > Either remove these EOL estimates or keep them strongly maintained aligned > with an updated 5.0 GA timeline. > Thanks! -- This message was sent by Atlassian Jira (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-19554) Website - Download section - Update / remove EOL dates
[ https://issues.apache.org/jira/browse/CASSANDRA-19554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854083#comment-17854083 ] Michael Semb Wever commented on CASSANDRA-19554: Committed https://github.com/apache/cassandra-website/commit/f313e9f866051fb767c7006012df5f089fc9bd3c Thanks [~himanshujindal] > Website - Download section - Update / remove EOL dates > -- > > Key: CASSANDRA-19554 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19554 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Thomas Steinmaurer >Assignee: Himanshu Jindal >Priority: Normal > Attachments: image-2024-04-11-13-15-52-317.png > > > Enterprise customers with on-prem Cassandra usage can be pretty nitpicking in > terms of EOL, running unsupported Cassandra versions and they often refer to > what is stated in https://cassandra.apache.org/_/download.html (as the only > source available?) and don't really think about the dependency to 5.0 GA, but > just reflecting EOL date information there. > As of April 11, 2024, the download section states the following information: > !image-2024-04-11-13-15-52-317.png! > According to that, 3.x is unmaintained, 4.0 soon to be EOL etc ... > Either remove these EOL estimates or keep them strongly maintained aligned > with an updated 5.0 GA timeline. > Thanks! -- This message was sent by Atlassian Jira (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-19534) Unbounded queues in native transport requests lead to node instability
[
https://issues.apache.org/jira/browse/CASSANDRA-19534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19534:
---
Fix Version/s: 4.1.6
5.0-beta2
5.0
5.1
(was: 5.x)
(was: 4.1.x)
(was: 5.0-rc)
> Unbounded queues in native transport requests lead to node instability
> --
>
> Key: CASSANDRA-19534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19534
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Jon Haddad
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 4.1.6, 5.0-beta2, 5.0, 5.1
>
> Attachments: Scenario 1 - QUEUE + Backpressure.jpg, Scenario 1 -
> QUEUE.jpg, Scenario 1 - Stock.jpg, Scenario 2 - QUEUE + Backpressure.jpg,
> Scenario 2 - QUEUE.jpg, Scenario 2 - Stock.jpg, ci_summary-4.1.html,
> ci_summary-5.0.html, ci_summary-trunk.html, ci_summary.html,
> image-2024-05-03-16-08-10-101.png, screenshot-1.png, screenshot-2.png,
> screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png,
> screenshot-7.png, screenshot-8.png, screenshot-9.png
>
> Time Spent: 10h 10m
> Remaining Estimate: 0h
>
> When a node is under pressure, hundreds of thousands of requests can show up
> in the native transport queue, and it looks like it can take way longer to
> timeout than is configured. We should be shedding load much more
> aggressively and use a bounded queue for incoming work. This is extremely
> evident when we combine a resource consuming workload with a smaller one:
> Running 5.0 HEAD on a single node as of today:
> {noformat}
> # populate only
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --maxrlat 100 --populate
> 10m --rate 50k -n 1
> # workload 1 - larger reads
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --rate 200 -d 1d
> # second workload - small reads
> easy-cass-stress run KeyValue -p 1m --rate 20k -r .5 -d 24h{noformat}
> It appears our results don't time out at the requested server time either:
>
> {noformat}
> Writes Reads
> Deletes Errors
> Count Latency (p99) 1min (req/s) | Count Latency (p99) 1min (req/s) |
> Count Latency (p99) 1min (req/s) | Count 1min (errors/s)
> 950286 70403.93 634.77 | 789524 70442.07 426.02 |
> 0 0 0 | 9580484 18980.45
> 952304 70567.62 640.1 | 791072 70634.34 428.36 |
> 0 0 0 | 9636658 18969.54
> 953146 70767.34 640.1 | 791400 70767.76 428.36 |
> 0 0 0 | 9695272 18969.54
> 956833 71171.28 623.14 | 794009 71175.6 412.79 |
> 0 0 0 | 9749377 19002.44
> 959627 71312.58 656.93 | 795703 71349.87 435.56 |
> 0 0 0 | 9804907 18943.11{noformat}
>
> After stopping the load test altogether, it took nearly a minute before the
> requests were no longer queued.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850305#comment-17850305
]
Michael Semb Wever commented on CASSANDRA-12937:
bq. I know Mick has approved on the PR…
I
[removed|https://issues.apache.org/jira/browse/CASSANDRA-12937?focusedCommentId=17831674=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17831674]
that approval once the concerns around bringing keyspace into the serialiser
was raised.
I will review again…
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8.5h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19667) update deps in netbeans project file (2024-05)
[
https://issues.apache.org/jira/browse/CASSANDRA-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19667:
---
Fix Version/s: 4.0.14
4.1.6
5.0-beta2
5.0
5.1
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
(was: 5.0.x)
Source Control Link:
https://github.com/apache/cassandra/commit/34e7fe4b4f53ecf23252a1e4dc36c15d07c9584d
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> update deps in netbeans project file (2024-05)
> --
>
> Key: CASSANDRA-19667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19667
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.14, 4.1.6, 5.0-beta2, 5.0, 5.1
>
>
> Dependencies have changed and the {{ide/nbproject/project.xml}} file needs to
> be updated accordingly.
--
This message was sent by Atlassian Jira
(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-19667) update deps in netbeans project file (2024-05)
[
https://issues.apache.org/jira/browse/CASSANDRA-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19667:
---
Reviewers: Enrico Olivelli
Status: Review In Progress (was: Patch Available)
> update deps in netbeans project file (2024-05)
> --
>
> Key: CASSANDRA-19667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19667
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Dependencies have changed and the {{ide/nbproject/project.xml}} file needs to
> be updated accordingly.
--
This message was sent by Atlassian Jira
(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-19667) update deps in netbeans project file (2024-05)
[
https://issues.apache.org/jira/browse/CASSANDRA-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19667:
---
Status: Ready to Commit (was: Review In Progress)
> update deps in netbeans project file (2024-05)
> --
>
> Key: CASSANDRA-19667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19667
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Dependencies have changed and the {{ide/nbproject/project.xml}} file needs to
> be updated accordingly.
--
This message was sent by Atlassian Jira
(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-19667) update deps in netbeans project file (2024-05)
[
https://issues.apache.org/jira/browse/CASSANDRA-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19667:
---
Test and Documentation Plan: `ant jar`, open project in netbeans, all
sources are unbadged (no errors).
Status: Patch Available (was: Open)
> update deps in netbeans project file (2024-05)
> --
>
> Key: CASSANDRA-19667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19667
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Dependencies have changed and the {{ide/nbproject/project.xml}} file needs to
> be updated accordingly.
--
This message was sent by Atlassian Jira
(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-19667) update deps in netbeans project file (2024-05)
[
https://issues.apache.org/jira/browse/CASSANDRA-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19667:
---
Change Category: Operability
Complexity: Low Hanging Fruit
Fix Version/s: 4.0.x
4.1.x
5.0.x
5.x
Assignee: Michael Semb Wever
Status: Open (was: Triage Needed)
> update deps in netbeans project file (2024-05)
> --
>
> Key: CASSANDRA-19667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19667
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Dependencies have changed and the {{ide/nbproject/project.xml}} file needs to
> be updated accordingly.
--
This message was sent by Atlassian Jira
(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-19667) update deps in netbeans project file (2024-05)
[
https://issues.apache.org/jira/browse/CASSANDRA-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850177#comment-17850177
]
Michael Semb Wever commented on CASSANDRA-19667:
trivial stuff.
patches
- 4.0:
https://github.com/apache/cassandra/compare/cassandra-4.0...thelastpickle:cassandra:mck/nb-deps-202405/4.0
- 4.1:
https://github.com/apache/cassandra/compare/cassandra-4.1...thelastpickle:cassandra:mck/nb-deps-202405/4.1
- 5.0:
https://github.com/apache/cassandra/compare/cassandra-5.0...thelastpickle:cassandra:mck/nb-deps-202405/5.0
- trunk:
https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/nb-deps-202405/trunk
> update deps in netbeans project file (2024-05)
> --
>
> Key: CASSANDRA-19667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19667
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Priority: Normal
>
> Dependencies have changed and the {{ide/nbproject/project.xml}} file needs to
> be updated accordingly.
--
This message was sent by Atlassian Jira
(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-19667) update deps in netbeans project file (2024-05)
[
https://issues.apache.org/jira/browse/CASSANDRA-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19667:
---
Summary: update deps in netbeans project file (2024-05) (was: update deps
in netbeans project file)
> update deps in netbeans project file (2024-05)
> --
>
> Key: CASSANDRA-19667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19667
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Priority: Normal
>
> Dependencies have changed and the {{ide/nbproject/project.xml}} file needs to
> be updated accordingly.
--
This message was sent by Atlassian Jira
(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-19667) update deps in netbeans project file
Michael Semb Wever created CASSANDRA-19667:
--
Summary: update deps in netbeans project file
Key: CASSANDRA-19667
URL: https://issues.apache.org/jira/browse/CASSANDRA-19667
Project: Cassandra
Issue Type: Task
Components: Build
Reporter: Michael Semb Wever
Dependencies have changed and the {{ide/nbproject/project.xml}} file needs to
be updated accordingly.
--
This message was sent by Atlassian Jira
(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-17047) Dropping a column can break queries until the schema is fully propagated (TAKE 2)
[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850094#comment-17850094
]
Michael Semb Wever commented on CASSANDRA-17047:
what's the latest here?
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> -
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[main/:na]
> ...
> {code}
> Note that it doesn't matter if we {{SELECT *}} or {{SELECT id, v1}}
> CASSANDRA-15899 tried to fix the problem when columns are dropped as well as
> when columns are added. Unfortunately the fix introduced an issue and had to
> be reverted in CASSANDRA-16735.
> If the scenario for ADDED columns is tricky, the original scenario for
> DROPPED columns can be solved in a safe way at the {{ColumnFilter}} level.
> By consequence, I think that we should at least solve that scenario.
> [~bdeggleston], [~samt], [~ifesdjeen] does my proposal makes sense to 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] [Updated] (CASSANDRA-14556) Stream entire SSTables when possible
[ https://issues.apache.org/jira/browse/CASSANDRA-14556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-14556: --- Source Control Link: https://github.com/apache/cassandra/commit/47a12c52a313258307ab88392f75c5866d9a2bb1 https://github.com/apache/cassandra-dtest/commit/d291b2b90326c62c2df8f49098c6deb915c16460 > Stream entire SSTables when possible > > > Key: CASSANDRA-14556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14556 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Streaming and Messaging >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Labels: Performance > Fix For: 4.0-alpha1, 4.0 > > > During streaming, Cassandra reifies the sstables into objects. This creates > unnecessary garbage and slows down the whole streaming process as some > sstables can be transferred as a whole file rather than individual > partitions. The objective of the ticket is to detect when a whole sstable can > be transferred and skip the object reification. We can also use a zero-copy > path to avoid bringing data into user-space on both sending and receiving > side. -- This message was sent by Atlassian Jira (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-19664) Accord Journal Determinism: PreAccept replay stability
[ https://issues.apache.org/jira/browse/CASSANDRA-19664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19664: --- Summary: Accord Journal Determinism: PreAccept replay stability (was: Accord Jounral Determinism: PreAccept replay stability ) > Accord Journal Determinism: PreAccept replay stability > --- > > Key: CASSANDRA-19664 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19664 > Project: Cassandra > Issue Type: Bug >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > Currently, some messages, such as PreAccept can have some of their context > initialized on replay. This patch adds a concept of Context to Journal that > can be used for arbitrary information necessary for replaying them just the > way they were executed the first time. -- This message was sent by Atlassian Jira (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-16383) Python dtests to use ccm tag instead of the `cassandra-test` branch
[
https://issues.apache.org/jira/browse/CASSANDRA-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16383:
---
Description:
The python dtests (cassandra-dtest repo) creates its clusters using ccm.
The version of ccm it uses is the HEAD of the {{cassandra-test}} branch. This
is referenced in the
[requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
The history for why a separate branch of ccm is used by dtests is explained in
https://github.com/apache/cassandra-dtest/pull/13
Long story short: the separate branch avoids two headaches
- the 'latest commit to master' broke all the c* builds surprises', and
- the 'i have to cut a release of ccm just to get a ccm change into use by
dtests'
But the two branches: {{master}} and {{cassandra-test}}; have effectively been
treated as two separate repositories, with (non-fast-forward) merges happening
in both directions. This makes the git history of both branches messy and
difficult to use, and it makes the merge strategy confusing. Bi-directional
merging between branches is considered a poor practice by many (Laura Wingerd's
'The Flow of Change'
[presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
and
[book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
refers to this as "don't drive through hedges" and encourages the "merge down,
copy up" approach against the "tofu scale: firm above, soft below").
To date, AFAIK no merges between the branches have occurred since January 2018.
A possible improvement to this process is to replace the {{cassandra-test}}
branch with a floating tag (of the same name).
That way new commits to {{master}} are not automatically used by the python
dtests. And changes made to ccm and intended/needed to be used by the dtests
can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
The re-tagging approach is
{code}
git tag -a -f cassandra-test
git push origin :refs/tags/cassandra-test
git push origin --tags
{code}
was:
The python dtests (cassandra-dtest repo) creates its clusters using ccm.
The version of ccm it uses is the HEAD of the {{cassandra-test}} branch. This
is referenced in the
[requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
The history for why a separate branch of ccm is used by dtests is explained in
https://github.com/apache/cassandra-dtest/pull/13
Long story short: the separate branch avoids two headaches
- the 'latest commit to master' broke all the c* builds surprises', and
- the 'i have to cut a release of ccm just to get a ccm change into use by
dtests'
But the two branches: {{master}} and {{cassandra-test}}; have effectively been
treated as two separate repositories, with (non-fast-forward) merges happening
in both directions. This makes the git history of both branches messy and
difficult to use, and it makes the merge strategy confusing. Bi-directional
merging between branches is considered a poor practice by many (Laura Wingerd's
'The Flow of Change'
[presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
and
[book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
refers to this as "don't drive through hedges" and encourages the "merge down,
copy up" approach against the "tofu scale: firm above, soft below").
To date, AFAIK no merges between the branches have occurred since January 2018.
A possible improvement to this process is to replace the {{cassandra-test}}
branch with a floating tag (of the same name).
That way new commits to {{master}} are not automatically used by the python
dtests. And changes made to ccm and intended/needed to be used by the dtests
can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
The re-tagging approach is
{code}
git tag -a -f cassandra-test
git push origin :refs/tags/cassandra-test
git push -f origin --tags
{code}
> Python dtests to use ccm tag instead of the `cassandra-test` branch
> ---
>
> Key: CASSANDRA-16383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16383
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.24, 3.11.10, 4.0-rc1, 4.0
>
>
> The
[jira] [Comment Edited] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849257#comment-17849257
]
Michael Semb Wever edited comment on CASSANDRA-19650 at 5/24/24 12:46 PM:
--
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_trunk_85_ci_summary.html] and
[^CASSANDRA-19650_trunk_85_results_details.tar.xz]
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on the PR
[here|https://github.com/riptano/ccm/pull/770#pullrequestreview-2074344248] his
breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
4.0 cqlsh-test
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/5/
Everything looks good!
was (Author: michaelsembwever):
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
-
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on the PR
[here|https://github.com/riptano/ccm/pull/770#pullrequestreview-2074344248] his
breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
4.0 cqlsh-test
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/5/
Everything looks good!
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz,
> CASSANDRA-19650_trunk_85_ci_summary.html,
> CASSANDRA-19650_trunk_85_results_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(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-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19650:
---
Attachment: CASSANDRA-19650_trunk_85_results_details.tar.xz
CASSANDRA-19650_trunk_85_ci_summary.html
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz,
> CASSANDRA-19650_trunk_85_ci_summary.html,
> CASSANDRA-19650_trunk_85_results_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(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-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849257#comment-17849257
]
Michael Semb Wever edited comment on CASSANDRA-19650 at 5/24/24 12:45 PM:
--
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
-
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on the PR
[here|https://github.com/riptano/ccm/pull/770#pullrequestreview-2074344248] his
breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
4.0 cqlsh-test
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/5/
Everything looks good!
was (Author: michaelsembwever):
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/5/
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on the PR
[here|https://github.com/riptano/ccm/pull/770#pullrequestreview-2074344248] his
breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
Everything looks good!
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(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-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849257#comment-17849257
]
Michael Semb Wever edited comment on CASSANDRA-19650 at 5/24/24 12:11 PM:
--
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/5/
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on the PR
[here|https://github.com/riptano/ccm/pull/770#pullrequestreview-2074344248] his
breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
Everything looks good!
was (Author: michaelsembwever):
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
- wip…
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on the PR
[here|https://github.com/riptano/ccm/pull/770#pullrequestreview-2074344248] his
breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
Everything looks good!
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(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-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849257#comment-17849257
]
Michael Semb Wever edited comment on CASSANDRA-19650 at 5/24/24 10:55 AM:
--
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
- wip…
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on the PR
[here|https://github.com/riptano/ccm/pull/770#pullrequestreview-2074344248] his
breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
Everything looks good!
was (Author: michaelsembwever):
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
- wip…
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on slack his breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
Everything looks good!
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(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-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849257#comment-17849257
]
Michael Semb Wever commented on CASSANDRA-19650:
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
- wip…
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on slack his breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
Everything looks good!
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(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-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19650:
---
Status: Ready to Commit (was: Review In Progress)
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(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-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19650:
---
Attachment: CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(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-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19650:
---
Attachment: CASSANDRA-19650_50_84_ci_summary.html
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(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-18120) Single slow node dramatically reduces cluster logged batch write throughput regardless of CL
[ https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18120: --- Change Category: Operability Complexity: Normal Component/s: Consistency/Coordination Fix Version/s: 4.0.x 4.1.x 5.0.x 5.x Reviewers: Michael Semb Wever Status: Open (was: Triage Needed) > Single slow node dramatically reduces cluster logged batch write throughput > regardless of CL > > > Key: CASSANDRA-18120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18120 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination >Reporter: Dan Sarisky >Assignee: Maxim Chanturiay >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, > QUORUM, or LOCAL_QUORUM) > > On clusters of any size - a single extremely slow node causes a ~90% loss of > cluster-wide throughput using batched writes. We can replicate this in the > lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1. > > It appears the mechanism in play is: > Those logged batches are immediately written to two replica nodes and the > actual mutations aren't processed until those two nodes acknowledge the batch > statements. Those replica nodes are selected randomly from all nodes in the > local data center currently up in gossip. If a single node is slow, but > still thought to be up in gossip, this eventually causes every other node to > have all of its MutationStages to be waiting while the slow replica accepts > batch writes. > > The code in play appears to be: > See > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245]. > In the method filterBatchlogEndpoints() there is a > Collections.shuffle() to order the endpoints and a > FailureDetector.isEndpointAlive() to test if the endpoint is acceptable. > > This behavior causes Cassandra to move from a multi-node fault tolerant > system toa collection of single points of failure. > > We try to take administrator actions to kill off the extremely slow nodes, > but it would be great to have some notion of "what node is a bad choice" when > writing log batches to replica nodes. > -- This message was sent by Atlassian Jira (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-18120) Single slow node dramatically reduces cluster logged batch write throughput regardless of CL
[ https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849074#comment-17849074 ] Michael Semb Wever edited comment on CASSANDRA-18120 at 5/23/24 6:39 PM: - [~shunsaker], do you want to share the patch you're willing to upstream ? That patch would have had a lot of production exposure already, so it would be my preference. [~maximc], are you ok if we focus on Shayne's patch ? I know you've done a lot of work already, and it sucks when you've completed a patch and it was the first patch offered. Given your expertise now, and not letting it go to waste, it would be very valuable to have you as a reviewer (and tester). bq. Michael Semb Wever and Maxim Chanturiay provide strong arguments against Dynamic snitch. This is not related to logged batch writes, and today the dynamic snitch does nothing for it anyway. The advice to disable the dynamic snitch has been a long standing recommendation from The Last Pickle, aimed at competent Cassandra operators that have healthy and performant clusters, and solid enough monitoring and alerting in place to otherwise detect and deal with a slow node. The dynamic snitch comes with its own overhead, and on healthy performant clusters can't keep up, so offers very little value and hurts latencies. (Don't look past those caveats though!) If you have a problem with slow nodes, and don't have a way to deal with it, then the dynamic snitch is a good option, and adding the same ability to the batchlog makes sense. was (Author: michaelsembwever): [~shunsaker], do you want to share the patch you're willing to upstream ? That patch would have had a lot of production exposure already, so it would be my preference. [~maximc], are you ok if we focus on Shayne's patch ? I know you've done a lot of work already, and it sucks when you've completed a patch and it was the first patch offered. Given your expertise now, and not letting it go to waste, it would be very valuable to have you as a reviewer (and tester). bq. Michael Semb Wever and Maxim Chanturiay provide strong arguments against Dynamic snitch. This is not related to logged batch writes, and today the dynamic snitch does nothing for it anyway. The advice to disable the dynamic snitch has been a long standing recommendation from The Last Pickle, aimed at competent Cassandra operators that have healthy and performant clusters, and solid enough monitoring and alerting in place to otherwise detect and deal with a slow node. The dynamic snitch comes with its own overhead, and on healthy performant clusters can't keep up, so offers very little value. (Don't look past those caveats though!) If you have a problem with slow nodes, and don't have a way to deal with it, then the dynamic snitch is a good option, and adding the same ability to the batchlog makes sense. > Single slow node dramatically reduces cluster logged batch write throughput > regardless of CL > > > Key: CASSANDRA-18120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18120 > Project: Cassandra > Issue Type: Improvement >Reporter: Dan Sarisky >Assignee: Maxim Chanturiay >Priority: Normal > > We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, > QUORUM, or LOCAL_QUORUM) > > On clusters of any size - a single extremely slow node causes a ~90% loss of > cluster-wide throughput using batched writes. We can replicate this in the > lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1. > > It appears the mechanism in play is: > Those logged batches are immediately written to two replica nodes and the > actual mutations aren't processed until those two nodes acknowledge the batch > statements. Those replica nodes are selected randomly from all nodes in the > local data center currently up in gossip. If a single node is slow, but > still thought to be up in gossip, this eventually causes every other node to > have all of its MutationStages to be waiting while the slow replica accepts > batch writes. > > The code in play appears to be: > See > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245]. > In the method filterBatchlogEndpoints() there is a > Collections.shuffle() to order the endpoints and a > FailureDetector.isEndpointAlive() to test if the endpoint is acceptable. > > This behavior causes Cassandra to move from a multi-node fault tolerant > system toa collection of single points of failure. > > We try to take administrator actions to kill off the extremely slow nodes, > but it would be great to have some notion of "what node is a bad choice" when >
[jira] [Comment Edited] (CASSANDRA-18120) Single slow node dramatically reduces cluster logged batch write throughput regardless of CL
[ https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849074#comment-17849074 ] Michael Semb Wever edited comment on CASSANDRA-18120 at 5/23/24 6:38 PM: - [~shunsaker], do you want to share the patch you're willing to upstream ? This patch has had a lot of production exposure already, so it has my preference. [~maximc], are you ok if we focus on Shayne's patch ? I know you've done a lot of work already, and it sucks when you've completed a patch and it was the first patch offered. Given your expertise now, and not letting it go to waste, it would be very valuable to have you as a reviewer (and tester). bq. Michael Semb Wever and Maxim Chanturiay provide strong arguments against Dynamic snitch. This is not related to logged batch writes, and today the dynamic snitch does nothing for it anyway. The advice to disable the dynamic snitch has been a long standing recommendation from The Last Pickle, aimed at competent Cassandra operators that have healthy and performant clusters, and solid enough monitoring and alerting in place to otherwise detect and deal with a slow node. The dynamic snitch comes with its own overhead, and on healthy performant clusters can't keep up, so offers very little value. (Don't look past those caveats though!) If you have a problem with slow nodes, and don't have a way to deal with it, then the dynamic snitch is a good option, and adding the same ability to the batchlog makes sense. was (Author: michaelsembwever): [~shunsaker], do you want to share the patch you're willing to upstream ? This patch has had a lot of production exposure already, so it has my preference. [~maximc], are you ok if we focus on Shayne's patch ? I know you've done a lot of work already, and it sucks when you've completed a patch and it was the first patch offered. Given your expertise now, and not letting it go to waste, it would be very valuable to have you as a reviewer (and tester). bq. Michael Semb Wever and Maxim Chanturiay provide strong arguments against Dynamic snitch. This is not related to logged batch writes, and today the dynamic snitch does nothing for it anyway. The advice to disable the dynamic snitch has been a long standing recommendation from The Last Pickle, aimed at competent Cassandra operators that have healthy and performant clusters, and solid enough monitoring and alerting in place to otherwise detect and deal with a slow node. The dynamic snitch comes with its own overhead, and on healthy performant clusters can't keep up, so offers very little value. (Don't look past those caveats though!) If you have a problem with slow nodes, and don't have a way to deal with it, then the dynamic snitch is a good option, and adding the same ability to the batchlog adds to that. > Single slow node dramatically reduces cluster logged batch write throughput > regardless of CL > > > Key: CASSANDRA-18120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18120 > Project: Cassandra > Issue Type: Improvement >Reporter: Dan Sarisky >Assignee: Maxim Chanturiay >Priority: Normal > > We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, > QUORUM, or LOCAL_QUORUM) > > On clusters of any size - a single extremely slow node causes a ~90% loss of > cluster-wide throughput using batched writes. We can replicate this in the > lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1. > > It appears the mechanism in play is: > Those logged batches are immediately written to two replica nodes and the > actual mutations aren't processed until those two nodes acknowledge the batch > statements. Those replica nodes are selected randomly from all nodes in the > local data center currently up in gossip. If a single node is slow, but > still thought to be up in gossip, this eventually causes every other node to > have all of its MutationStages to be waiting while the slow replica accepts > batch writes. > > The code in play appears to be: > See > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245]. > In the method filterBatchlogEndpoints() there is a > Collections.shuffle() to order the endpoints and a > FailureDetector.isEndpointAlive() to test if the endpoint is acceptable. > > This behavior causes Cassandra to move from a multi-node fault tolerant > system toa collection of single points of failure. > > We try to take administrator actions to kill off the extremely slow nodes, > but it would be great to have some notion of "what node is a bad choice" when > writing log batches to replica nodes. > --
[jira] [Comment Edited] (CASSANDRA-18120) Single slow node dramatically reduces cluster logged batch write throughput regardless of CL
[ https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849074#comment-17849074 ] Michael Semb Wever edited comment on CASSANDRA-18120 at 5/23/24 6:38 PM: - [~shunsaker], do you want to share the patch you're willing to upstream ? That patch would have had a lot of production exposure already, so it would be my preference. [~maximc], are you ok if we focus on Shayne's patch ? I know you've done a lot of work already, and it sucks when you've completed a patch and it was the first patch offered. Given your expertise now, and not letting it go to waste, it would be very valuable to have you as a reviewer (and tester). bq. Michael Semb Wever and Maxim Chanturiay provide strong arguments against Dynamic snitch. This is not related to logged batch writes, and today the dynamic snitch does nothing for it anyway. The advice to disable the dynamic snitch has been a long standing recommendation from The Last Pickle, aimed at competent Cassandra operators that have healthy and performant clusters, and solid enough monitoring and alerting in place to otherwise detect and deal with a slow node. The dynamic snitch comes with its own overhead, and on healthy performant clusters can't keep up, so offers very little value. (Don't look past those caveats though!) If you have a problem with slow nodes, and don't have a way to deal with it, then the dynamic snitch is a good option, and adding the same ability to the batchlog makes sense. was (Author: michaelsembwever): [~shunsaker], do you want to share the patch you're willing to upstream ? This patch has had a lot of production exposure already, so it has my preference. [~maximc], are you ok if we focus on Shayne's patch ? I know you've done a lot of work already, and it sucks when you've completed a patch and it was the first patch offered. Given your expertise now, and not letting it go to waste, it would be very valuable to have you as a reviewer (and tester). bq. Michael Semb Wever and Maxim Chanturiay provide strong arguments against Dynamic snitch. This is not related to logged batch writes, and today the dynamic snitch does nothing for it anyway. The advice to disable the dynamic snitch has been a long standing recommendation from The Last Pickle, aimed at competent Cassandra operators that have healthy and performant clusters, and solid enough monitoring and alerting in place to otherwise detect and deal with a slow node. The dynamic snitch comes with its own overhead, and on healthy performant clusters can't keep up, so offers very little value. (Don't look past those caveats though!) If you have a problem with slow nodes, and don't have a way to deal with it, then the dynamic snitch is a good option, and adding the same ability to the batchlog makes sense. > Single slow node dramatically reduces cluster logged batch write throughput > regardless of CL > > > Key: CASSANDRA-18120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18120 > Project: Cassandra > Issue Type: Improvement >Reporter: Dan Sarisky >Assignee: Maxim Chanturiay >Priority: Normal > > We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, > QUORUM, or LOCAL_QUORUM) > > On clusters of any size - a single extremely slow node causes a ~90% loss of > cluster-wide throughput using batched writes. We can replicate this in the > lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1. > > It appears the mechanism in play is: > Those logged batches are immediately written to two replica nodes and the > actual mutations aren't processed until those two nodes acknowledge the batch > statements. Those replica nodes are selected randomly from all nodes in the > local data center currently up in gossip. If a single node is slow, but > still thought to be up in gossip, this eventually causes every other node to > have all of its MutationStages to be waiting while the slow replica accepts > batch writes. > > The code in play appears to be: > See > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245]. > In the method filterBatchlogEndpoints() there is a > Collections.shuffle() to order the endpoints and a > FailureDetector.isEndpointAlive() to test if the endpoint is acceptable. > > This behavior causes Cassandra to move from a multi-node fault tolerant > system toa collection of single points of failure. > > We try to take administrator actions to kill off the extremely slow nodes, > but it would be great to have some notion of "what node is a bad choice" when > writing log batches to replica nodes.
[jira] [Updated] (CASSANDRA-18120) Single slow node dramatically reduces cluster logged batch write throughput regardless of CL
[ https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18120: --- Summary: Single slow node dramatically reduces cluster logged batch write throughput regardless of CL (was: Single slow node dramatically reduces cluster write throughput regardless of CL) > Single slow node dramatically reduces cluster logged batch write throughput > regardless of CL > > > Key: CASSANDRA-18120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18120 > Project: Cassandra > Issue Type: Improvement >Reporter: Dan Sarisky >Assignee: Maxim Chanturiay >Priority: Normal > > We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, > QUORUM, or LOCAL_QUORUM) > > On clusters of any size - a single extremely slow node causes a ~90% loss of > cluster-wide throughput using batched writes. We can replicate this in the > lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1. > > It appears the mechanism in play is: > Those logged batches are immediately written to two replica nodes and the > actual mutations aren't processed until those two nodes acknowledge the batch > statements. Those replica nodes are selected randomly from all nodes in the > local data center currently up in gossip. If a single node is slow, but > still thought to be up in gossip, this eventually causes every other node to > have all of its MutationStages to be waiting while the slow replica accepts > batch writes. > > The code in play appears to be: > See > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245]. > In the method filterBatchlogEndpoints() there is a > Collections.shuffle() to order the endpoints and a > FailureDetector.isEndpointAlive() to test if the endpoint is acceptable. > > This behavior causes Cassandra to move from a multi-node fault tolerant > system toa collection of single points of failure. > > We try to take administrator actions to kill off the extremely slow nodes, > but it would be great to have some notion of "what node is a bad choice" when > writing log batches to replica nodes. > -- This message was sent by Atlassian Jira (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-18120) Single slow node dramatically reduces cluster write throughput regardless of CL
[ https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849074#comment-17849074 ] Michael Semb Wever commented on CASSANDRA-18120: [~shunsaker], do you want to share the patch you're willing to upstream ? This patch has had a lot of production exposure already, so it has my preference. [~maximc], are you ok if we focus on Shayne's patch ? I know you've done a lot of work already, and it sucks when you've completed a patch and it was the first patch offered. Given your expertise now, and not letting it go to waste, it would be very valuable to have you as a reviewer (and tester). bq. Michael Semb Wever and Maxim Chanturiay provide strong arguments against Dynamic snitch. This is not related to logged batch writes, and today the dynamic snitch does nothing for it anyway. The advice to disable the dynamic snitch has been a long standing recommendation from The Last Pickle, aimed at competent Cassandra operators that have healthy and performant clusters, and solid enough monitoring and alerting in place to otherwise detect and deal with a slow node. The dynamic snitch comes with its own overhead, and on healthy performant clusters can't keep up, so offers very little value. (Don't look past those caveats though!) If you have a problem with slow nodes, and don't have a way to deal with it, then the dynamic snitch is a good option, and adding the same ability to the batchlog adds to that. > Single slow node dramatically reduces cluster write throughput regardless of > CL > --- > > Key: CASSANDRA-18120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18120 > Project: Cassandra > Issue Type: Improvement >Reporter: Dan Sarisky >Assignee: Maxim Chanturiay >Priority: Normal > > We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, > QUORUM, or LOCAL_QUORUM) > > On clusters of any size - a single extremely slow node causes a ~90% loss of > cluster-wide throughput using batched writes. We can replicate this in the > lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1. > > It appears the mechanism in play is: > Those logged batches are immediately written to two replica nodes and the > actual mutations aren't processed until those two nodes acknowledge the batch > statements. Those replica nodes are selected randomly from all nodes in the > local data center currently up in gossip. If a single node is slow, but > still thought to be up in gossip, this eventually causes every other node to > have all of its MutationStages to be waiting while the slow replica accepts > batch writes. > > The code in play appears to be: > See > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245]. > In the method filterBatchlogEndpoints() there is a > Collections.shuffle() to order the endpoints and a > FailureDetector.isEndpointAlive() to test if the endpoint is acceptable. > > This behavior causes Cassandra to move from a multi-node fault tolerant > system toa collection of single points of failure. > > We try to take administrator actions to kill off the extremely slow nodes, > but it would be great to have some notion of "what node is a bad choice" when > writing log batches to replica nodes. > -- This message was sent by Atlassian Jira (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-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848709#comment-17848709 ] Michael Semb Wever edited comment on CASSANDRA-19556 at 5/22/24 8:00 PM: - bq. it is removing alter_table_enabled guardrail. We can deprecate alter_table_enabled in 5.0.1 If I'm reading all comments correctly, it seems the right approach is this ticket waits til 5.0.0 is released, and then introduces the system property in 4.0, 4.1, 5.0 branches, deprecates alter_table_enabled in cassandra-5.0, and applies the current patch to trunk. was (Author: michaelsembwever): bq. it is removing alter_table_enabled guardrail. We can deprecate alter_table_enabled in 5.0.1 If I'm reading all comments correctly, it seems the right approach is this ticket waits til 5.0.0 is released, and then introduces the system property in Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (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-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848709#comment-17848709 ] Michael Semb Wever commented on CASSANDRA-19556: bq. it is removing alter_table_enabled guardrail. We can deprecate alter_table_enabled in 5.0.1 If I'm reading all comments correctly, it seems the right approach is this ticket waits til 5.0.0 is released, and then introduces the system property in Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (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-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19650:
---
Discovered By: DTest (was: User Report)
Fix Version/s: 3.0.x
3.11.x
4.0.x
4.1.x
(was: NA)
Severity: Normal (was: Low)
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(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-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848505#comment-17848505
]
Michael Semb Wever commented on CASSANDRA-19650:
In addition, CASSANDRA-19636 appears to have broken jdk-switching
(upgrade_through_versions) when, after an upgrade and jdk-switch, a new node is
added that relies on a jdk-switch.
The following logging shows a four node cluster starting up using jdk8 (from
matching $PATH and $JAVA_HOME) on 4.1.6. It then switch all four nodes to
jdk11 (using $JAVA11_HOME) and 5.0. But when it tries to add the 5th node (on
jdk11 and 5.0) it suddenly fails.
{noformat}
upgrade_tests/upgrade_through_versions_test.py::TestUpgrade_indev_4_1_x_To_indev_5_0_x::test_bootstrap_multidc
…
21:00:02,930 ccm INFO Supported Java versions for Cassandra distribution in
'/parallel-ci/work/.ccm/repository/githubCOLONapacheSLASHcassandra-4.1': None
21:00:03,64 ccm INFO node1: Using the current Java 8 available on PATH for the
current invocation of Cassandra 4.1.6.
21:00:03,153 ccm INFO Supported Java versions for Cassandra distribution in
'/parallel-ci/work/.ccm/repository/githubCOLONapacheSLASHcassandra-4.1': None
21:00:03,284 ccm INFO node1: Using the current Java 8 available on PATH for the
current invocation of Cassandra 4.1.6.
21:00:03,333 ccm INFO Starting node1 with
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 java_version=8
cassandra_version=4.1.6,
install_dir=/parallel-ci/work/.ccm/repository/githubCOLONapacheSLASHcassandra-4.1
21:00:08,458 ccm INFO Supported Java versions for Cassandra distribution in
'/parallel-ci/work/.ccm/repository/githubCOLONapacheSLASHcassandra-4.1': None
21:00:08,595 ccm INFO node2: Using the current Java 8 available on PATH for the
current invocation of Cassandra 4.1.6.
21:00:08,707 ccm INFO Supported Java versions for Cassandra distribution in
'/parallel-ci/work/.ccm/repository/githubCOLONapacheSLASHcassandra-4.1': None
21:00:08,841 ccm INFO node2: Using the current Java 8 available on PATH for the
current invocation of Cassandra 4.1.6.
21:00:08,889 ccm INFO Starting node2 with
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 java_version=8
cassandra_version=4.1.6,
install_dir=/parallel-ci/work/.ccm/repository/githubCOLONapacheSLASHcassandra-4.1
21:00:23,522 ccm INFO Supported Java versions for Cassandra distribution in
'/parallel-ci/work/.ccm/repository/githubCOLONapacheSLASHcassandra-4.1': None
21:00:23,657 ccm INFO node3: Using the current Java 8 available on PATH for the
current invocation of Cassandra 4.1.6.
21:00:23,756 ccm INFO Supported Java versions for Cassandra distribution in
'/parallel-ci/work/.ccm/repository/githubCOLONapacheSLASHcassandra-4.1': None
21:00:23,901 ccm INFO node3: Using the current Java 8 available on PATH for the
current invocation of Cassandra 4.1.6.
21:00:23,947 ccm INFO Starting node3 with
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 java_version=8
cassandra_version=4.1.6,
install_dir=/parallel-ci/work/.ccm/repository/githubCOLONapacheSLASHcassandra-4.1
21:00:38,573 ccm INFO Supported Java versions for Cassandra distribution in
'/parallel-ci/work/.ccm/repository/githubCOLONapacheSLASHcassandra-4.1': None
21:00:38,707 ccm INFO node4: Using the current Java 8 available on PATH for the
current invocation of Cassandra 4.1.6.
21:00:38,803 ccm INFO Supported Java versions for Cassandra distribution in
'/parallel-ci/work/.ccm/repository/githubCOLONapacheSLASHcassandra-4.1': None
21:00:38,931 ccm INFO node4: Using the current Java 8 available on PATH for the
current invocation of Cassandra 4.1.6.
21:00:38,978 ccm INFO Starting node4 with
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 java_version=8
cassandra_version=4.1.6,
install_dir=/parallel-ci/work/.ccm/repository/githubCOLONapacheSLASHcassandra-4.1
…
21:02:18,416 ccm INFO Supported Java versions for Cassandra distribution in
'/parallel-ci/work/.ccm/repository/githubCOLONapacheSLASHcassandra-5.0': [11,
17]
21:02:18,556 ccm WARNING node1: The current Java 8 is not supported by
Cassandra 5.0 (supported versions: [11, 17]).
21:02:18,557 ccm INFO node1: CCM has found {17: 'JAVA17_HOME', 8: 'JAVA_HOME',
11: 'JAVA11_HOME'} Java distributions, the required Java version for Cassandra
5.0 is [11, 17].
…
FAILED
{noformat}
ref: https://pastebin.com/JfGziJHh
[~aweisberg], have you been able to provide steps to reproduce this ?
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: NA
>
>
> CCM interprets
[jira] [Commented] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848503#comment-17848503
]
Michael Semb Wever commented on CASSANDRA-19650:
All CI, all branches before 5, is currently broken because of CASSANDRA-19636
Specifically the cqlsh ({{`pylib/cassandra-cqlsh-tests.sh`}}) tests.
{noformat}
18:29:42 + ccm create test -n 1 --install-dir=/home/cassandra/cassandra
18:29:43 Current cluster is now: test
18:29:43 16:29:43,74 ccm DEBUG using balanced tokens for non-vnode cluster
18:29:43 + ccm updateconf 'user_defined_functions_enabled: true'
18:29:44 + ccm updateconf 'scripted_user_defined_functions_enabled: true'
18:29:44 ++ ccm node1 versionfrombuild
18:29:44 + version_from_build=4.1.6
18:29:44 ++ python -c 'from distutils.version import LooseVersion
18:29:44 print ("postcdc" if LooseVersion("4.1.6") >= "3.8" else "precdc")
18:29:44 '
18:29:45 :2: DeprecationWarning: distutils Version classes are
deprecated. Use packaging.version instead.
18:29:45 + export pre_or_post_cdc=postcdc
18:29:45 + pre_or_post_cdc=postcdc
18:29:45 + case "${pre_or_post_cdc}" in
18:29:45 + ccm updateconf 'cdc_enabled: true'
18:29:45 + ccm start --wait-for-binary-proto
18:29:46 16:29:46,124 ccm INFO Supported Java versions for Cassandra
distribution in '/home/cassandra/cassandra': None
18:29:46 16:29:46,186 ccm WARNING node1: The current Java 8 is not supported by
Cassandra 4.1.6 (supported versions: [11]).
18:29:46 Traceback (most recent call last):
18:29:46 File "/home/cassandra/cassandra/venv/bin/ccm", line 7, in
18:29:46 exec(compile(f.read(), __file__, 'exec'))
18:29:46 File "/home/cassandra/cassandra/venv/src/ccm/ccm", line 112, in
18:29:46 cmd.run()
18:29:46 File
"/home/cassandra/cassandra/venv/src/ccm/ccmlib/cmds/cluster_cmds.py", line 513,
in run
18:29:46 if self.cluster.start(no_wait=self.options.no_wait,
18:29:46 File "/home/cassandra/cassandra/venv/src/ccm/ccmlib/cluster.py",
line 526, in start
18:29:46 p = node.start(update_pid=False, jvm_args=jvm_args,
jvm_version=jvm_version,
18:29:46 File "/home/cassandra/cassandra/venv/src/ccm/ccmlib/node.py", line
820, in start
18:29:46 env = self.get_env()
18:29:46 File "/home/cassandra/cassandra/venv/src/ccm/ccmlib/node.py", line
240, in get_env
18:29:46 env = common.update_java_version(jvm_version=None,
18:29:46 File "/home/cassandra/cassandra/venv/src/ccm/ccmlib/common.py", line
960, in update_java_version
18:29:46 return _update_java_version(current_java_version,
current_java_home_version,
18:29:46 File "/home/cassandra/cassandra/venv/src/ccm/ccmlib/common.py", line
1031, in _update_java_version
18:29:46 raise RuntimeError('{}: Cannot find any Java distribution for the
current invocation. Available Java distributions: {}, required Java
distributions: {}'
18:29:46 RuntimeError: node1: Cannot find any Java distribution for the current
invocation. Available Java distributions: {8: 'JAVA_HOME'}, required Java
distributions: [11]
{noformat}
Ref:
- https://ci-cassandra.apache.org/job/Cassandra-4.1-cqlsh-tests/435/
-
https://nightlies.apache.org/cassandra/cassandra-4.1/Cassandra-4.1-cqlsh-tests/435/Cassandra-4.1-cqlsh-tests/cython=no,jdk=jdk_1.8_latest,label=cassandra/
This is because it was expecting {{`CASSANDRA_USE_JDK11=false`}} to work. It
never did, but before 19636 was being ignored.
Ref:
https://github.com/apache/cassandra/blob/cassandra-4.1/pylib/cassandra-cqlsh-tests.sh#L47
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: NA
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(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-12864) "commitlog_sync_batch_window_in_ms" parameter is not documented correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-12864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848377#comment-17848377 ] Michael Semb Wever edited comment on CASSANDRA-12864 at 5/21/24 9:29 PM: - In addition, the page has a number of faults that should be corrected: - the default is periodic, - there's an odd '(Default Value: (complex option): ' section (maybe this is just asciidoc ?) - the sentence "Any data written to Cassandra will first be written to a commit log before being written to a memtable." isn't strictly-speaking correct, the commitlog and the memtable happen in parallel… And, it would be worthwhile if the page referenced, for more advanced info, this [blog post|https://cassandra.apache.org/_/blog/Learn-How-CommitLog-Works-in-Apache-Cassandra.html] these pages are now found at - https://cassandra.apache.org/doc/3.11/cassandra/architecture/storage_engine.html#commit-log - https://cassandra.apache.org/doc/4.0/cassandra/architecture/storage_engine.html#commit-log - https://cassandra.apache.org/doc/4.1/cassandra/architecture/storage_engine.html#commit-log - https://cassandra.apache.org/doc/5.0/cassandra/architecture/storage-engine.html - https://cassandra.apache.org/doc/5.1/cassandra/architecture/storage-engine.html - https://cassandra.apache.org/doc/latest/cassandra/architecture/storage-engine.html was (Author: michaelsembwever): In addition, the page has a number of faults that should be corrected: - the default is periodic, - there's an odd '(Default Value: (complex option): ' section (maybe this is just asciidoc ?) - the sentence "Any data written to Cassandra will first be written to a commit log before being written to a memtable." isn't strictly-speaking correct, the commitlog and the memtable happen in parallel… And, it would be worthwhile if the page referenced, for more advanced info, this [blog post|https://cassandra.apache.org/_/blog/Learn-How-CommitLog-Works-in-Apache-Cassandra.html] > "commitlog_sync_batch_window_in_ms" parameter is not documented correctly > - > > Key: CASSANDRA-12864 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12864 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Hiroyuki Yamada >Priority: Normal > > "commitlog_sync_batch_window_in_ms" doesn't seem to be working at least in > the latest versions in 2.1.16, 2.2.8 and 3.9. > Here is the way to reproduce the bug. > 1. set the following parameters in cassandra.yaml > * commitlog_sync: batch > * commitlog_sync_batch_window_in_ms: 1 (10s) > 2. issue an insert from cqlsh > 3. it immediately returns instead of waiting for 10 seconds. > Please refer to the communication in the mailing list. > http://www.mail-archive.com/user@cassandra.apache.org/msg49642.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] [Commented] (CASSANDRA-12864) "commitlog_sync_batch_window_in_ms" parameter is not documented correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-12864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848377#comment-17848377 ] Michael Semb Wever commented on CASSANDRA-12864: In addition, the page has a number of faults that should be corrected: - the default is periodic, - there's an odd '(Default Value: (complex option): ' section (maybe this is just asciidoc ?) - the sentence "Any data written to Cassandra will first be written to a commit log before being written to a memtable." isn't strictly-speaking correct, the commitlog and the memtable happen in parallel… And, it would be worthwhile if the page referenced, for more advanced info, this [blog post|https://cassandra.apache.org/_/blog/Learn-How-CommitLog-Works-in-Apache-Cassandra.html] > "commitlog_sync_batch_window_in_ms" parameter is not documented correctly > - > > Key: CASSANDRA-12864 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12864 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Hiroyuki Yamada >Priority: Normal > > "commitlog_sync_batch_window_in_ms" doesn't seem to be working at least in > the latest versions in 2.1.16, 2.2.8 and 3.9. > Here is the way to reproduce the bug. > 1. set the following parameters in cassandra.yaml > * commitlog_sync: batch > * commitlog_sync_batch_window_in_ms: 1 (10s) > 2. issue an insert from cqlsh > 3. it immediately returns instead of waiting for 10 seconds. > Please refer to the communication in the mailing list. > http://www.mail-archive.com/user@cassandra.apache.org/msg49642.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-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19650:
---
Reviewers: Michael Semb Wever, Michael Semb Wever
Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever)
Status: Review In Progress (was: Patch Available)
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: NA
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(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-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847941#comment-17847941 ] Michael Semb Wever edited comment on CASSANDRA-19556 at 5/20/24 5:12 PM: - [~samt], I'm interested in hearing where you're at on this… This issue is not a 5.0-rc blocker, but if it is ready to be committed, and there's an important enough reason to commit it for the sake of upgrading to tcm, then that's our argument to present. It's also worth pointing out that trunk is still for now 5.1, so upgrades from 4.0 and 4.1 to tcm would still be possible too. My general sentiment remains we're way past the gate for this patch, our normal deprecation cycle suffices and we shouldn't be afraid of adding what feels like duplication… [~smiklosovic], it's still time-consuming having to scan the comments every time to figure out which patch is "Ready to Commit". Can we please keep the links section up to date. This makes the ticket not "super simple", which would help put at ease any new reviewers… was (Author: michaelsembwever): [~samt], I'm interested in hearing where you're at on this… This issue is not a 5.0-rc blocker, but if it is ready to be committed, and there's an important enough reason to commit it for the sake of upgrading to tcm, then that's our argument to present. It's also worth pointing out that trunk is still for now 5.1, so upgrades from 4.0 and 4.1 to tcm would still be possible too. My general sentiment remains we're way past the gate for this, our normal deprecation suffices and we shouldn't be afraid of adding what feels like duplication… [~smiklosovic], it's still time-consuming having to scan the comments every time to figure out which patch is "Ready to Commit". Can we please keep the links section up to date. This makes the ticket not "super simple", which would help put at ease any new reviewers… > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (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-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847941#comment-17847941 ] Michael Semb Wever commented on CASSANDRA-19556: [~samt], I'm interested in hearing where you're at on this… This issue is not a 5.0-rc blocker, but if it is ready to be committed, and there's an important enough reason to commit it for the sake of upgrading to tcm, then that's our argument to present. It's also worth pointing out that trunk is still for now 5.1, so upgrades from 4.0 and 4.1 to tcm would still be possible too. My general sentiment remains we're way past the gate for this, our normal deprecation suffices and we shouldn't be afraid of adding what feels like duplication… [~smiklosovic], it's still time-consuming having to scan the comments every time to figure out which patch is "Ready to Commit". Can we please keep the links section up to date. This makes the ticket not "super simple", which would help put at ease any new reviewers… > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (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-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845315#comment-17845315 ] Michael Semb Wever edited comment on CASSANDRA-19556 at 5/20/24 5:00 PM: - please, let's not include this in 5.0.0, we are long past the appropriate release lifecycle phase to be including new features. if we think this is appropriate to include in a 5.0.1, could we then be a hold on this until after 5.0.0 is out …? (personally i see no reason this needs to be in any 5.0.x) was (Author: michaelsembwever): please, let's not include this in 5.0, we are long past the appropriate release lifecycle phase to be including new features. if we think this is appropriate to include in a 5.0.1, could we then be a hold on this until after 5.0.0 is out …? (personally i see no reason this needs to be in any 5.0.x) > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (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-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=17847641#comment-17847641
]
Michael Semb Wever edited comment on CASSANDRA-16364 at 5/19/24 8:17 AM:
-
bq. Maybe that's what you mean by "hacky"?
I only meant a clever fix that's not aligned with the intended design and
approach. Hacks are great IMHO if contained, but here with breaking the
determinism it won't be
was (Author: michaelsembwever):
bq. Maybe that's what you mean by "hacky"?
I only meant a clever fix that's not aligned with the intended design and
approach. Hacks are great IMHO if contained, but here breaking the determinism
won't be
> 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] [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=17847641#comment-17847641
]
Michael Semb Wever commented on CASSANDRA-16364:
bq. Maybe that's what you mean by "hacky"?
I only meant a clever fix that's not aligned with the intended design and
approach. Hacks are great IMHO if contained, but here breaking the determinism
won't be
> 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] [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=17847494#comment-17847494
]
Michael Semb Wever commented on CASSANDRA-16364:
Backing up [~jjordan]'s statement, token allocation is designed to be
deterministic, and we don't support simultaneous bootstraps.
Seems the fault to fix here is preventing/detecting this problem as early as
possible (and better docs) per the original description of the ticket. 100%
agree that the feature can and should be made safer.Changing the design to
non-deterministic may work but is hacky, inappropriate in patch versions and
i'm sure will introduce breakages (/more work) elsewhere given our assumptions
on the design.
Does this apply in trunk with tcm? Think we should be removing fixVersion 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, 5.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] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847040#comment-17847040 ] Michael Semb Wever commented on CASSANDRA-19556: CASSANDRA-19534 is a bug, it's not the same thing. We have _effectively_ been in rc mode for months now (chasing that "last" rc blocker, again and again…). Furthermore, we have defined our [release lifecycle doc|https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle] so to avoid changes like this once beta1 is released. Sam's argument above is the crux for me. If we see this as critical to do in 5.0.0 (and not 5.0.1) for 5.1/5.0 then let's explain that as the waiver. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (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-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846989#comment-17846989 ] Michael Semb Wever commented on CASSANDRA-18712: Upgrading these dependencies repeatedly is a PITA – you have to make sure they're compatible with each other, have a clean transitive tree with no conflicts, all found in public repos, all found in the bom, and ideally not early-access versions. But we do want to encourage s390x work, or it'll never have any chance of being _officially accepted_. [~Nayana], how difficult it is for you to continue your s390x work having to manually re-apply this patch…? bq. I checked that the versions match the versions in the bom. Which bom version ? (link please) bq. there is not any "not early access" of 2.24, they stopped with 2.24ea28 and next one was 2.25ea0. 2.24 releases do exist, ref: https://github.com/OpenHFT/Chronicle-Bytes/releases/tag/chronicle-bytes-2.24.29. And the bom in repo1 has them ( https://repo1.maven.org/maven2/net/openhft/chronicle-bom/ ) but I've no idea about where the other 2.24 releases are to be found in public maven repos. We can build and deploy them to https://repository.apache.org/content/groups/public/ if we really want to… > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846964#comment-17846964
]
Michael Semb Wever edited comment on CASSANDRA-19636 at 5/16/24 1:59 PM:
-
+1 to the patch. we just need CI for (some) <5 branches.
(EDIT: didn't see Ariel's comment, not overriding it)
was (Author: michaelsembwever):
+1 to the patch. we just need CI for (some) <5 branches.
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846964#comment-17846964
]
Michael Semb Wever commented on CASSANDRA-19636:
+1 to the patch. we just need CI for (some) <5 branches.
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846945#comment-17846945
]
Michael Semb Wever commented on CASSANDRA-19636:
CI
- 5.0
[^CASSANDRA-19636_50_75_ci_summary.html] ,
[^CASSANDRA-19636_50_75_results_details.tar.xz]
- trunk
[^CASSANDRA-19636_trunk_76_ci_summary.html] ,
[^CASSANDRA-19636_trunk_76_results_details.tar.xz]
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19636:
---
Attachment: CASSANDRA-19636_trunk_76_ci_summary.html
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19636:
---
Attachment: CASSANDRA-19636_trunk_76_results_details.tar.xz
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19636:
---
Attachment: CASSANDRA-19636_50_75_ci_summary.html
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19636:
---
Reviewers: Michael Semb Wever, Michael Semb Wever
Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever)
Status: Review In Progress (was: Patch Available)
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19636:
---
Attachment: CASSANDRA-19636_50_75_results_details.tar.xz
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19489) Guardrail to warn clients about possible transient incorrect responses for filtering queries against multiple mutable columns
[ https://issues.apache.org/jira/browse/CASSANDRA-19489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19489: --- Fix Version/s: 5.0-beta2 5.0 (was: 5.0.x) > Guardrail to warn clients about possible transient incorrect responses for > filtering queries against multiple mutable columns > - > > Key: CASSANDRA-19489 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19489 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, CQL/Semantics, Messaging/Client >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 5.0-beta2, 5.0, 5.1 > > Attachments: ci_summary-1.html, ci_summary.html > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Given we may not have time to fully resolve CASSANDRA-19007 before we release > 5.0, it would still be helpful to have, at the very minimum, a client warning > for cases where a user filters on two or more mutable (static or regular) > columns at consistency levels that require coordinator reconciliation. We may > also want the option to fail these queries outright, although that need not > be the default. > The only art involved in this is deciding what we want to say in the > warning/error message. It's probably reasonable to mention there that this > only happens when we have unrepaired data. It's also worth noting that SAI > queries are no longer vulnerable to this after the resolution of > CASSANDRA-19018. -- This message was sent by Atlassian Jira (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-18714) Expand CQLSSTableWriter to write SSTable-attached secondary indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-18714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18714:
---
Fix Version/s: 5.0-beta2
5.0
5.1
(was: 5.x)
(was: 5.0-rc)
> Expand CQLSSTableWriter to write SSTable-attached secondary indexes
> ---
>
> Key: CASSANDRA-18714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18714
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI, Tool/bulk load
>Reporter: Caleb Rackliffe
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-beta2, 5.0, 5.1
>
> Attachments: client-mode-cqlsstablewriter-tests.patch
>
> Time Spent: 14h
> Remaining Estimate: 0h
>
> {{CQLSSTableWriter}} currently has no way of writing any secondary indexes
> inline as it writes the core SSTable components. With SAI, this has become
> tractable problem, and we should be able to enhance both it and
> {{SSTableImporter}} to handle cases where we might want to write SSTables
> somewhere in bulk (and in parallel) and then import them without waiting for
> index building on import. It would require the following changes:
> 1.) {{CQLSSTableWriter}} must accept 2i definitions on top of its current
> table schema definition. Once added to the schema, any {{ColumnFamilyStore}}
> instances opened will have those 2i defined in their index managers.
> 2.) All {{AbstractSSTableSimpleWriter}} instances must register index groups,
> allowing the proper {{SSTableFlushObservers}} to be attached to
> {{SSTableWriter}}. Once this is done, SAI (and any other SSTable-attached
> indexes) components will be built incrementally along w/ the SSTable data
> file, and will be finalized when the newly written SSTable is finalized.
> 3.) Provide an example (in a unit test?) of how a third-party tool might,
> assuming access to the right C* JAR, validate/checksum SAI components outside
> C* proper.
> 4.) {{SSTableImporter}} should have two new options:
> a.) an option that fails import if any SSTable-attached 2i must be built
> (i.e. has not already been built and brought along w/ the other new SSTable
> components)
> b.) an option that allows us to bypass full checksum validation on
> imported/already-built SSTable-attached indexes (assuming they have just been
> written by {{CQLSSTableWriter}})
--
This message was sent by Atlassian Jira
(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-18753) Add an optimized default configuration to tests and make it available for new users
[
https://issues.apache.org/jira/browse/CASSANDRA-18753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18753:
---
Fix Version/s: 5.0-beta2
5.0
5.1
(was: 5.x)
(was: 5.0-rc)
> Add an optimized default configuration to tests and make it available for new
> users
> ---
>
> Key: CASSANDRA-18753
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18753
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
>Priority: Urgent
> Fix For: 5.0-beta2, 5.0, 5.1
>
> Attachments:
> CCM_Add_support_for_specifying_the_name_of_the_file_to_use_as_cassandra_YAML_.patch,
>
> DTEST_Add_support_for_specifying_the_name_of_the_file_to_use_as_cassandra_YAML_.patch
>
> Time Spent: 12h 20m
> Remaining Estimate: 0h
>
> We currently offer only one sample configuration file with Cassandra, and
> that file is deliberately configured to disable all new functionality and
> incompatible improvements. This works well for legacy users that want to have
> a painless upgrade, but is a very bad choice for new users, or anyone wanting
> to make comparisons between Cassandra versions or between Cassandra and other
> databases.
> We offer very little indication, in the database packaging itself, that there
> are well-tested configuration choices that can solve known problems and
> dramatically improve performance. This is guaranteed to paint the database in
> a worse light than it deserves, and will very likely hurt adoption.
> We should find a way to offer a very easy way of choosing between "optimized"
> and "compatible" defaults. At minimal, we could provide alternate yaml files.
> Alternatively, we could build on the {{storage_compatibility_mode}} concept
> to grow it into a setting that not only enables/disables certain settings,
> but also changes their default values.
--
This message was sent by Atlassian Jira
(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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19428: --- Fix Version/s: 5.0 (was: 5.1-alpha) > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-beta2, 5.0, 5.1 > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- This message was sent by Atlassian Jira (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-19414) Skinny dev circle workflow
[ https://issues.apache.org/jira/browse/CASSANDRA-19414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19414: --- Fix Version/s: 5.0-beta2 5.0 5.1 (was: 5.x) (was: 5.0-rc) > Skinny dev circle workflow > -- > > Key: CASSANDRA-19414 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19414 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0-beta2, 5.0, 5.1 > > > CircleCi CI runs are getting pretty heavy. During dev iterations we trigger > many CI pre-commit jobs which are just an overkill. > This ticket has the purpose to purge from the pre-commit workflow all > variations of the test matrix but the vanilla one. That should enable us for > a quick and cheap to iterate *during dev*, this is not a substitute for > pre-commit . This ticket's work will serve as the basis for the upcoming > changes being discussed > [atm|https://lists.apache.org/thread/qf5c3hhz6qkpyqvbd3sppzlmftlc0bw0] -- This message was sent by Atlassian Jira (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-18673) Reduce size of per-SSTable index components
[ https://issues.apache.org/jira/browse/CASSANDRA-18673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18673: --- Fix Version/s: 5.0 > Reduce size of per-SSTable index components > --- > > Key: CASSANDRA-18673 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18673 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Urgent > Fix For: 5.0-alpha1, 5.0, 5.1 > > Time Spent: 6.5h > Remaining Estimate: 0h > > The current per-SSTable index components are large because the primary keys > that are stored in them include the token as part of the byte comparable. The > byte comparable puts the token first meaning that we get very little prefix > compression from either the trie or the sorted terms store. > We can fix this by removing the token from the primary key serialization. > This would allow us to get the prefix compression from the trie and the > sorted terms store. -- This message was sent by Atlassian Jira (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-18970) Cut ASF releases for cassandra-java-driver 3.x and 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-18970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794740#comment-17794740
]
Michael Semb Wever edited comment on CASSANDRA-18970 at 5/14/24 2:57 PM:
-
The 4.x branch is correctly set up now wrt ASF licenses and releases
(CASSANDRA-18969).
Cutting release for 4.x manually with
{code}
mvn release:prepare
mvn release:perform
svn mkdir -m "Cassandra Java Driver 4.18.0" \
https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver
svn co https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver
cp distribution-source/target/*.tar.* cassandra-java-driver/
cp distribution/target/*.tar.* cassandra-java-driver/
rm cassandra-java-driver/*.asc.*
svn add cassandra-java-driver/*
svn ci -m "Cassandra Java Driver 4.18.0" cassandra-java-driver
{code}
(note, the version number directory under cassandra-java-driver/ is missing.
but you get the jist…)
was (Author: michaelsembwever):
The 4.x branch is correctly set up now wrt ASF licenses and releases
(CASSANDRA-18969).
Cutting release for 4.x manually with
{code}
mvn release:prepare
mvn release:perform
svn mkdir -m "Cassandra Java Driver 4.18.0" \
https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver
svn co https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver
cp distribution-source/target/*.tar.* cassandra-java-driver/
cp distribution/target/*.tar.* cassandra-java-driver/
rm cassandra-java-driver/*.asc.*
svn add cassandra-java-driver/*
svn ci -m "Cassandra Java Driver 4.18.0" cassandra-java-driver
{code}
> Cut ASF releases for cassandra-java-driver 3.x and 4.x
> --
>
> Key: CASSANDRA-18970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18970
> Project: Cassandra
> Issue Type: Sub-task
> Components: Client/java-driver
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
--
This message was sent by Atlassian Jira
(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-18970) Cut ASF releases for cassandra-java-driver 3.x and 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-18970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794740#comment-17794740
]
Michael Semb Wever edited comment on CASSANDRA-18970 at 5/14/24 2:57 PM:
-
The 4.x branch is correctly set up now wrt ASF licenses and releases
(CASSANDRA-18969).
Cutting release for 4.x manually with
{code}
mvn release:prepare
mvn release:perform
svn mkdir -m "Cassandra Java Driver 4.18.0" \
https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver
svn co https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver
cp distribution-source/target/*.tar.* cassandra-java-driver/
cp distribution/target/*.tar.* cassandra-java-driver/
rm cassandra-java-driver/*.asc.*
svn add cassandra-java-driver/*
svn ci -m "Cassandra Java Driver 4.18.0" cassandra-java-driver
{code}
(note, the version number directory under cassandra-java-driver/ is missing.
but you get the jist… see
https://dist.apache.org/repos/dist/release/cassandra/cassandra-java-driver/ for
it ends up looking)
was (Author: michaelsembwever):
The 4.x branch is correctly set up now wrt ASF licenses and releases
(CASSANDRA-18969).
Cutting release for 4.x manually with
{code}
mvn release:prepare
mvn release:perform
svn mkdir -m "Cassandra Java Driver 4.18.0" \
https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver
svn co https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver
cp distribution-source/target/*.tar.* cassandra-java-driver/
cp distribution/target/*.tar.* cassandra-java-driver/
rm cassandra-java-driver/*.asc.*
svn add cassandra-java-driver/*
svn ci -m "Cassandra Java Driver 4.18.0" cassandra-java-driver
{code}
(note, the version number directory under cassandra-java-driver/ is missing.
but you get the jist…)
> Cut ASF releases for cassandra-java-driver 3.x and 4.x
> --
>
> Key: CASSANDRA-18970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18970
> Project: Cassandra
> Issue Type: Sub-task
> Components: Client/java-driver
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
--
This message was sent by Atlassian Jira
(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-18970) Cut ASF releases for cassandra-java-driver 3.x and 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-18970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794740#comment-17794740
]
Michael Semb Wever edited comment on CASSANDRA-18970 at 5/14/24 2:42 PM:
-
The 4.x branch is correctly set up now wrt ASF licenses and releases
(CASSANDRA-18969).
Cutting release for 4.x manually with
{code}
mvn release:prepare
mvn release:perform
svn mkdir -m "Cassandra Java Driver 4.18.0" \
https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver
svn co https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver
cp distribution-source/target/*.tar.* cassandra-java-driver/
cp distribution/target/*.tar.* cassandra-java-driver/
rm cassandra-java-driver/*.asc.*
svn add cassandra-java-driver/*
svn ci -m "Cassandra Java Driver 4.18.0" cassandra-java-driver
{code}
was (Author: michaelsembwever):
The 4.x branch is correctly set up now wrt ASF licenses and releases
(CASSANDRA-18969).
Cutting release for 4.x manually with
{code}
mvn release:prepare
mvn release:perform
svn mkdir -m "Cassandra Java Driver 4.18.0"
https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver
svn co https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver
cp distribution-source/target/*.tar.* cassandra-java-driver/
cp distribution/target/*.tar.* cassandra-java-driver/
rm cassandra-java-driver/*.asc.*
svn add cassandra-java-driver/*
svn ci -m "Cassandra Java Driver 4.18.0" cassandra-java-driver
{code}
> Cut ASF releases for cassandra-java-driver 3.x and 4.x
> --
>
> Key: CASSANDRA-18970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18970
> Project: Cassandra
> Issue Type: Sub-task
> Components: Client/java-driver
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
--
This message was sent by Atlassian Jira
(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-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846101#comment-17846101 ] Michael Semb Wever edited comment on CASSANDRA-18106 at 5/13/24 10:22 PM: -- We weren't running dtest-upgrade-large tests at all, so there was no need for jdk switching. (We'd forgotten about the --intensive flag on upgrade tests.) The tests in question are doing multi-step upgrades. (We don't recommend upgrading and switching jdk at the same time, here the absolutely correct thing for the tests to be doing is upgrading and then restarting to switch jdk, but that's kinda overkill.) Are these tests really testing something that is persisted (serialised), i.e. something that happens in 3.0 that persists and isn't a problem until two major version later in 5.0 ? That sounds more like serialisation tests (that don't even need to be upgrade tests). ccm still supports jdk switching with JAVAx_HOME env vars, so if we need to we can still introduce these vars carefully for just these particular tests found in dtest-upgrade-large. (i.e. there's no change to undo here, we're still moving forward to a cleaner place…) was (Author: michaelsembwever): We weren't running dtest-upgrade-large tests at all, so there was no need for jdk switching. (We'd forgotten about the --intensive flag on upgrade tests.) The tests in question are doing multi-step upgrades. (We don't recommend upgrading and switching jdk at the same time, here the absolutely correct thing for the tests to be doing is upgrading and then restarting to switch jdk, but that's kinda overkill.) Are these tests really testing something that is persisted (serialised), i.e. something that happens in 3.0 that persists and isn't a problem until two major version later in 5.0 ? That sounds more like serialisation tests (that don't even need to be upgrade tests). ccm still supports jdk switching with JAVAx_HOME env vars, so if we need to we can still introduce these vars carefully for just these particular tests found in dtest-upgrade-large. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (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-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846101#comment-17846101 ] Michael Semb Wever commented on CASSANDRA-18106: We weren't running dtest-upgrade-large tests at all, so there was no need for jdk switching. (We'd forgotten about the --intensive flag on upgrade tests.) The tests in question are doing multi-step upgrades. (We don't recommend upgrading and switching jdk at the same time, here the absolutely correct thing for the tests to be doing is upgrading and then restarting to switch jdk, but that's kinda overkill.) Are these tests really testing something that is persisted (serialised), i.e. something that happens in 3.0 that persists and isn't a problem until two major version later in 5.0 ? That sounds more like serialisation tests (that don't even need to be upgrade tests). ccm still supports jdk switching with JAVAx_HOME env vars, so if we need to we can still introduce these vars carefully for just these particular tests found in dtest-upgrade-large. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (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-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846069#comment-17846069
]
Michael Semb Wever commented on CASSANDRA-18106:
We do have tests that need to change jdks. The dtest-upgrade-large* test types
have tests like
{{upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD}}
These types multi-step through the upgrades.
Without the JAVAx_HOME variables set they skip steps that involve C* versions
that require a different jdk.
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-alpha1, 5.0
>
> Attachments: Screenshot 2023-03-03 at 09.24.50.png
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
This message was sent by Atlassian Jira
(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=17845364#comment-17845364 ] Michael Semb Wever commented on CASSANDRA-19632: there's past ML discussions where the consensus was to avoid these types of changes on release branches. 5.0 should now be focused on stability. new development in trunk. > 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 >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 5.0.x, 5.x > > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-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=17845304#comment-17845304 ] Michael Semb Wever commented on CASSANDRA-19632: please do not do this in 5.0 (unless where it addresses a known bug) > 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 >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 5.0.x, 5.x > > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19619) Enforce contract for internal metrics naming
[
https://issues.apache.org/jira/browse/CASSANDRA-19619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843835#comment-17843835
]
Michael Semb Wever commented on CASSANDRA-19619:
+1 (so long CI is ok)
> Enforce contract for internal metrics naming
>
>
> Key: CASSANDRA-19619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19619
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Metrics have their internal representation which uniquely identifies a
> particular metric name. The name is formed as {{. type>..}}. For some metrics, the scope includes a
> metric name that is not necessary for uniqueness, this can be simplified.
> For example,
> {code}
> // AS IS
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics.BalancedTreeIntersectionEarlyExits
> // TO BE
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics
> {code}
> The metrics are filtered based on knowledge of how they are formatted, so
> having a metric scope without a built-in metric name also simplifies the way
> we filter metrics.
--
This message was sent by Atlassian Jira
(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-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19606:
---
Fix Version/s: 5.0-beta2
5.0
5.1
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 3.0.31, 3.11.18, 4.0.13, 4.1.5, 5.0-beta2, 5.0, 5.1
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843540#comment-17843540
]
Michael Semb Wever commented on CASSANDRA-19606:
Brandon's in-tree commit:
https://github.com/apache/cassandra/commit/3262847ad75e720963024edae5cb39a60e789678
… has been pushed to dockerhub and apache.jfrog.io for amd64 and arm64
according to instructions in CASSANDRA-18931
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 3.0.31, 3.11.18, 4.0.13, 4.1.5
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19606:
---
Source Control Link:
https://github.com/apache/cassandra-builds/commit/4ec20b6979cb97ce5b8f1ecb817cf22ecf92bcae
https://github.com/apache/cassandra/commit/3262847ad75e720963024edae5cb39a60e789678
(was:
https://github.com/apache/cassandra-builds/commit/4ec20b6979cb97ce5b8f1ecb817cf22ecf92bcae)
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 3.0.31, 3.11.18, 4.0.13, 4.1.5
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19606:
---
Fix Version/s: (was: 5.0)
(was: 5.1)
(was: 5.0-beta2)
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 3.0.31, 3.11.18, 4.0.13, 4.1.5
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19534) unbounded queues in native transport requests lead to node instability
[
https://issues.apache.org/jira/browse/CASSANDRA-19534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19534:
---
Fix Version/s: 4.1.x
> unbounded queues in native transport requests lead to node instability
> --
>
> Key: CASSANDRA-19534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19534
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Jon Haddad
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Attachments: Scenario 1 - QUEUE + Backpressure.jpg, Scenario 1 -
> QUEUE.jpg, Scenario 1 - Stock.jpg, Scenario 2 - QUEUE + Backpressure.jpg,
> Scenario 2 - QUEUE.jpg, Scenario 2 - Stock.jpg, ci_summary.html,
> screenshot-1.png, screenshot-2.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a node is under pressure, hundreds of thousands of requests can show up
> in the native transport queue, and it looks like it can take way longer to
> timeout than is configured. We should be shedding load much more
> aggressively and use a bounded queue for incoming work. This is extremely
> evident when we combine a resource consuming workload with a smaller one:
> Running 5.0 HEAD on a single node as of today:
> {noformat}
> # populate only
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --maxrlat 100 --populate
> 10m --rate 50k -n 1
> # workload 1 - larger reads
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --rate 200 -d 1d
> # second workload - small reads
> easy-cass-stress run KeyValue -p 1m --rate 20k -r .5 -d 24h{noformat}
> It appears our results don't time out at the requested server time either:
>
> {noformat}
> Writes Reads
> Deletes Errors
> Count Latency (p99) 1min (req/s) | Count Latency (p99) 1min (req/s) |
> Count Latency (p99) 1min (req/s) | Count 1min (errors/s)
> 950286 70403.93 634.77 | 789524 70442.07 426.02 |
> 0 0 0 | 9580484 18980.45
> 952304 70567.62 640.1 | 791072 70634.34 428.36 |
> 0 0 0 | 9636658 18969.54
> 953146 70767.34 640.1 | 791400 70767.76 428.36 |
> 0 0 0 | 9695272 18969.54
> 956833 71171.28 623.14 | 794009 71175.6 412.79 |
> 0 0 0 | 9749377 19002.44
> 959627 71312.58 656.93 | 795703 71349.87 435.56 |
> 0 0 0 | 9804907 18943.11{noformat}
>
> After stopping the load test altogether, it took nearly a minute before the
> requests were no longer queued.
--
This message was sent by Atlassian Jira
(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-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19606:
---
Fix Version/s: 5.0
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 3.0.31, 3.11.18, 4.0.13, 4.1.5, 5.0-beta2, 5.0, 5.1
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842761#comment-17842761
]
Michael Semb Wever commented on CASSANDRA-19606:
Nice catch!
Do we need (or should) to do this in the in-tree images too ?
Does this fix (prevent failures) on future <5.0 release cuttings ?
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19490) Add foundation for independent parsing of junit based output for CI reporting to cassandra-builds
[ https://issues.apache.org/jira/browse/CASSANDRA-19490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842084#comment-17842084 ] Michael Semb Wever commented on CASSANDRA-19490: yes. do we have a ticket for a script that validates a results_details.tar.xz meets pre-commit requirements …? > Add foundation for independent parsing of junit based output for CI reporting > to cassandra-builds > - > > Key: CASSANDRA-19490 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19490 > Project: Cassandra > Issue Type: New Feature > Components: CI >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > PR attached. > For doing CI ourselves, it's useful to have a single pane of glass report > where you have a summary of results for all your suites as well as inlined > failures. This should be agnostic to any xunit based output; so long as we > co-locate the xunit data in directories adjacent to one another, the script > in the PR will generate an in-memory representation of the xunit results as > well as inline failures to an existing .html file. > The contents will need to be tweaked a bit to generate the top level branch + > sha + checkstyle + summaries information, but the vast majority of that is > already parsed and easily available within the script and can be extended > pretty trivially. > Opening up a pr to pull this into > [cassandra-builds](https://github.com/apache/cassandra-builds) since [~mck] > is actively working on that and needs these primitives. I'd expect the > contents in ci_parser to be massaged to become a more finalized, full > solution before we start to use it but no harm in the incremental merge. -- This message was sent by Atlassian Jira (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-18831) Enable Cassandra to build and run under JDK21
[ https://issues.apache.org/jira/browse/CASSANDRA-18831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841511#comment-17841511 ] Michael Semb Wever commented on CASSANDRA-18831: Reminder that when this lands we want to drop support for JDK 11 (which we should have a separate ticket for), and bump the major version. A new major release that supports JDK 17 and JDK 21 is no longer online-compatible with a 4.x cluster using the same JDK. (We stated we do not want to encourage nor force operators upgrade versions and JDKs in the same step.) Therefore the new major release needs to be accompanied with a new major version, i.e. 6.0. I don't believe this causes additional work beyond the trivial. And let's not commit trunk to 6.0 until after this has landed (we've jumped on the "new major version, let's clean up" happy caravan all too prematurely once already… > Enable Cassandra to build and run under JDK21 > - > > Key: CASSANDRA-18831 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18831 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Achilles Benetopoulos >Assignee: Josh McKenzie >Priority: Normal > Fix For: 5.x > > Attachments: jdk21-patch > > > This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list > of supported Java versions, and extends that work to enable building and > running Cassandra under JDK21. > The following commits comprise the changes included in the attached patch: > - > [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47] > - > [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897] > - > [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913] > - > [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451] -- This message was sent by Atlassian Jira (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-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19558: --- Fix Version/s: 5.0-beta2 5.0 5.1 (was: 5.x) (was: 5.0.x) Since Version: 5.0-beta1 Source Control Link: https://github.com/apache/cassandra-builds/commit/5a9ba1a1962794a338cecaa7d8e7f23cd0ea09fd https://github.com/apache/cassandra-builds/commit/eab310bd76329be5d47c7a8c4e8837bbb3e2fff0 https://github.com/apache/cassandra/commit/3c85def5cc8bbd93e0c16554e9ae5 (was: https://github.com/apache/cassandra-builds/commit/5a9ba1a1962794a338cecaa7d8e7f23cd0ea09fd https://github.com/apache/cassandra-builds/commit/eab310bd76329be5d47c7a8c4e8837bbb3e2fff0) Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed https://github.com/apache/cassandra/commit/3c85def5cc8bbd93e0c16554e9ae5fdc6badf24f > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-beta2, 5.0, 5.1 > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558-50-33-ci_summary.html, > CASSANDRA-19558-50-33-results_details.tar.xz, > CASSANDRA-19558-trunk-11-ci_summary.html, CASSANDRA-19558_#8_ci_summary.html, > CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - -docker scripts always try to login (as base images need to be pulled too)- > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was > INFRA-25694) > - copy ci_summary.html and results_details.tar.xz to nightlies -- This message was sent by Atlassian Jira (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-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19558: --- Description: A few follow up improvements and bug fixes for the standalone jenkinsfile. - add at top a list of test failures in ci_summary.html - -docker scripts always try to login (as base images need to be pulled too)- - move simulator-dtests to large containers (they need 8g just heap) - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct perms (from marcuse) - persist the jenkinsfile parameters from run to run (important for the post-commit jobs to keep their non-default branch and profile values) (was CASSANDRA-19536) - increase jvm-dtest splits from 8 to 12 - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile generateTestReports() with manual wget of test files, allowing the summary phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was INFRA-25694) - copy ci_summary.html and results_details.tar.xz to nightlies was: A few follow up improvements and bug fixes for the standalone jenkinsfile. - add at top a list of test failures in ci_summary.html - docker scripts always try to login (as base images need to be pulled too) - move simulator-dtests to large containers (they need 8g just heap) - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct perms (from marcuse) - persist the jenkinsfile parameters from run to run (important for the post-commit jobs to keep their non-default branch and profile values) (was CASSANDRA-19536) - increase jvm-dtest splits from 8 to 12 - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile generateTestReports() with manual wget of test files, allowing the summary phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was INFRA-25694) - copy ci_summary.html and results_details.tar.xz to nightlies > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558-50-33-ci_summary.html, > CASSANDRA-19558-50-33-results_details.tar.xz, > CASSANDRA-19558-trunk-11-ci_summary.html, CASSANDRA-19558_#8_ci_summary.html, > CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - -docker scripts always try to login (as base images need to be pulled too)- > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was > INFRA-25694) > - copy ci_summary.html and results_details.tar.xz to nightlies -- This message was sent by Atlassian Jira (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-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840770#comment-17840770 ] Michael Semb Wever edited comment on CASSANDRA-19558 at 4/25/24 11:49 AM: -- Back to (3)… New Patches - trunk https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/jenkinsfile-persist-parameters - 5.0 https://github.com/apache/cassandra/compare/cassandra-5.0...thelastpickle:cassandra:mck/jenkinsfile-persist-parameters-5.0 CI - 5.0 post-commit https://ci-cassandra.apache.org/job/Cassandra-devbranch-5/21 - 5.0 pre-commit internal [^CASSANDRA-19558-50-33-ci_summary.html] , [^CASSANDRA-19558-50-33-results_details.tar.xz] - trunk pre-commit internal [^CASSANDRA-19558-trunk-11-ci_summary.html] , [^CASSANDRA-19558_#8_results_details.tar.xz] No related failures! was (Author: michaelsembwever): Back to (3)… New Patches - trunk https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/jenkinsfile-persist-parameters - 5.0 https://github.com/apache/cassandra/compare/cassandra-5.0...thelastpickle:cassandra:mck/jenkinsfile-persist-parameters-5.0 CI 5.0 post-commit https://ci-cassandra.apache.org/job/Cassandra-devbranch-5/21 5.0 pre-commit internal [^CASSANDRA-19558-50-33-ci_summary.html] , [^CASSANDRA-19558-50-33-results_details.tar.xz] trunk pre-commit internal [^CASSANDRA-19558-trunk-11-ci_summary.html] , [^CASSANDRA-19558_#8_results_details.tar.xz] No related failures! > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558-50-33-ci_summary.html, > CASSANDRA-19558-50-33-results_details.tar.xz, > CASSANDRA-19558-trunk-11-ci_summary.html, CASSANDRA-19558_#8_ci_summary.html, > CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - docker scripts always try to login (as base images need to be pulled too) > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was > INFRA-25694) > - copy ci_summary.html and results_details.tar.xz to nightlies -- This message was sent by Atlassian Jira (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-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840770#comment-17840770 ] Michael Semb Wever commented on CASSANDRA-19558: Back to (3)… New Patches - trunk https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/jenkinsfile-persist-parameters - 5.0 https://github.com/apache/cassandra/compare/cassandra-5.0...thelastpickle:cassandra:mck/jenkinsfile-persist-parameters-5.0 CI 5.0 post-commit https://ci-cassandra.apache.org/job/Cassandra-devbranch-5/21 5.0 pre-commit internal [^CASSANDRA-19558-50-33-ci_summary.html] , [^CASSANDRA-19558-50-33-results_details.tar.xz] trunk pre-commit internal [^CASSANDRA-19558-trunk-11-ci_summary.html] , [^CASSANDRA-19558_#8_results_details.tar.xz] No related failures! > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558-50-33-ci_summary.html, > CASSANDRA-19558-50-33-results_details.tar.xz, > CASSANDRA-19558-trunk-11-ci_summary.html, CASSANDRA-19558_#8_ci_summary.html, > CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - docker scripts always try to login (as base images need to be pulled too) > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was > INFRA-25694) > - copy ci_summary.html and results_details.tar.xz to nightlies -- This message was sent by Atlassian Jira (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-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840332#comment-17840332 ] Michael Semb Wever edited comment on CASSANDRA-19558 at 4/25/24 8:08 AM: - Still issues with docker rate limits, now solely caused by pulling alpine:latest Fixing by pushing alpine:3.19.1 into our jfrog too, reference this comment: https://issues.apache.org/jira/browse/CASSANDRA-18931?focusedCommentId=17840325=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17840325 Another issue was with having the .git subdirectory included in the stash, and unstashing it on top of existing git working directories on ci-cassandra. The only reason .git was being stashed was because a bug had crept into the deb/rpm scripts where they failed if git didn't work. The scripts have been fixed to work on non-versioned working directories, and .git subdirectory is no longer stashed. was (Author: michaelsembwever): Still issues with docker rate limits, now solely caused by pulling alpine:latest Pushing alpine:3.19.1 into our jfrog too, reference this comment: https://issues.apache.org/jira/browse/CASSANDRA-18931?focusedCommentId=17840325=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17840325 > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558_#8_ci_summary.html, CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - docker scripts always try to login (as base images need to be pulled too) > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was > INFRA-25694) > - copy ci_summary.html and results_details.tar.xz to nightlies -- This message was sent by Atlassian Jira (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-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19558: --- Attachment: CASSANDRA-19558-50-33-ci_summary.html > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558-50-33-ci_summary.html, > CASSANDRA-19558-50-33-results_details.tar.xz, > CASSANDRA-19558_#8_ci_summary.html, CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - docker scripts always try to login (as base images need to be pulled too) > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was > INFRA-25694) > - copy ci_summary.html and results_details.tar.xz to nightlies -- This message was sent by Atlassian Jira (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-18931) ci job to build and push new in-tree docker images when dockerfile changes
[
https://issues.apache.org/jira/browse/CASSANDRA-18931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840325#comment-17840325
]
Michael Semb Wever commented on CASSANDRA-18931:
We want alpine:3.19.1 in jfrog too.
Pushing it is a bit tricky because of referenced SHAs in its manifest.
Something like…
{code}
# just grab everything
docker pull --platform linux/amd64 --all-tags alpine
docker pull --platform linux/arm64 --all-tags alpine
docker tag alpine:3.19.1 apache.jfrog.io/cassan-docker/alpine:3.19.1
docker push apache.jfrog.io/cassan-docker/alpine:3.19.1
# repeat for any missing references
docker pull --platform linux/amd64 alpine:latest@sha256:
docker pull --platform linux/arm64 alpine:latest@sha256:
{code}
> ci job to build and push new in-tree docker images when dockerfile changes
> --
>
> Key: CASSANDRA-18931
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18931
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> The dockerfiles under .build/docker are now and are deployed by file md5sum.
> (There is no "latest").
> in-tree scripts will have to build these images on-the-fly if they are not
> available to pull from dockerhub.
> Automatically building and pushing them to dockerhub whenever they change
> will save a lot of resources and time in tests/CI.
--
This message was sent by Atlassian Jira
(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-18130) Log hardware and container params during test runs to help troubleshoot intermittent failures
[
https://issues.apache.org/jira/browse/CASSANDRA-18130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18130:
---
Fix Version/s: 2.2.20
3.0.31
3.11.18
4.0.13
4.1.5
5.0-beta2
5.0
5.1
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
> Log hardware and container params during test runs to help troubleshoot
> intermittent failures
> -
>
> Key: CASSANDRA-18130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18130
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java, Test/dtest/python, Test/unit
>Reporter: Josh McKenzie
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.31, 3.11.18, 4.0.13, 4.1.5, 5.0-beta2, 5.0,
> 5.1
>
>
> {color:#00}We’ve long had flakiness in our containerized ASF CI
> environment that we don’t see in circleci. The environment itself is both
> containerized and heterogenous, so there are differences in both the hardware
> environment and the software environment in which it executes. For reference,
> see:
> [https://github.com/apache/cassandra-builds/blob/trunk/ASF-jenkins-agents.md#current-agents]{color}
> {color:#00} {color}
> {color:#00}We should log a variety of hardware, container, and software
> environment details to help get to the bottom of where some test failures may
> be occurring. As we don’t have shell access to the machines it’ll be easier
> to have this information logged / retrieved during test runs than to try and
> profile each host independently.{color}
--
This message was sent by Atlassian Jira
(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-18130) Log hardware and container params during test runs to help troubleshoot intermittent failures
[
https://issues.apache.org/jira/browse/CASSANDRA-18130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18130:
---
Resolution: Fixed
Status: Resolved (was: Open)
Committed as
https://github.com/apache/cassandra-builds/commit/eab310bd76329be5d47c7a8c4e8837bbb3e2fff0
as part of CASSANDRA-19558
> Log hardware and container params during test runs to help troubleshoot
> intermittent failures
> -
>
> Key: CASSANDRA-18130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18130
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java, Test/dtest/python, Test/unit
>Reporter: Josh McKenzie
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> {color:#00}We’ve long had flakiness in our containerized ASF CI
> environment that we don’t see in circleci. The environment itself is both
> containerized and heterogenous, so there are differences in both the hardware
> environment and the software environment in which it executes. For reference,
> see:
> [https://github.com/apache/cassandra-builds/blob/trunk/ASF-jenkins-agents.md#current-agents]{color}
> {color:#00} {color}
> {color:#00}We should log a variety of hardware, container, and software
> environment details to help get to the bottom of where some test failures may
> be occurring. As we don’t have shell access to the machines it’ll be easier
> to have this information logged / retrieved during test runs than to try and
> profile each host independently.{color}
--
This message was sent by Atlassian Jira
(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-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19558: --- Source Control Link: https://github.com/apache/cassandra-builds/commit/5a9ba1a1962794a338cecaa7d8e7f23cd0ea09fd https://github.com/apache/cassandra-builds/commit/eab310bd76329be5d47c7a8c4e8837bbb3e2fff0 > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558_#8_ci_summary.html, CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - docker scripts always try to login (as base images need to be pulled too) > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was > INFRA-25694) > - copy ci_summary.html and results_details.tar.xz to nightlies -- This message was sent by Atlassian Jira (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-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839287#comment-17839287 ] Michael Semb Wever edited comment on CASSANDRA-19558 at 4/23/24 7:31 PM: - A number of issues have been identified. – need to capture the generateTestReports logs, – fix ant version in centos7-build.docker – remove docker login (if credentials exist then docker is logged in) – prefetch docker images from jfrog (to reduce dockerhub pull rate limits) – use scripts from cassandra-builds to clean and report on agents – stream xz where possible (not an issue, just perf improvement) The docker pull rate limit was the most serious, blocking. patches… 1. this is part of CASSANDRA-18594 (most of it is already running (manually deployed) to ci-cassandra) [https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:cassandra-builds:mck/18594] ( [https://github.com/apache/cassandra-builds/commit/eb3eb5e] ) 2. and for CASSANDRA-19558 [https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:cassandra-builds:mck/19558] ( [https://github.com/thelastpickle/cassandra-builds/commit/9f8ae9dcacd0d744992cc4eaf50f29a8836ffdbd] ) 3. and then (also for CASSANDRA-19558 ) but comes last (i can test it manually once (2) is committed) [https://github.com/apache/cassandra/commit/92c0cb7] (this is on top of the previous commit (that already passed review) in [https://github.com/apache/cassandra/compare/apache:cassandra:cassandra-5.0...thelastpickle:cassandra:mck/jenkinsfile-persist-parameters-5.0|https://github.com/apache/cassandra/compare/apache:cassandra:cassandra-5.0...thelastpickle:cassandra:mck/jenkinsfile-persist-parameters-5.0] ) was (Author: michaelsembwever): A number of issues have been identified. – need to capture the generateTestReports logs, – fix ant version in centos7-build.docker – remove docker login (if credentials exist then docker is logged in) – prefetch docker images from jfrog (to reduce dockerhub pull rate limits) – use scripts from cassandra-builds to clean and report on agents – stream xz where possible (not an issue, just perf improvement) The docker pull rate limit was the most serious, blocking. patches… 1. this is part of CASSANDRA-18594 (most of it is already running (manually deployed) to ci-cassandra) [https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:cassandra-builds:mck/18594] ( [https://github.com/apache/cassandra-builds/commit/eb3eb5e] ) 2. and for CASSANDRA-19558 [https://github.com/thelastpickle/cassandra-builds/compare/mck/18594...thelastpickle:cassandra-builds:mck/19558] ( [https://github.com/thelastpickle/cassandra-builds/commit/9f8ae9dcacd0d744992cc4eaf50f29a8836ffdbd] ) 3. and then (also for CASSANDRA-19558 ) but comes last (i can test it manually once (2) is committed) [https://github.com/apache/cassandra/commit/92c0cb7] (this is on top of the previous commit (that already passed review) in [https://github.com/apache/cassandra/compare/apache:cassandra:cassandra-5.0...thelastpickle:cassandra:mck/jenkinsfile-persist-parameters-5.0|https://github.com/apache/cassandra/compare/apache:cassandra:cassandra-5.0...thelastpickle:cassandra:mck/jenkinsfile-persist-parameters-5.0] ) > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558_#8_ci_summary.html, CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - docker scripts always try to login (as base images need to be pulled too) > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would
[jira] [Comment Edited] (CASSANDRA-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839287#comment-17839287 ] Michael Semb Wever edited comment on CASSANDRA-19558 at 4/23/24 7:26 PM: - A number of issues have been identified. – need to capture the generateTestReports logs, – fix ant version in centos7-build.docker – remove docker login (if credentials exist then docker is logged in) – prefetch docker images from jfrog (to reduce dockerhub pull rate limits) – use scripts from cassandra-builds to clean and report on agents – stream xz where possible (not an issue, just perf improvement) The docker pull rate limit was the most serious, blocking. patches… 1. this is part of CASSANDRA-18594 (most of it is already running (manually deployed) to ci-cassandra) [https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:cassandra-builds:mck/18594] ( [https://github.com/apache/cassandra-builds/commit/eb3eb5e] ) 2. and for CASSANDRA-19558 [https://github.com/thelastpickle/cassandra-builds/compare/mck/18594...thelastpickle:cassandra-builds:mck/19558] ( [https://github.com/thelastpickle/cassandra-builds/commit/9f8ae9dcacd0d744992cc4eaf50f29a8836ffdbd] ) 3. and then (also for CASSANDRA-19558 ) but comes last (i can test it manually once (2) is committed) [https://github.com/apache/cassandra/commit/92c0cb7] (this is on top of the previous commit (that already passed review) in [https://github.com/apache/cassandra/compare/apache:cassandra:cassandra-5.0...thelastpickle:cassandra:mck/jenkinsfile-persist-parameters-5.0|https://github.com/apache/cassandra/compare/apache:cassandra:cassandra-5.0...thelastpickle:cassandra:mck/jenkinsfile-persist-parameters-5.0] ) was (Author: michaelsembwever): A number of issues have been identified. – need to capture the generateTestReports logs, – fix ant version in centos7-build.docker – remove docker login (if credentials exist then docker is logged in) – prefetch docker images from jfrog (to reduce dockerhub pull rate limits) – use scripts from cassandra-builds to clean and report on agents – stream xz where possible (not an issue, just perf improvement) The docker pull rate limit was the most serious, blocking. patches… 1. this is part of CASSANDRA-18594 (most of it is already running (manually deployed) to ci-cassandra) [https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:cassandra-builds:mck/18594] ( [https://github.com/apache/cassandra-builds/commit/eb3eb5e] ) 2. and for CASSANDRA-19558 [https://github.com/thelastpickle/cassandra-builds/compare/mck/18594...thelastpickle:cassandra-builds:mck/19558] ( [https://github.com/thelastpickle/cassandra-builds/commit/9f8ae9dcacd0d744992cc4eaf50f29a8836ffdbd] ) 3. and then (also for CASSANDRA-19558 ) but comes last (i can test it manually once (2) is committed) [https://github.com/apache/cassandra/commit/b3e1e40658e99c37f2a142e247ca4305fcc52eb0] (this is on top of the previous commit (that already passed review) in [https://github.com/apache/cassandra/compare/apache:cassandra:cassandra-5.0...thelastpickle:cassandra:mck/mck/jenkinsfile-persist-parameters-5.0-test] ) > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558_#8_ci_summary.html, CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - docker scripts always try to login (as base images need to be pulled too) > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was > INFRA-25694) > - copy ci_summary.html and
[jira] [Updated] (CASSANDRA-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19558: --- Reviewers: Brandon Williams, Michael Semb Wever (was: Brandon Williams) Status: Review In Progress (was: Patch Available) > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558_#8_ci_summary.html, CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - docker scripts always try to login (as base images need to be pulled too) > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was > INFRA-25694) > - copy ci_summary.html and results_details.tar.xz to nightlies -- This message was sent by Atlassian Jira (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-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840060#comment-17840060 ] Michael Semb Wever edited comment on CASSANDRA-19558 at 4/23/24 10:55 AM: -- (1) is committed. wrt (2). hit a few small problems. INFRA-25738 being one (though unrelated to the patch). needed to make it work for the <5 jobs, and against different possible python versions (>=3.6). these are fixed. i'm ready to commit (2) which is now [https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:cassandra-builds:mck/19558] (excluding the throwaway commit, ofc) Otherwise we have good test runs in #3 to #7 in [https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-artifacts/] and in #588 to #594 in [https://ci-cassandra.apache.org/job/Cassandra-4.1-artifacts/] For (3) it is also needed ensuring it works when github is down (or goes down mid build)… was (Author: michaelsembwever): (1) is committed. wrt (2). hit a few small problems. INFRA-25738 being one (though unrelated to the patch). needed to make it work for the <5 jobs, and against different possible python versions (>=3.6). these are fixed. i'm ready to commit (2) which is now https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:cassandra-builds:mck/19558 Otherwise we have good test runs in #3 to #7 in [https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-artifacts/] and in #588 to #594 in [https://ci-cassandra.apache.org/job/Cassandra-4.1-artifacts/] For (3) it is also needed ensuring it works when github is down (or goes down mid build)… > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558_#8_ci_summary.html, CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - docker scripts always try to login (as base images need to be pulled too) > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was > INFRA-25694) > - copy ci_summary.html and results_details.tar.xz to nightlies -- This message was sent by Atlassian Jira (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-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19558: --- Status: Ready to Commit (was: Review In Progress) > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558_#8_ci_summary.html, CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - docker scripts always try to login (as base images need to be pulled too) > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was > INFRA-25694) > - copy ci_summary.html and results_details.tar.xz to nightlies -- This message was sent by Atlassian Jira (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-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840060#comment-17840060 ] Michael Semb Wever edited comment on CASSANDRA-19558 at 4/23/24 10:51 AM: -- (1) is committed. wrt (2). hit a few small problems. INFRA-25738 being one (though unrelated to the patch). needed to make it work for the <5 jobs, and against different possible python versions (>=3.6). these are fixed. i'm ready to commit (2) which is now https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:cassandra-builds:mck/19558 Otherwise we have good test runs in #3 to #7 in [https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-artifacts/] and in #588 to #594 in [https://ci-cassandra.apache.org/job/Cassandra-4.1-artifacts/] For (3) it is also needed ensuring it works when github is down (or goes down mid build)… was (Author: michaelsembwever): (1) is committed. wrt (2). hit a few small problems. INFRA-25738 being one (though unrelated to the patch). needed to make it work for the <5 jobs, and against different possible python versions (>=3.6). these are fixed. i'm ready to commit (2). Otherwise we have good test runs in #3 to #7 in [https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-artifacts/] and in #588 to #594 in [https://ci-cassandra.apache.org/job/Cassandra-4.1-artifacts/] For (3) it is also needed ensuring it works when github is down (or goes down mid build)… > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558_#8_ci_summary.html, CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - docker scripts always try to login (as base images need to be pulled too) > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was > INFRA-25694) > - copy ci_summary.html and results_details.tar.xz to nightlies -- This message was sent by Atlassian Jira (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-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840060#comment-17840060 ] Michael Semb Wever edited comment on CASSANDRA-19558 at 4/23/24 10:50 AM: -- (1) is committed. wrt (2). hit a few small problems. INFRA-25738 being one (though unrelated to the patch). needed to make it work for the <5 jobs, and against different possible python versions (>=3.6). these are fixed. i'm ready to commit (2). Otherwise we have good test runs in #3 to #7 in [https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-artifacts/] and in #588 to #594 in [https://ci-cassandra.apache.org/job/Cassandra-4.1-artifacts/] For (3) it is also needed ensuring it works when github is down (or goes down mid build)… was (Author: michaelsembwever): (1) is committed. working on (2). hit a few small problems. INFRA-25738 being one (though unrelated to the patch). needed to make it work for the <5 jobs, and against different possible python versions (>=3.6), and ensuring it works when github is down (or goes down mid build)… Otherwise we have good test runs in #3 to #7 in [https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-artifacts/] and in #588 to #594 in [https://ci-cassandra.apache.org/job/Cassandra-4.1-artifacts/] > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558_#8_ci_summary.html, CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - docker scripts always try to login (as base images need to be pulled too) > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was > INFRA-25694) > - copy ci_summary.html and results_details.tar.xz to nightlies -- This message was sent by Atlassian Jira (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-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840060#comment-17840060 ] Michael Semb Wever edited comment on CASSANDRA-19558 at 4/23/24 10:48 AM: -- (1) is committed. working on (2). hit a few small problems. INFRA-25738 being one (though unrelated to the patch). needed to make it work for the <5 jobs, and against different possible python versions (>=3.6), and ensuring it works when github is down (or goes down mid build)… Otherwise we have good test runs in #3 to #7 in [https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-artifacts/] and in #588 to #594 in [https://ci-cassandra.apache.org/job/Cassandra-4.1-artifacts/] was (Author: michaelsembwever): (1) is committed. working on (2). hit a few small problems. INFRA-25738 being one (though unrelated to the patch). needed to make it work for the <5 jobs, and against different possible python versions (>=3.6), and ensuring it works when github is down (or goes down mid build)… > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558_#8_ci_summary.html, CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - docker scripts always try to login (as base images need to be pulled too) > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was > INFRA-25694) > - copy ci_summary.html and results_details.tar.xz to nightlies -- This message was sent by Atlassian Jira (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-19558) Standalone jenkinsfile first round bug fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840060#comment-17840060 ] Michael Semb Wever commented on CASSANDRA-19558: (1) is committed. working on (2). hit a few small problems. INFRA-25738 being one (though unrelated to the patch). needed to make it work for the <5 jobs, and against different possible python versions (>=3.6), and ensuring it works when github is down (or goes down mid build)… > Standalone jenkinsfile first round bug fixes > > > Key: CASSANDRA-19558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19558 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-19558_50_#5_ci_summary.html, > CASSANDRA-19558_50_#5_results_details.tar.xz, > CASSANDRA-19558-5.0_#13_ci_summary.html, > CASSANDRA-19558-5.0_#13_results_details.tar.xz, > CASSANDRA-19558-5.0_#16_ci_summary.html, > CASSANDRA-19558-5.0_#16_results_details.tar.xz, > CASSANDRA-19558_#8_ci_summary.html, CASSANDRA-19558_#8_results_details.tar.xz > > > A few follow up improvements and bug fixes for the standalone jenkinsfile. > - add at top a list of test failures in ci_summary.html > - docker scripts always try to login (as base images need to be pulled too) > - move simulator-dtests to large containers (they need 8g just heap) > - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct > perms (from marcuse) > - persist the jenkinsfile parameters from run to run (important for the > post-commit jobs to keep their non-default branch and profile values) (was > CASSANDRA-19536) > - increase jvm-dtest splits from 8 to 12 > - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile > generateTestReports() with manual wget of test files, allowing the summary > phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was > INFRA-25694) > - copy ci_summary.html and results_details.tar.xz to nightlies -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
