(cassandra-website) branch asf-staging updated (d65c1e11 -> 8df8dc70)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard d65c1e11 generate docs for 607350d3 new 8df8dc70 generate docs for 607350d3 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (d65c1e11) \ N -- N -- N refs/heads/asf-staging (8df8dc70) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../managing/tools/nodetool/clientstats.html | 3 +-- .../managing/tools/nodetool/clientstats.html | 3 +-- site-ui/build/ui-bundle.zip| Bin 4883646 -> 4883646 bytes 3 files changed, 2 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19493) Optionally fail writes when SAI refuses to index a term value exceeding a configured maximum size
[
https://issues.apache.org/jira/browse/CASSANDRA-19493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837503#comment-17837503
]
Caleb Rackliffe commented on CASSANDRA-19493:
-
Once I get a +1 on the 5.0 patch, I'll create a trunk branch...
> Optionally fail writes when SAI refuses to index a term value exceeding a
> configured maximum size
> -
>
> Key: CASSANDRA-19493
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19493
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Attachments: ci_summary.html
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> SAI currently emits a client warning when we try to index a text value larger
> than {{{}cassandra.sai.max_string_term_size{}}}. It might be nice to have a
> hard limit as well, above which we can reject the mutation entirely.
--
This message was sent by Atlassian Jira
(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-19493) Optionally fail writes when SAI refuses to index a term value exceeding a configured maximum size
[
https://issues.apache.org/jira/browse/CASSANDRA-19493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19493:
Attachment: ci_summary.html
> Optionally fail writes when SAI refuses to index a term value exceeding a
> configured maximum size
> -
>
> Key: CASSANDRA-19493
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19493
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Attachments: ci_summary.html
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> SAI currently emits a client warning when we try to index a text value larger
> than {{{}cassandra.sai.max_string_term_size{}}}. It might be nice to have a
> hard limit as well, above which we can reject the mutation entirely.
--
This message was sent by Atlassian Jira
(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-19493) Optionally fail writes when SAI refuses to index a term value exceeding a configured maximum size
[
https://issues.apache.org/jira/browse/CASSANDRA-19493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837502#comment-17837502
]
Caleb Rackliffe commented on CASSANDRA-19493:
-
Attached 5.0 CI results. Everything looks good, except for some Python upgrade
test issues that are both unrelated to the patch and specific to my CI
environment.
> Optionally fail writes when SAI refuses to index a term value exceeding a
> configured maximum size
> -
>
> Key: CASSANDRA-19493
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19493
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Attachments: ci_summary.html
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> SAI currently emits a client warning when we try to index a text value larger
> than {{{}cassandra.sai.max_string_term_size{}}}. It might be nice to have a
> hard limit as well, above which we can reject the mutation entirely.
--
This message was sent by Atlassian Jira
(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-18736) Streaming exception race creates corrupt transaction log files that prevent restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837487#comment-17837487
]
Jon Meredith commented on CASSANDRA-18736:
--
As expected, the (modified) tests fail on 4.0 so I've backported there too.
I'll try and post test runs tomorrow but wanted to share the changes in case
anybody was waiting on it.
PRs
Trunk https://github.com/apache/cassandra/pull/3250
5.0 https://github.com/apache/cassandra/pull/3251
4.1 https://github.com/apache/cassandra/pull/3252
4.0 https://github.com/apache/cassandra/pull/3253
> Streaming exception race creates corrupt transaction log files that prevent
> restart
> ---
>
> Key: CASSANDRA-18736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18736
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/Startup and Shutdown
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> On restart, Cassandra logs this message and terminates.
> {code:java}
> ERROR 2023-07-17T17:17:22,931 [main]
> org.apache.cassandra.db.lifecycle.LogTransaction:561 - Unexpected disk state:
> failed to read transaction log
> [nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log in
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043]
> Files and contents follow:
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log
> ABORT:[,0,0][737437348]
> ***This record should have been the last one in all replicas
>
> ADD:[/datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb-284490-big-,0,8][2493503833]
> {code}
> The root cause is a race during streaming exception handling.
> Although concurrent modification of to the {{LogTransaction}} was added for
> CASSANDRA-16225, there is nothing to prevent usage after the transaction is
> completed (committed/aborted) once it has been processed by
> {{TransactionTidier}} (after the last reference is released). Before the
> transaction is tidied, the {{LogFile}} keeps a list of records that are
> checked for completion before adding new entries. In {{TransactionTidier}}
> {{LogFile.records}} are cleared as no longer needed, however the
> LogTransaction/LogFile is still accessible to the stream.
> The changes in CASSANDRA-17273 added a parallel set of {{onDiskRecords}} that
> could be used to reliably recreate the transaction log at any new datadirs
> the same as the existing
> datadirs - regardless of the effect of
> {{LogTransaction.untrackNew/LogFile.remove}}
> If a streaming exception causes the LogTransaction to be aborted and tidied
> just before {{SimpleSSTableMultiWriter}} calls trackNew to add a new sstable.
> At the time of the call, the {{LogFile}} will not contain any {{LogReplicas}},
> {{LogFile.records}} will be empty, and {{LogFile.onDiskRecords}} will contain
> an {{ABORT}}.
> When {{LogTransaction.trackNew/LogFile.add}} is called, the check for
> completed transaction fails as records is empty, there are no replicas on the
> datadir, so {{maybeCreateReplicas}} creates a new txnlog file replica
> containing ABORT, then
> appends an ADD record.
> The LogFile has already been tidied after the abort so the txnlog file is not
> removed and sits on disk until a restart, causing the faiulre.
> There is a related exception caused with a different interleaving of aborts,
> after an sstable is added, however this is just a nuisance in the logs as the
> LogRelica is already created with an {{ADD}} record first.
> {code:java}
> java.lang.AssertionError:
> [ADD:[/datadir1/keyspace/table/nb-23314378-big-,0,8][1869379820]] is not
> tracked by 55be35b0-35d1-11ee-865d-8b1e3c48ca06
> at org.apache.cassandra.db.lifecycle.LogFile.remove(LogFile.java:388)
> at
> org.apache.cassandra.db.lifecycle.LogTransaction.untrackNew(LogTransaction.java:158)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.untrackNew(LifecycleTransaction.java:577)
> at
> org.apache.cassandra.db.streaming.CassandraStreamReceiver$1.untrackNew(CassandraStreamReceiver.java:149)
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.abort(SimpleSSTableMultiWriter.java:95)
> at
> org.apache.cassandra.io.sstable.format.RangeAwareSSTableWriter.abort(RangeAwareSSTableWriter.java:191)
> at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamReader.read(CassandraCompressedStreamReader.java:115)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:85)
> at
>
[jira] [Commented] (CASSANDRA-19498) Error reading data from credential file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837480#comment-17837480
]
Brad Schoening commented on CASSANDRA-19498:
[~slavavrn] I'm having a problem running the pytest:
{code:java}
$ pytest test/test_legacy_auth.py
> from bin.cqlsh import read_options as cqlsh_read_options
E ModuleNotFoundError: No module named 'bin'
{code}
> Error reading data from credential file
> ---
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-website) branch asf-staging updated (368f9ecc -> d65c1e11)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 368f9ecc generate docs for 607350d3 new d65c1e11 generate docs for 607350d3 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (368f9ecc) \ N -- N -- N refs/heads/asf-staging (d65c1e11) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../managing/tools/nodetool/clientstats.html | 3 ++- .../managing/tools/nodetool/clientstats.html | 3 ++- content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4883646 -> 4883646 bytes 4 files changed, 5 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837468#comment-17837468 ] Abe Ratnofsky commented on CASSANDRA-19532: --- I forgot to update conf/cassandra.yaml and conf/cassandra_latest.yaml, thanks Stefan for catching that. Just fixed those and uploaded new test results, no failures related to my changes. > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary-1.html > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- This message was sent by Atlassian Jira (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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19532: -- Attachment: ci_summary-1.html > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary-1.html > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- This message was sent by Atlassian Jira (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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19532: -- Attachment: (was: ci_summary.html) > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary-1.html > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- This message was sent by Atlassian Jira (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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19532: -- Attachment: (was: result_details.tar.gz) > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary-1.html > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- This message was sent by Atlassian Jira (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-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:comment-tabpanel=17837458#comment-17837458
]
Brandon Williams commented on CASSANDRA-19534:
--
I do have to use a higher rate, but running both workloads concurrently
reproduces the runaway buildup and latency. On 4.1 this seems to stabilize
once errors begin, though higher than any timeouts are set, so this is new
behavior.
> 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: 5.0-rc, 5.x
>
>
> 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
(cassandra-website) branch asf-staging updated (955e8c2f -> 368f9ecc)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 955e8c2f generate docs for 607350d3 new 368f9ecc generate docs for 607350d3 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (955e8c2f) \ N -- N -- N refs/heads/asf-staging (368f9ecc) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4883646 -> 4883646 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19551) CCM nodes share the same environment variable map breaking upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837451#comment-17837451
]
Brandon Williams commented on CASSANDRA-19551:
--
The bootstrap failure is CASSANDRA-18098
> CCM nodes share the same environment variable map breaking upgrade tests
>
>
> Key: CASSANDRA-19551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> In {{node.py}} {{__environment_variables}} is generally always set with a map
> that is passed in from {{cluster.py}} so it is [shared between
> nodes](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151)
> and if nodes modify the map, such as in {{start}} when [updating the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860)
> then when {{get_env}} runs it will [overwrite the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244)
> that is selected by {{update_java_version}}.
> This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
> some of the upgrade tests because after the first node upgrades to 4.0 it's
> not longer possible for the subsequent nodes to select a Java version that
> isn't 11 because it's overridden by {{__environment_variables}}.
> I'm not even 100% clear on why the code in {{start}} should update
> {{__environment_variables}} at all if we calculate the correct java version
> on every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19558) Standalone jenkinsfile first round bug fixes
[
https://issues.apache.org/jira/browse/CASSANDRA-19558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837446#comment-17837446
]
Michael Semb Wever edited comment on CASSANDRA-19558 at 4/15/24 9:13 PM:
-
Ok, new round.
Two key improvements:
- {{options { durabilityHint('PERFORMANCE_OPTIMIZED') } }}
-
{{System.setProperty("org.jenkinsci.plugins.durabletask.BourneShellScript.USE_BINARY_WRAPPER",
"true");}}
Explicitly printing exit codes has also been added to the docker scripts.
Patch
- 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 (jdk11 only)
https://ci-cassandra.apache.org/job/Cassandra-5-devbranch/108/
- 5.0 pre-commit internal [^CASSANDRA-19558-5.0_#13_ci_summary.html] ,
[^CASSANDRA-19558-5.0_#13_results_details.tar.xz]
- 5.0 post-commit internal …wip…
- 5.0 …wip…
- trunk …wip…
was (Author: michaelsembwever):
Ok, new round.
Patch
- 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 (jdk11 only)
https://ci-cassandra.apache.org/job/Cassandra-5-devbranch/108/
- 5.0 pre-commit internal [^CASSANDRA-19558-5.0_#13_ci_summary.html] ,
[^CASSANDRA-19558-5.0_#13_results_details.tar.xz]
- 5.0 post-commit internal …wip…
- 5.0 …wip…
- trunk …wip…
> 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_#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-19551) CCM nodes share the same environment variable map breaking upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837447#comment-17837447
]
Ariel Weisberg edited comment on CASSANDRA-19551 at 4/15/24 9:12 PM:
-
Looks like {{TestGossip::test_assassinate_valid_node}} and
{{TestLargeColumn::test_cleanup}} consistently every time the past 5 runs, but
{{bootstrap_test.py::TestBootstrap::test_cleanup}} I haven't seen a failure for.
was (Author: aweisberg):
Looks like `TestGossip::test_assassinate_valid_node` and
`TestLargeColumn::test_cleanup` consistently every time the past 5 runs, but
`bootstrap_test.py::TestBootstrap::test_cleanup` I haven't seen a failure for.
> CCM nodes share the same environment variable map breaking upgrade tests
>
>
> Key: CASSANDRA-19551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> In {{node.py}} {{__environment_variables}} is generally always set with a map
> that is passed in from {{cluster.py}} so it is [shared between
> nodes](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151)
> and if nodes modify the map, such as in {{start}} when [updating the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860)
> then when {{get_env}} runs it will [overwrite the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244)
> that is selected by {{update_java_version}}.
> This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
> some of the upgrade tests because after the first node upgrades to 4.0 it's
> not longer possible for the subsequent nodes to select a Java version that
> isn't 11 because it's overridden by {{__environment_variables}}.
> I'm not even 100% clear on why the code in {{start}} should update
> {{__environment_variables}} at all if we calculate the correct java version
> on every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19551) CCM nodes share the same environment variable map breaking upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837447#comment-17837447
]
Ariel Weisberg commented on CASSANDRA-19551:
Looks like `TestGossip::test_assassinate_valid_node` and
`TestLargeColumn::test_cleanup` consistently every time the past 5 runs, but
`bootstrap_test.py::TestBootstrap::test_cleanup` I haven't seen a failure for.
> CCM nodes share the same environment variable map breaking upgrade tests
>
>
> Key: CASSANDRA-19551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> In {{node.py}} {{__environment_variables}} is generally always set with a map
> that is passed in from {{cluster.py}} so it is [shared between
> nodes](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151)
> and if nodes modify the map, such as in {{start}} when [updating the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860)
> then when {{get_env}} runs it will [overwrite the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244)
> that is selected by {{update_java_version}}.
> This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
> some of the upgrade tests because after the first node upgrades to 4.0 it's
> not longer possible for the subsequent nodes to select a Java version that
> isn't 11 because it's overridden by {{__environment_variables}}.
> I'm not even 100% clear on why the code in {{start}} should update
> {{__environment_variables}} at all if we calculate the correct java version
> on every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-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:comment-tabpanel=17837445#comment-17837445
]
Jon Haddad commented on CASSANDRA-19534:
OK. The issue is how C* recovers from being overloaded, so try doubling the
throughput from easy-cass-stress. Having two workloads running concurrently
helps make the problem more obvious, because this one is fairly resource
consuming:
{noformat}
easy-cass-stress run RandomPartitionAccess -p 100 -r 1 --workload.rows=10
--workload.select=partition --rate 200 -d 1d
{noformat}
By mixing one workload that has long queries with another workload that has
short ones, it creates a bottleneck and the small queries create a massive
backlog.
> 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: 5.0-rc, 5.x
>
>
> 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-19551) CCM nodes share the same environment variable map breaking upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837444#comment-17837444
]
Ariel Weisberg commented on CASSANDRA-19551:
Attached result of running on trunk with a copy of the environment variables
for each node.
One failure is an assertion on some values which looks like an unrelated
problem since the cluster is coming up and working.
Looking into the other failures now. I'll also have baseline nightlies tomorrow.
> CCM nodes share the same environment variable map breaking upgrade tests
>
>
> Key: CASSANDRA-19551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> In {{node.py}} {{__environment_variables}} is generally always set with a map
> that is passed in from {{cluster.py}} so it is [shared between
> nodes](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151)
> and if nodes modify the map, such as in {{start}} when [updating the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860)
> then when {{get_env}} runs it will [overwrite the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244)
> that is selected by {{update_java_version}}.
> This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
> some of the upgrade tests because after the first node upgrades to 4.0 it's
> not longer possible for the subsequent nodes to select a Java version that
> isn't 11 because it's overridden by {{__environment_variables}}.
> I'm not even 100% clear on why the code in {{start}} should update
> {{__environment_variables}} at all if we calculate the correct java version
> on every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (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:comment-tabpanel=17837443#comment-17837443
]
Brandon Williams commented on CASSANDRA-19534:
--
I did run the first workload to populate, and after many minutes cancelled the
larger reads. The last workload has been going now for about an hour without
issue at a steady 10k req/s.
> 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: 5.0-rc, 5.x
>
>
> 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-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:comment-tabpanel=17837437#comment-17837437
]
Jon Haddad commented on CASSANDRA-19534:
[~brandon.williams] not offhand. Are you running the first command to populate
the DB before running both of the other two workloads?
I was able to trigger this very quickly IIRC.
Maybe you need to increase the --rate?
If you can't repro, I'll try it again on my end and I'll give you a full script
to reproduce using easy-cass-lab.
> 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: 5.0-rc, 5.x
>
>
> 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-19551) CCM nodes share the same environment variable map breaking upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-19551:
---
Attachment: ci_summary.html
> CCM nodes share the same environment variable map breaking upgrade tests
>
>
> Key: CASSANDRA-19551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> In {{node.py}} {{__environment_variables}} is generally always set with a map
> that is passed in from {{cluster.py}} so it is [shared between
> nodes](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151)
> and if nodes modify the map, such as in {{start}} when [updating the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860)
> then when {{get_env}} runs it will [overwrite the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244)
> that is selected by {{update_java_version}}.
> This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
> some of the upgrade tests because after the first node upgrades to 4.0 it's
> not longer possible for the subsequent nodes to select a Java version that
> isn't 11 because it's overridden by {{__environment_variables}}.
> I'm not even 100% clear on why the code in {{start}} should update
> {{__environment_variables}} at all if we calculate the correct java version
> on every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-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:comment-tabpanel=17837427#comment-17837427
]
Brandon Williams commented on CASSANDRA-19534:
--
[~rustyrazorblade] do you have more details on how you caused this? I'm not
sure if I need to wait the full 24h but so far I have not seen the same results
using your easy-cass-stress commands on a modest machine with 8 cores and 8G of
ram.
> 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: 5.0-rc, 5.x
>
>
> 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-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:comment-tabpanel=17837419#comment-17837419
]
Alex Petrov commented on CASSANDRA-19534:
-
Sounds good, I'll tag you as soon as I have it up. Thank you [~rustyrazorblade]!
> 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: 5.0-rc, 5.x
>
>
> 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-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:comment-tabpanel=17837417#comment-17837417
]
Jon Haddad commented on CASSANDRA-19534:
I don't have a patch for this, will wait for yours.
Happy to give a perf test when it's done, but we should probably get someone
else to review for correctness.
> 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: 5.0-rc, 5.x
>
>
> 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-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:comment-tabpanel=17837416#comment-17837416
]
Alex Petrov commented on CASSANDRA-19534:
-
[~rustyrazorblade] oh yes, that would exist in a single node as well. Think of
a single node as a case of RF1 and coordinator and replica are colocated. I
have just finished the last wrinkle in my patch, now just need to rebase and
hope to post it ASAP. Hope it's not pressing, but wanted to indicate that
unless you already have a patch for this, probably the quickest way is to check
out what I got as what you describe should be well covered.
> 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: 5.0-rc, 5.x
>
>
> 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-19493) Optionally fail writes when SAI refuses to index a term value exceeding a configured maximum size
[
https://issues.apache.org/jira/browse/CASSANDRA-19493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19493:
Reviewers: Berenguer Blasi, Stefan Miklosovic (was: Berenguer Blasi)
> Optionally fail writes when SAI refuses to index a term value exceeding a
> configured maximum size
> -
>
> Key: CASSANDRA-19493
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19493
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> SAI currently emits a client warning when we try to index a text value larger
> than {{{}cassandra.sai.max_string_term_size{}}}. It might be nice to have a
> hard limit as well, above which we can reject the mutation entirely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-sidecar) branch r/apache/pr109 deleted (was 60d78f2)
This is an automated email from the ASF dual-hosted git repository. ycai pushed a change to branch r/apache/pr109 in repository https://gitbox.apache.org/repos/asf/cassandra-sidecar.git was 60d78f2 feedback This change permanently discards the following revisions: discard 60d78f2 feedback - 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
]
Brandon Williams updated CASSANDRA-19534:
-
Bug Category: Parent values: Availability(12983)
Complexity: Normal
Component/s: Legacy/Local Write-Read Paths
Discovered By: User Report
Fix Version/s: 5.0-rc
5.x
Severity: Normal
Status: Open (was: Triage Needed)
> 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: 5.0-rc, 5.x
>
>
> 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-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:comment-tabpanel=17837406#comment-17837406
]
Jon Haddad commented on CASSANDRA-19534:
In the example I listed, this was a single node, so there were no replicas to
take into account. However, unbounded queues for the other queues are also a
problem, if that's what you meant then I agree.
> 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
>Reporter: Jon Haddad
>Assignee: Alex Petrov
>Priority: Normal
>
> 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-19478) Add CI for python 3.6 back to 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837397#comment-17837397 ] Brandon Williams commented on CASSANDRA-19478: -- Yep, I think that's all that should be necessary. > Add CI for python 3.6 back to 5.0 > - > > Key: CASSANDRA-19478 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19478 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Brandon Williams >Priority: Normal > Fix For: 5.0.x > > > 5.0 doesn't currently run python 3.6 (but branches below it do) however in > CASSANDRA-19467 we have restored python 3.6 support so we should have test > coverage for it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19478) Add CI for python 3.6 back to 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837395#comment-17837395 ] Josh McKenzie commented on CASSANDRA-19478: --- We're talking python version on what, cqlshlib tests only? Makes sense to me for pre-commit smoke suites to check that as well if we still support it, since those suites are lightweight. > Add CI for python 3.6 back to 5.0 > - > > Key: CASSANDRA-19478 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19478 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Brandon Williams >Priority: Normal > Fix For: 5.0.x > > > 5.0 doesn't currently run python 3.6 (but branches below it do) however in > CASSANDRA-19467 we have restored python 3.6 support so we should have test > coverage for it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19559) prepare_release.sh should check for mvn
[ https://issues.apache.org/jira/browse/CASSANDRA-19559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19559: - Test and Documentation Plan: run script Status: Patch Available (was: Open) > prepare_release.sh should check for mvn > --- > > Key: CASSANDRA-19559 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19559 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: NA > > > Part of the 'prepare' phase of releasing includes publishing Maven artifacts, > which requires that it be installed. The script should check for this since > it's quite easy to miss. -- This message was sent by Atlassian Jira (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-19559) prepare_release.sh should check for mvn
[ https://issues.apache.org/jira/browse/CASSANDRA-19559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19559: - Description: Part of the 'prepare' phase of releasing includes publishing Maven artifacts, which requires that it be installed. The script should check for this since it's quite easy to miss. (was: Part of the 'prepare' phase of releasing include publishing Maven artifacts, which requires that it be installed. The script should check for this since it's quite easy to miss.) > prepare_release.sh should check for mvn > --- > > Key: CASSANDRA-19559 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19559 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: NA > > > Part of the 'prepare' phase of releasing includes publishing Maven artifacts, > which requires that it be installed. The script should check for this since > it's quite easy to miss. -- This message was sent by Atlassian Jira (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-19559) prepare_release.sh should check for mvn
Brandon Williams created CASSANDRA-19559: Summary: prepare_release.sh should check for mvn Key: CASSANDRA-19559 URL: https://issues.apache.org/jira/browse/CASSANDRA-19559 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams Part of the 'prepare' phase of releasing include publishing Maven artifacts, which requires that it be installed. The script should check for this since it's quite easy to miss. -- This message was sent by Atlassian Jira (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-19559) prepare_release.sh should check for mvn
[ https://issues.apache.org/jira/browse/CASSANDRA-19559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19559: - Bug Category: Parent values: Correctness(12982) Complexity: Low Hanging Fruit Component/s: Build Discovered By: User Report Fix Version/s: NA Severity: Normal Assignee: Brandon Williams Status: Open (was: Triage Needed) > prepare_release.sh should check for mvn > --- > > Key: CASSANDRA-19559 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19559 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: NA > > > Part of the 'prepare' phase of releasing include publishing Maven artifacts, > which requires that it be installed. The script should check for this since > it's quite easy to miss. -- This message was sent by Atlassian Jira (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] (CASSANDRASC-119) Fix flaky test due to port conflicts
[
https://issues.apache.org/jira/browse/CASSANDRASC-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRASC-119:
--
Fix Version/s: 1.0
Source Control Link:
https://github.com/apache/cassandra-sidecar/commit/686d9e8699bd0a56857e24523d883120023b9841
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Fix flaky test due to port conflicts
>
>
> Key: CASSANDRASC-119
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-119
> Project: Sidecar for Apache Cassandra
> Issue Type: Task
> Components: Rest API
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Labels: pull-request-available
> Fix For: 1.0
>
>
> There are still tests are binding to fixed port number and fail to start
> sidecar server. Proposing a patch to always start test server that binds to
> port 0 with TestServiceConfiguration.
> {code:java}
> ERROR [vert.x-eventloop-thread-2] 2024-04-13 14:17:57,490
> ServerVerticle.java:93 - Failed to deploy Cassandra Sidecar verticle failed
> on socket addresses=[0.0.0.0:9043]
> java.net.BindException: Address already in use
> at java.base/sun.nio.ch.Net.bind0(Native Method)
> at java.base/sun.nio.ch.Net.bind(Net.java:459)
> at java.base/sun.nio.ch.Net.bind(Net.java:448)
> at
> java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:227)
> at
> io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:141)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:562)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:600)
> at
> io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:579)
> at
> io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
> at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260)
> at
> io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:380)
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasksFrom(SingleThreadEventExecutor.java:426)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:375)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:557)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-119) Fix flaky test due to port conflicts
[
https://issues.apache.org/jira/browse/CASSANDRASC-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837362#comment-17837362
]
ASF subversion and git services commented on CASSANDRASC-119:
-
Commit 686d9e8699bd0a56857e24523d883120023b9841 in cassandra-sidecar's branch
refs/heads/trunk from Yifan Cai
[ https://gitbox.apache.org/repos/asf?p=cassandra-sidecar.git;h=686d9e8 ]
CASSANDRASC-119: Fix flaky test due to port conflicts (#113)
Patch by Yifan Cai; Reviewed by Francisco Guerrero for CASSANDRASC-119
> Fix flaky test due to port conflicts
>
>
> Key: CASSANDRASC-119
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-119
> Project: Sidecar for Apache Cassandra
> Issue Type: Task
> Components: Rest API
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Labels: pull-request-available
>
> There are still tests are binding to fixed port number and fail to start
> sidecar server. Proposing a patch to always start test server that binds to
> port 0 with TestServiceConfiguration.
> {code:java}
> ERROR [vert.x-eventloop-thread-2] 2024-04-13 14:17:57,490
> ServerVerticle.java:93 - Failed to deploy Cassandra Sidecar verticle failed
> on socket addresses=[0.0.0.0:9043]
> java.net.BindException: Address already in use
> at java.base/sun.nio.ch.Net.bind0(Native Method)
> at java.base/sun.nio.ch.Net.bind(Net.java:459)
> at java.base/sun.nio.ch.Net.bind(Net.java:448)
> at
> java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:227)
> at
> io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:141)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:562)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:600)
> at
> io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:579)
> at
> io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
> at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260)
> at
> io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:380)
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasksFrom(SingleThreadEventExecutor.java:426)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:375)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:557)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-119) Fix flaky test due to port conflicts
[
https://issues.apache.org/jira/browse/CASSANDRASC-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRASC-119:
--
Status: Ready to Commit (was: Review In Progress)
> Fix flaky test due to port conflicts
>
>
> Key: CASSANDRASC-119
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-119
> Project: Sidecar for Apache Cassandra
> Issue Type: Task
> Components: Rest API
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Labels: pull-request-available
>
> There are still tests are binding to fixed port number and fail to start
> sidecar server. Proposing a patch to always start test server that binds to
> port 0 with TestServiceConfiguration.
> {code:java}
> ERROR [vert.x-eventloop-thread-2] 2024-04-13 14:17:57,490
> ServerVerticle.java:93 - Failed to deploy Cassandra Sidecar verticle failed
> on socket addresses=[0.0.0.0:9043]
> java.net.BindException: Address already in use
> at java.base/sun.nio.ch.Net.bind0(Native Method)
> at java.base/sun.nio.ch.Net.bind(Net.java:459)
> at java.base/sun.nio.ch.Net.bind(Net.java:448)
> at
> java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:227)
> at
> io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:141)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:562)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:600)
> at
> io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:579)
> at
> io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
> at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260)
> at
> io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:380)
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasksFrom(SingleThreadEventExecutor.java:426)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:375)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:557)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-sidecar) branch trunk updated: CASSANDRASC-119: Fix flaky test due to port conflicts (#113)
This is an automated email from the ASF dual-hosted git repository.
ycai pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-sidecar.git
The following commit(s) were added to refs/heads/trunk by this push:
new 686d9e86 CASSANDRASC-119: Fix flaky test due to port conflicts (#113)
686d9e86 is described below
commit 686d9e8699bd0a56857e24523d883120023b9841
Author: Yifan Cai <52585731+yifa...@users.noreply.github.com>
AuthorDate: Mon Apr 15 09:48:59 2024 -0700
CASSANDRASC-119: Fix flaky test due to port conflicts (#113)
Patch by Yifan Cai; Reviewed by Francisco Guerrero for CASSANDRASC-119
---
.../apache/cassandra/sidecar/server/Server.java| 5 ++-
.../cassandra/sidecar/server/ServerVerticle.java | 5 ++-
.../sidecar/testing/IntegrationTestModule.java | 6 +--
.../cassandra/sidecar/ExecutorPoolsHelper.java | 4 +-
.../org/apache/cassandra/sidecar/TestModule.java | 6 +--
.../sstableuploads/BaseUploadsHandlerTest.java | 8 ++--
.../cassandra/sidecar/server/ServerSSLTest.java| 46 +-
.../cassandra/sidecar/utils/CacheFactoryTest.java | 4 +-
.../sidecar/utils/SSTableImporterTest.java | 6 +--
.../config/yaml/TestServiceConfiguration.java | 41 +++
10 files changed, 71 insertions(+), 60 deletions(-)
diff --git a/src/main/java/org/apache/cassandra/sidecar/server/Server.java
b/src/main/java/org/apache/cassandra/sidecar/server/Server.java
index 51b67b2d..d6bd652f 100644
--- a/src/main/java/org/apache/cassandra/sidecar/server/Server.java
+++ b/src/main/java/org/apache/cassandra/sidecar/server/Server.java
@@ -208,14 +208,15 @@ public class Server
/**
* Expose the port of the first deployed verticle for testing purposes
*
- * @return the port where the first verticle is deployed, or -1 if the
server has not been deployed
+ * @return the port where the first verticle is deployed
+ * @throws IllegalStateException if the server has not been deployed
*/
@VisibleForTesting
public int actualPort()
{
if (!deployedServerVerticles.isEmpty())
return deployedServerVerticles.get(0).actualPort();
-return -1;
+throw new IllegalStateException("No deployed server verticles. Maybe
server failed to deploy due to port conflict");
}
protected Future notifyServerStart(String deploymentId)
diff --git
a/src/main/java/org/apache/cassandra/sidecar/server/ServerVerticle.java
b/src/main/java/org/apache/cassandra/sidecar/server/ServerVerticle.java
index 109b3695..54ca7041 100644
--- a/src/main/java/org/apache/cassandra/sidecar/server/ServerVerticle.java
+++ b/src/main/java/org/apache/cassandra/sidecar/server/ServerVerticle.java
@@ -131,13 +131,14 @@ public class ServerVerticle extends AbstractVerticle
}
/**
- * @return the actual port of the first deployed server, or -1 if no
servers are deployed
+ * @return the actual port of the first deployed server
+ * @throws IllegalStateException if no servers are deployed
*/
@VisibleForTesting
int actualPort()
{
if (deployedServers != null && !deployedServers.isEmpty())
return deployedServers.get(0).actualPort();
-return -1;
+throw new IllegalStateException("No deployed server. Maybe server
failed to deploy due to port conflict");
}
}
diff --git
a/src/test/integration/org/apache/cassandra/sidecar/testing/IntegrationTestModule.java
b/src/test/integration/org/apache/cassandra/sidecar/testing/IntegrationTestModule.java
index d0c069d5..5a5deadc 100644
---
a/src/test/integration/org/apache/cassandra/sidecar/testing/IntegrationTestModule.java
+++
b/src/test/integration/org/apache/cassandra/sidecar/testing/IntegrationTestModule.java
@@ -37,8 +37,8 @@ import
org.apache.cassandra.sidecar.config.ServiceConfiguration;
import org.apache.cassandra.sidecar.config.SidecarConfiguration;
import org.apache.cassandra.sidecar.config.yaml.HealthCheckConfigurationImpl;
import
org.apache.cassandra.sidecar.config.yaml.SchemaKeyspaceConfigurationImpl;
-import org.apache.cassandra.sidecar.config.yaml.ServiceConfigurationImpl;
import org.apache.cassandra.sidecar.config.yaml.SidecarConfigurationImpl;
+import org.apache.cassandra.sidecar.config.yaml.TestServiceConfiguration;
import org.jetbrains.annotations.NotNull;
import static
org.apache.cassandra.sidecar.server.SidecarServerEvents.ON_SERVER_STOP;
@@ -67,9 +67,7 @@ public class IntegrationTestModule extends AbstractModule
public SidecarConfiguration configuration()
{
ServiceConfiguration conf
-= ServiceConfigurationImpl.builder()
- .host("127.0.0.1")
- .port(0) // let the test find an available
port
+= TestServiceConfiguration.builder()
[jira] [Updated] (CASSANDRASC-119) Fix flaky test due to port conflicts
[
https://issues.apache.org/jira/browse/CASSANDRASC-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRASC-119:
---
Reviewers: Francisco Guerrero
Status: Review In Progress (was: Patch Available)
> Fix flaky test due to port conflicts
>
>
> Key: CASSANDRASC-119
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-119
> Project: Sidecar for Apache Cassandra
> Issue Type: Task
> Components: Rest API
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Labels: pull-request-available
>
> There are still tests are binding to fixed port number and fail to start
> sidecar server. Proposing a patch to always start test server that binds to
> port 0 with TestServiceConfiguration.
> {code:java}
> ERROR [vert.x-eventloop-thread-2] 2024-04-13 14:17:57,490
> ServerVerticle.java:93 - Failed to deploy Cassandra Sidecar verticle failed
> on socket addresses=[0.0.0.0:9043]
> java.net.BindException: Address already in use
> at java.base/sun.nio.ch.Net.bind0(Native Method)
> at java.base/sun.nio.ch.Net.bind(Net.java:459)
> at java.base/sun.nio.ch.Net.bind(Net.java:448)
> at
> java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:227)
> at
> io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:141)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:562)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:600)
> at
> io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:579)
> at
> io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
> at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260)
> at
> io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:380)
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasksFrom(SingleThreadEventExecutor.java:426)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:375)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:557)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-119) Fix flaky test due to port conflicts
[
https://issues.apache.org/jira/browse/CASSANDRASC-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837360#comment-17837360
]
Francisco Guerrero commented on CASSANDRASC-119:
+1 Thanks for the fix
> Fix flaky test due to port conflicts
>
>
> Key: CASSANDRASC-119
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-119
> Project: Sidecar for Apache Cassandra
> Issue Type: Task
> Components: Rest API
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Labels: pull-request-available
>
> There are still tests are binding to fixed port number and fail to start
> sidecar server. Proposing a patch to always start test server that binds to
> port 0 with TestServiceConfiguration.
> {code:java}
> ERROR [vert.x-eventloop-thread-2] 2024-04-13 14:17:57,490
> ServerVerticle.java:93 - Failed to deploy Cassandra Sidecar verticle failed
> on socket addresses=[0.0.0.0:9043]
> java.net.BindException: Address already in use
> at java.base/sun.nio.ch.Net.bind0(Native Method)
> at java.base/sun.nio.ch.Net.bind(Net.java:459)
> at java.base/sun.nio.ch.Net.bind(Net.java:448)
> at
> java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:227)
> at
> io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:141)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:562)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:600)
> at
> io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:579)
> at
> io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
> at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260)
> at
> io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:380)
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasksFrom(SingleThreadEventExecutor.java:426)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:375)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:557)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-119) Fix flaky test due to port conflicts
[
https://issues.apache.org/jira/browse/CASSANDRASC-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRASC-119:
--
Test and Documentation Plan: unit; ci
Status: Patch Available (was: Open)
> Fix flaky test due to port conflicts
>
>
> Key: CASSANDRASC-119
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-119
> Project: Sidecar for Apache Cassandra
> Issue Type: Task
> Components: Rest API
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Labels: pull-request-available
>
> There are still tests are binding to fixed port number and fail to start
> sidecar server. Proposing a patch to always start test server that binds to
> port 0 with TestServiceConfiguration.
> {code:java}
> ERROR [vert.x-eventloop-thread-2] 2024-04-13 14:17:57,490
> ServerVerticle.java:93 - Failed to deploy Cassandra Sidecar verticle failed
> on socket addresses=[0.0.0.0:9043]
> java.net.BindException: Address already in use
> at java.base/sun.nio.ch.Net.bind0(Native Method)
> at java.base/sun.nio.ch.Net.bind(Net.java:459)
> at java.base/sun.nio.ch.Net.bind(Net.java:448)
> at
> java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:227)
> at
> io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:141)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:562)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:600)
> at
> io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:579)
> at
> io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
> at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260)
> at
> io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:380)
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasksFrom(SingleThreadEventExecutor.java:426)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:375)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:557)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-dtest) branch trunk updated: increment 3.0 version for upgrades
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git The following commit(s) were added to refs/heads/trunk by this push: new ac32ff9f increment 3.0 version for upgrades ac32ff9f is described below commit ac32ff9fc4868cc0f354ca90cbaa322e3f87716b Author: Brandon Williams AuthorDate: Mon Apr 15 11:27:38 2024 -0500 increment 3.0 version for upgrades --- upgrade_tests/upgrade_manifest.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/upgrade_tests/upgrade_manifest.py b/upgrade_tests/upgrade_manifest.py index 5237ef74..760255ed 100644 --- a/upgrade_tests/upgrade_manifest.py +++ b/upgrade_tests/upgrade_manifest.py @@ -163,7 +163,7 @@ indev_2_2_x = VersionMeta(name='indev_2_2_x', family=CASSANDRA_2_2, variant='ind current_2_2_x = VersionMeta(name='current_2_2_x', family=CASSANDRA_2_2, variant='current', version='2.2.19', min_proto_v=1, max_proto_v=3, java_versions=(7, 8)) indev_3_0_x = VersionMeta(name='indev_3_0_x', family=CASSANDRA_3_0, variant='indev', version='github:apache/cassandra-3.0', min_proto_v=3, max_proto_v=4, java_versions=(8,)) -current_3_0_x = VersionMeta(name='current_3_0_x', family=CASSANDRA_3_0, variant='current', version='3.0.29', min_proto_v=3, max_proto_v=4, java_versions=(8,)) +current_3_0_x = VersionMeta(name='current_3_0_x', family=CASSANDRA_3_0, variant='current', version='3.0.30', min_proto_v=3, max_proto_v=4, java_versions=(8,)) indev_3_11_x = VersionMeta(name='indev_3_11_x', family=CASSANDRA_3_11, variant='indev', version='github:apache/cassandra-3.11', min_proto_v=3, max_proto_v=4, java_versions=(8,)) current_3_11_x = VersionMeta(name='current_3_11_x', family=CASSANDRA_3_11, variant='current', version='3.11.16', min_proto_v=3, max_proto_v=4, java_versions=(8,)) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/01: Merge branch 'cassandra-5.0' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 9abd84b8f8735ac5f884d963847b0eb61ce26e5c Merge: 74aa4a12ad e127ddf7dd Author: Brandon Williams AuthorDate: Mon Apr 15 11:25:41 2024 -0500 Merge branch 'cassandra-5.0' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/01: Merge branch 'cassandra-4.0' into cassandra-4.1
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit a6209d0cfc22c7688cbe5a87c9c75a33230157e1 Merge: b525f5fff4 53f07f9610 Author: Brandon Williams AuthorDate: Mon Apr 15 11:25:24 2024 -0500 Merge branch 'cassandra-4.0' into cassandra-4.1 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 53f07f96103959c69c7fa4144eb9b1fe56fd194d Merge: fd46d400b5 7af7f42f5f Author: Brandon Williams AuthorDate: Mon Apr 15 11:25:18 2024 -0500 Merge branch 'cassandra-3.11' into cassandra-4.0 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-5.0 updated (42498a14fa -> e127ddf7dd)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-5.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 42498a14fa Merge branch 'cassandra-4.1' into cassandra-5.0 new 44f472d742 Increment version new 7af7f42f5f Merge branch 'cassandra-3.0' into cassandra-3.11 new 53f07f9610 Merge branch 'cassandra-3.11' into cassandra-4.0 new a6209d0cfc Merge branch 'cassandra-4.0' into cassandra-4.1 new e127ddf7dd Merge branch 'cassandra-4.1' into cassandra-5.0 The 5 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-4.1 updated (b525f5fff4 -> a6209d0cfc)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from b525f5fff4 Merge branch 'cassandra-4.0' into cassandra-4.1 new 44f472d742 Increment version new 7af7f42f5f Merge branch 'cassandra-3.0' into cassandra-3.11 new 53f07f9610 Merge branch 'cassandra-3.11' into cassandra-4.0 new a6209d0cfc Merge branch 'cassandra-4.0' into cassandra-4.1 The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-3.0 updated: Increment version
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-3.0 by this push: new 44f472d742 Increment version 44f472d742 is described below commit 44f472d742d5ce71c226790fe92e6b75af70b5a1 Author: Brandon Williams AuthorDate: Mon Apr 15 11:24:55 2024 -0500 Increment version --- CHANGES.txt | 3 +++ build.xml | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/CHANGES.txt b/CHANGES.txt index 7e28aed561..f82ddbc4b3 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,3 +1,6 @@ +3.0.31 + * + 3.0.30 * Fix SCM URL link (CASSANDRA-19422) * Backport CASSANDRA-16418 to 3.x (CASSANDRA-18824) diff --git a/build.xml b/build.xml index 40590764e9..7bcfb3e17c 100644 --- a/build.xml +++ b/build.xml @@ -34,7 +34,7 @@ - + https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf?p=cassandra.git"/> - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/01: Merge branch 'cassandra-4.1' into cassandra-5.0
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-5.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit e127ddf7dd26143701f20d65328ec87c009731fc Merge: 42498a14fa a6209d0cfc Author: Brandon Williams AuthorDate: Mon Apr 15 11:25:34 2024 -0500 Merge branch 'cassandra-4.1' into cassandra-5.0 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch trunk updated (74aa4a12ad -> 9abd84b8f8)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 74aa4a12ad Merge branch 'cassandra-5.0' into trunk new 44f472d742 Increment version new 7af7f42f5f Merge branch 'cassandra-3.0' into cassandra-3.11 new 53f07f9610 Merge branch 'cassandra-3.11' into cassandra-4.0 new a6209d0cfc Merge branch 'cassandra-4.0' into cassandra-4.1 new e127ddf7dd Merge branch 'cassandra-4.1' into cassandra-5.0 new 9abd84b8f8 Merge branch 'cassandra-5.0' into trunk The 6 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-4.0 updated (fd46d400b5 -> 53f07f9610)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from fd46d400b5 Merge branch 'cassandra-3.11' into cassandra-4.0 new 44f472d742 Increment version new 7af7f42f5f Merge branch 'cassandra-3.0' into cassandra-3.11 new 53f07f9610 Merge branch 'cassandra-3.11' into cassandra-4.0 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 7af7f42f5f6e8b7ccf05790a17c0e317015240d5 Merge: d079952c50 44f472d742 Author: Brandon Williams AuthorDate: Mon Apr 15 11:25:11 2024 -0500 Merge branch 'cassandra-3.0' into cassandra-3.11 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-3.11 updated (d079952c50 -> 7af7f42f5f)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from d079952c50 Prepare debian changelog for 3.11.17 new 44f472d742 Increment version new 7af7f42f5f Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r68540 - /release/cassandra/3.0.29/
Author: brandonwilliams Date: Mon Apr 15 16:23:48 2024 New Revision: 68540 Log: Remove old version Removed: release/cassandra/3.0.29/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18736) Streaming exception race creates corrupt transaction log files that prevent restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837338#comment-17837338
]
Ekaterina Dimitrova commented on CASSANDRA-18736:
-
Hey [~jonmeredith], I haven't tried myself, but I have people telling me they
reproduced the issue on 4.0.
I can try to ask for more details if that will help you.
> Streaming exception race creates corrupt transaction log files that prevent
> restart
> ---
>
> Key: CASSANDRA-18736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18736
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/Startup and Shutdown
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> On restart, Cassandra logs this message and terminates.
> {code:java}
> ERROR 2023-07-17T17:17:22,931 [main]
> org.apache.cassandra.db.lifecycle.LogTransaction:561 - Unexpected disk state:
> failed to read transaction log
> [nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log in
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043]
> Files and contents follow:
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log
> ABORT:[,0,0][737437348]
> ***This record should have been the last one in all replicas
>
> ADD:[/datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb-284490-big-,0,8][2493503833]
> {code}
> The root cause is a race during streaming exception handling.
> Although concurrent modification of to the {{LogTransaction}} was added for
> CASSANDRA-16225, there is nothing to prevent usage after the transaction is
> completed (committed/aborted) once it has been processed by
> {{TransactionTidier}} (after the last reference is released). Before the
> transaction is tidied, the {{LogFile}} keeps a list of records that are
> checked for completion before adding new entries. In {{TransactionTidier}}
> {{LogFile.records}} are cleared as no longer needed, however the
> LogTransaction/LogFile is still accessible to the stream.
> The changes in CASSANDRA-17273 added a parallel set of {{onDiskRecords}} that
> could be used to reliably recreate the transaction log at any new datadirs
> the same as the existing
> datadirs - regardless of the effect of
> {{LogTransaction.untrackNew/LogFile.remove}}
> If a streaming exception causes the LogTransaction to be aborted and tidied
> just before {{SimpleSSTableMultiWriter}} calls trackNew to add a new sstable.
> At the time of the call, the {{LogFile}} will not contain any {{LogReplicas}},
> {{LogFile.records}} will be empty, and {{LogFile.onDiskRecords}} will contain
> an {{ABORT}}.
> When {{LogTransaction.trackNew/LogFile.add}} is called, the check for
> completed transaction fails as records is empty, there are no replicas on the
> datadir, so {{maybeCreateReplicas}} creates a new txnlog file replica
> containing ABORT, then
> appends an ADD record.
> The LogFile has already been tidied after the abort so the txnlog file is not
> removed and sits on disk until a restart, causing the faiulre.
> There is a related exception caused with a different interleaving of aborts,
> after an sstable is added, however this is just a nuisance in the logs as the
> LogRelica is already created with an {{ADD}} record first.
> {code:java}
> java.lang.AssertionError:
> [ADD:[/datadir1/keyspace/table/nb-23314378-big-,0,8][1869379820]] is not
> tracked by 55be35b0-35d1-11ee-865d-8b1e3c48ca06
> at org.apache.cassandra.db.lifecycle.LogFile.remove(LogFile.java:388)
> at
> org.apache.cassandra.db.lifecycle.LogTransaction.untrackNew(LogTransaction.java:158)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.untrackNew(LifecycleTransaction.java:577)
> at
> org.apache.cassandra.db.streaming.CassandraStreamReceiver$1.untrackNew(CassandraStreamReceiver.java:149)
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.abort(SimpleSSTableMultiWriter.java:95)
> at
> org.apache.cassandra.io.sstable.format.RangeAwareSSTableWriter.abort(RangeAwareSSTableWriter.java:191)
> at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamReader.read(CassandraCompressedStreamReader.java:115)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:85)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:53)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:38)
> at
>
(cassandra-website) branch asf-staging updated (8a61c43a -> 955e8c2f)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 8a61c43a generate docs for 3774363b add 607350d3 Minor release 3.0.30 new 955e8c2f generate docs for 607350d3 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (8a61c43a) \ N -- N -- N refs/heads/asf-staging (955e8c2f) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/_/download.html| 8 content/search-index.js| 2 +- .../source/modules/ROOT/pages/download.adoc| 8 site-ui/build/ui-bundle.zip| Bin 4883646 -> 4883646 bytes 4 files changed, 9 insertions(+), 9 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-18736) Streaming exception race creates corrupt transaction log files that prevent restart
[ https://issues.apache.org/jira/browse/CASSANDRA-18736 ]
Jon Meredith deleted comment on CASSANDRA-18736:
--
was (Author: jonmeredith):
Trunk [PR|https://github.com/apache/cassandra/pull/2565]
[Branch|https://github.com/jonmeredith/cassandra/tree/C18733-trunk]
[5.0 Branch|https://github.com/jonmeredith/cassandra/tree/C18733-5.0]
Only minor difference is no \{{StreamSession.failureReason}}
[4.1 Branch|https://github.com/jonmeredith/cassandra/tree/C18733-4.1]
> Streaming exception race creates corrupt transaction log files that prevent
> restart
> ---
>
> Key: CASSANDRA-18736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18736
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/Startup and Shutdown
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> On restart, Cassandra logs this message and terminates.
> {code:java}
> ERROR 2023-07-17T17:17:22,931 [main]
> org.apache.cassandra.db.lifecycle.LogTransaction:561 - Unexpected disk state:
> failed to read transaction log
> [nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log in
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043]
> Files and contents follow:
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log
> ABORT:[,0,0][737437348]
> ***This record should have been the last one in all replicas
>
> ADD:[/datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb-284490-big-,0,8][2493503833]
> {code}
> The root cause is a race during streaming exception handling.
> Although concurrent modification of to the {{LogTransaction}} was added for
> CASSANDRA-16225, there is nothing to prevent usage after the transaction is
> completed (committed/aborted) once it has been processed by
> {{TransactionTidier}} (after the last reference is released). Before the
> transaction is tidied, the {{LogFile}} keeps a list of records that are
> checked for completion before adding new entries. In {{TransactionTidier}}
> {{LogFile.records}} are cleared as no longer needed, however the
> LogTransaction/LogFile is still accessible to the stream.
> The changes in CASSANDRA-17273 added a parallel set of {{onDiskRecords}} that
> could be used to reliably recreate the transaction log at any new datadirs
> the same as the existing
> datadirs - regardless of the effect of
> {{LogTransaction.untrackNew/LogFile.remove}}
> If a streaming exception causes the LogTransaction to be aborted and tidied
> just before {{SimpleSSTableMultiWriter}} calls trackNew to add a new sstable.
> At the time of the call, the {{LogFile}} will not contain any {{LogReplicas}},
> {{LogFile.records}} will be empty, and {{LogFile.onDiskRecords}} will contain
> an {{ABORT}}.
> When {{LogTransaction.trackNew/LogFile.add}} is called, the check for
> completed transaction fails as records is empty, there are no replicas on the
> datadir, so {{maybeCreateReplicas}} creates a new txnlog file replica
> containing ABORT, then
> appends an ADD record.
> The LogFile has already been tidied after the abort so the txnlog file is not
> removed and sits on disk until a restart, causing the faiulre.
> There is a related exception caused with a different interleaving of aborts,
> after an sstable is added, however this is just a nuisance in the logs as the
> LogRelica is already created with an {{ADD}} record first.
> {code:java}
> java.lang.AssertionError:
> [ADD:[/datadir1/keyspace/table/nb-23314378-big-,0,8][1869379820]] is not
> tracked by 55be35b0-35d1-11ee-865d-8b1e3c48ca06
> at org.apache.cassandra.db.lifecycle.LogFile.remove(LogFile.java:388)
> at
> org.apache.cassandra.db.lifecycle.LogTransaction.untrackNew(LogTransaction.java:158)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.untrackNew(LifecycleTransaction.java:577)
> at
> org.apache.cassandra.db.streaming.CassandraStreamReceiver$1.untrackNew(CassandraStreamReceiver.java:149)
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.abort(SimpleSSTableMultiWriter.java:95)
> at
> org.apache.cassandra.io.sstable.format.RangeAwareSSTableWriter.abort(RangeAwareSSTableWriter.java:191)
> at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamReader.read(CassandraCompressedStreamReader.java:115)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:85)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:53)
> at
>
[jira] [Commented] (CASSANDRA-18736) Streaming exception race creates corrupt transaction log files that prevent restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837333#comment-17837333
]
Jon Meredith commented on CASSANDRA-18736:
--
I'm double-checking at the moment. I think the bug became an issue after some
restructuring for the simulator, but need to convince myself of that.
Also, I've deleted the original branches/PRs as I accidentally referenced ones
from a different fix. I'll post new ones in a day or so.
> Streaming exception race creates corrupt transaction log files that prevent
> restart
> ---
>
> Key: CASSANDRA-18736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18736
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/Startup and Shutdown
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> On restart, Cassandra logs this message and terminates.
> {code:java}
> ERROR 2023-07-17T17:17:22,931 [main]
> org.apache.cassandra.db.lifecycle.LogTransaction:561 - Unexpected disk state:
> failed to read transaction log
> [nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log in
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043]
> Files and contents follow:
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log
> ABORT:[,0,0][737437348]
> ***This record should have been the last one in all replicas
>
> ADD:[/datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb-284490-big-,0,8][2493503833]
> {code}
> The root cause is a race during streaming exception handling.
> Although concurrent modification of to the {{LogTransaction}} was added for
> CASSANDRA-16225, there is nothing to prevent usage after the transaction is
> completed (committed/aborted) once it has been processed by
> {{TransactionTidier}} (after the last reference is released). Before the
> transaction is tidied, the {{LogFile}} keeps a list of records that are
> checked for completion before adding new entries. In {{TransactionTidier}}
> {{LogFile.records}} are cleared as no longer needed, however the
> LogTransaction/LogFile is still accessible to the stream.
> The changes in CASSANDRA-17273 added a parallel set of {{onDiskRecords}} that
> could be used to reliably recreate the transaction log at any new datadirs
> the same as the existing
> datadirs - regardless of the effect of
> {{LogTransaction.untrackNew/LogFile.remove}}
> If a streaming exception causes the LogTransaction to be aborted and tidied
> just before {{SimpleSSTableMultiWriter}} calls trackNew to add a new sstable.
> At the time of the call, the {{LogFile}} will not contain any {{LogReplicas}},
> {{LogFile.records}} will be empty, and {{LogFile.onDiskRecords}} will contain
> an {{ABORT}}.
> When {{LogTransaction.trackNew/LogFile.add}} is called, the check for
> completed transaction fails as records is empty, there are no replicas on the
> datadir, so {{maybeCreateReplicas}} creates a new txnlog file replica
> containing ABORT, then
> appends an ADD record.
> The LogFile has already been tidied after the abort so the txnlog file is not
> removed and sits on disk until a restart, causing the faiulre.
> There is a related exception caused with a different interleaving of aborts,
> after an sstable is added, however this is just a nuisance in the logs as the
> LogRelica is already created with an {{ADD}} record first.
> {code:java}
> java.lang.AssertionError:
> [ADD:[/datadir1/keyspace/table/nb-23314378-big-,0,8][1869379820]] is not
> tracked by 55be35b0-35d1-11ee-865d-8b1e3c48ca06
> at org.apache.cassandra.db.lifecycle.LogFile.remove(LogFile.java:388)
> at
> org.apache.cassandra.db.lifecycle.LogTransaction.untrackNew(LogTransaction.java:158)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.untrackNew(LifecycleTransaction.java:577)
> at
> org.apache.cassandra.db.streaming.CassandraStreamReceiver$1.untrackNew(CassandraStreamReceiver.java:149)
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.abort(SimpleSSTableMultiWriter.java:95)
> at
> org.apache.cassandra.io.sstable.format.RangeAwareSSTableWriter.abort(RangeAwareSSTableWriter.java:191)
> at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamReader.read(CassandraCompressedStreamReader.java:115)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:85)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:53)
> at
>
(cassandra-website) branch trunk updated: Minor release 3.0.30
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new 607350d3 Minor release 3.0.30 607350d3 is described below commit 607350d348359bd7e32ac6218359eebb74165322 Author: Brandon Williams AuthorDate: Mon Apr 15 10:42:54 2024 -0500 Minor release 3.0.30 https://lists.apache.org/thread/flg3w0s5b7xvdz0zs42o8rp1cfbwr5ls --- site-content/source/modules/ROOT/pages/download.adoc | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/site-content/source/modules/ROOT/pages/download.adoc b/site-content/source/modules/ROOT/pages/download.adoc index 8d1267a0..ad04d53d 100644 --- a/site-content/source/modules/ROOT/pages/download.adoc +++ b/site-content/source/modules/ROOT/pages/download.adoc @@ -100,15 +100,15 @@ https://www.apache.org/dyn/closer.lua/cassandra/3.11.16/apache-cassandra-3.11.16 [discrete] Apache Cassandra 3.0 [discrete] - Latest release on 2023-05-15 + Latest release on 2024-04-15 [discrete] Maintained until 5.0.0 release (Nov-Dec 2023) [.btn.btn--alt] -https://www.apache.org/dyn/closer.lua/cassandra/3.0.29/apache-cassandra-3.0.29-bin.tar.gz[3.0.29,window=blank] +https://www.apache.org/dyn/closer.lua/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz[3.0.30,window=blank] -(https://downloads.apache.org/cassandra/3.0.29/apache-cassandra-3.0.29-bin.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/3.0.29/apache-cassandra-3.0.29-bin.tar.gz.sha256[sha256,window=blank], https://downloads.apache.org/cassandra/3.0.29/apache-cassandra-3.0.29-bin.tar.gz.sha512[sha512,window=blank]) + -(https://www.apache.org/dyn/closer.lua/cassandra/3.0.29/apache-cassandra-3.0.29-src.tar.gz[source,window=blank]: https://downloads.apache.org/cassandra/3.0.29/apache-cassandra-3.0.29-src.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/3.0.29/apache-cassandra-3.0.29-src.tar.gz.sha256[sha256,window=blank], https://downloads.apache.org/cassandra/3.0.29/apache-cassandra-3.0.29-src.tar.gz.sha512[sha512,window=blank]) +(https://downloads.apache.org/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha256[sha256,window=blank], https://downloads.apache.org/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha512[sha512,window=blank]) + +(https://www.apache.org/dyn/closer.lua/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz[source,window=blank]: https://downloads.apache.org/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.sha256[sha256,window=blank], https://downloads.apache.org/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.sha512[sha512,window=blank]) -- [openblock, inline100 inline-top] - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r68535 - /release/cassandra/3.0.30/redhat/
Author: brandonwilliams Date: Mon Apr 15 15:21:57 2024 New Revision: 68535 Log: Apache Cassandra 3.0.30 redhat artifacts Removed: release/cassandra/3.0.30/redhat/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r68534 - /release/cassandra/3.0.30/debian/
Author: brandonwilliams Date: Mon Apr 15 15:21:27 2024 New Revision: 68534 Log: Apache Cassandra 3.0.30 debian artifacts Removed: release/cassandra/3.0.30/debian/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) annotated tag cassandra-3.0.30 created (now 9da39173e2)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to annotated tag cassandra-3.0.30 in repository https://gitbox.apache.org/repos/asf/cassandra.git at 9da39173e2 (tag) tagging 657e595b78227c28a6b8808ef9bf62f646029f3b (commit) replaces cassandra-3.0.29 by Brandon Williams on Mon Apr 15 10:20:35 2024 -0500 - Log - Apache Cassandra 3.0.30 release --- No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r68533 - /dev/cassandra/3.0.30/ /release/cassandra/3.0.30/
Author: brandonwilliams Date: Mon Apr 15 15:20:46 2024 New Revision: 68533 Log: Apache Cassandra 3.0.30 release Added: release/cassandra/3.0.30/ - copied from r68532, dev/cassandra/3.0.30/ Removed: dev/cassandra/3.0.30/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) tag 3.0.30-tentative deleted (was 657e595b78)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git *** WARNING: tag 3.0.30-tentative was deleted! *** was 657e595b78 Prepare debian changelog for 3.0.30 The revisions that were on this tag are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18736) Streaming exception race creates corrupt transaction log files that prevent restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837291#comment-17837291
]
Ekaterina Dimitrova commented on CASSANDRA-18736:
-
[~jonmeredith] , the fix versions mention 4.0, but I do not see a branch for
it. Do you plan to apply it on that branch too?
> Streaming exception race creates corrupt transaction log files that prevent
> restart
> ---
>
> Key: CASSANDRA-18736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18736
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/Startup and Shutdown
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> On restart, Cassandra logs this message and terminates.
> {code:java}
> ERROR 2023-07-17T17:17:22,931 [main]
> org.apache.cassandra.db.lifecycle.LogTransaction:561 - Unexpected disk state:
> failed to read transaction log
> [nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log in
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043]
> Files and contents follow:
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log
> ABORT:[,0,0][737437348]
> ***This record should have been the last one in all replicas
>
> ADD:[/datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb-284490-big-,0,8][2493503833]
> {code}
> The root cause is a race during streaming exception handling.
> Although concurrent modification of to the {{LogTransaction}} was added for
> CASSANDRA-16225, there is nothing to prevent usage after the transaction is
> completed (committed/aborted) once it has been processed by
> {{TransactionTidier}} (after the last reference is released). Before the
> transaction is tidied, the {{LogFile}} keeps a list of records that are
> checked for completion before adding new entries. In {{TransactionTidier}}
> {{LogFile.records}} are cleared as no longer needed, however the
> LogTransaction/LogFile is still accessible to the stream.
> The changes in CASSANDRA-17273 added a parallel set of {{onDiskRecords}} that
> could be used to reliably recreate the transaction log at any new datadirs
> the same as the existing
> datadirs - regardless of the effect of
> {{LogTransaction.untrackNew/LogFile.remove}}
> If a streaming exception causes the LogTransaction to be aborted and tidied
> just before {{SimpleSSTableMultiWriter}} calls trackNew to add a new sstable.
> At the time of the call, the {{LogFile}} will not contain any {{LogReplicas}},
> {{LogFile.records}} will be empty, and {{LogFile.onDiskRecords}} will contain
> an {{ABORT}}.
> When {{LogTransaction.trackNew/LogFile.add}} is called, the check for
> completed transaction fails as records is empty, there are no replicas on the
> datadir, so {{maybeCreateReplicas}} creates a new txnlog file replica
> containing ABORT, then
> appends an ADD record.
> The LogFile has already been tidied after the abort so the txnlog file is not
> removed and sits on disk until a restart, causing the faiulre.
> There is a related exception caused with a different interleaving of aborts,
> after an sstable is added, however this is just a nuisance in the logs as the
> LogRelica is already created with an {{ADD}} record first.
> {code:java}
> java.lang.AssertionError:
> [ADD:[/datadir1/keyspace/table/nb-23314378-big-,0,8][1869379820]] is not
> tracked by 55be35b0-35d1-11ee-865d-8b1e3c48ca06
> at org.apache.cassandra.db.lifecycle.LogFile.remove(LogFile.java:388)
> at
> org.apache.cassandra.db.lifecycle.LogTransaction.untrackNew(LogTransaction.java:158)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.untrackNew(LifecycleTransaction.java:577)
> at
> org.apache.cassandra.db.streaming.CassandraStreamReceiver$1.untrackNew(CassandraStreamReceiver.java:149)
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.abort(SimpleSSTableMultiWriter.java:95)
> at
> org.apache.cassandra.io.sstable.format.RangeAwareSSTableWriter.abort(RangeAwareSSTableWriter.java:191)
> at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamReader.read(CassandraCompressedStreamReader.java:115)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:85)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:53)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:38)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:53)
>
[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=17837237#comment-17837237
]
Alex Petrov commented on CASSANDRA-12937:
-
bq. Yes, I think this is the most ideal solution. If somebody wants to
experiment with a new compressor and similar, there would need to be some knob
to override it, like some JMX method or similar, and all risks attached to that
(divergence of the configuration caused by operator's negligence) would be on
him.
Some things are actually quite useful for gradual rollout. For example,
compression. You probably do not want to rewrite your sstables across the
entire cluster. Similar arguments may be made for canary deployments of
memtable settings and other things.
I agree that it is fine if these parameters are completely transient (i.e. if
you have set it to something that diverges from the clusterwide value, it will
get reverted back after the node bounce). In such case, probably they will not
go through TCM and will be purely node-local.
Examples of things that are now configuable via yaml but will be configurable
via TCM if we go ahead with this proposal: partitioner, memtable configuration,
default compaction strategy, compression. As Sam has mentioned, "which specific
value makes it into schema just depends on which instance acts as the
coordinator for a given DCL statement".
bq. but I remain unconvinced that just picking the defaults from whatever node
happens to be coordinating is the right way to go.
I have talked with Sam shortly just to make sure I understand it correctly
before trying to describe it. Since this was first worded in a way that
suggested a problem but not directly proposed a solution (possibly described
elsewhere), I will attempt to do this. Sam has already described a part of the
solution as:
bq. That should probably be in a parallel local datastructure though, not in
the node's local log table as we don't want to ship those local defaults to
peers when providing log catchup (because they should use their own defaults).
The part that was missing for me was where would the values be coming from, and
what would be the precedence. When executing a {CREATE} statement on some node
_without_ specifying, say, compression, the statement will be created and
executed without the value for compression set at all. Every node will pick the
value from its ephemeral parallel structure Sam described (which is also
settable via JMX and alike like Stefan mentioned). If no value is present in
this table, it will be picked from yaml (alternatively, we could just populate
this structure from yaml, too, but I consider these things roughly equivalent).
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837237#comment-17837237
]
Alex Petrov edited comment on CASSANDRA-12937 at 4/15/24 1:08 PM:
--
bq. Yes, I think this is the most ideal solution. If somebody wants to
experiment with a new compressor and similar, there would need to be some knob
to override it, like some JMX method or similar, and all risks attached to that
(divergence of the configuration caused by operator's negligence) would be on
him.
Some things are actually quite useful for gradual rollout. For example,
compression. You probably do not want to rewrite your sstables across the
entire cluster. Similar arguments may be made for canary deployments of
memtable settings and other things.
I agree that it is fine if these parameters are completely transient (i.e. if
you have set it to something that diverges from the clusterwide value, it will
get reverted back after the node bounce). In such case, probably they will not
go through TCM and will be purely node-local.
Examples of things that are now configuable via yaml but will be configurable
via TCM if we go ahead with this proposal: partitioner, memtable configuration,
default compaction strategy, compression. As Sam has mentioned, "which specific
value makes it into schema just depends on which instance acts as the
coordinator for a given DCL statement".
bq. but I remain unconvinced that just picking the defaults from whatever node
happens to be coordinating is the right way to go.
I have talked with Sam shortly just to make sure I understand it correctly
before trying to describe it. Since this was first worded in a way that
suggested a problem but not directly proposed a solution (possibly described
elsewhere), I will attempt to do this. Sam has already described a part of the
solution as:
bq. That should probably be in a parallel local datastructure though, not in
the node's local log table as we don't want to ship those local defaults to
peers when providing log catchup (because they should use their own defaults).
The part that was missing for me was where would the values be coming from, and
what would be the precedence. When executing a {{CREATE}} statement on some
node _without_ specifying, say, compression, the statement will be created and
executed without the value for compression set at all. Every node will pick the
value from its ephemeral parallel structure Sam described (which is also
settable via JMX and alike like Stefan mentioned). If no value is present in
this table, it will be picked from yaml (alternatively, we could just populate
this structure from yaml, too, but I consider these things roughly equivalent).
was (Author: ifesdjeen):
bq. Yes, I think this is the most ideal solution. If somebody wants to
experiment with a new compressor and similar, there would need to be some knob
to override it, like some JMX method or similar, and all risks attached to that
(divergence of the configuration caused by operator's negligence) would be on
him.
Some things are actually quite useful for gradual rollout. For example,
compression. You probably do not want to rewrite your sstables across the
entire cluster. Similar arguments may be made for canary deployments of
memtable settings and other things.
I agree that it is fine if these parameters are completely transient (i.e. if
you have set it to something that diverges from the clusterwide value, it will
get reverted back after the node bounce). In such case, probably they will not
go through TCM and will be purely node-local.
Examples of things that are now configuable via yaml but will be configurable
via TCM if we go ahead with this proposal: partitioner, memtable configuration,
default compaction strategy, compression. As Sam has mentioned, "which specific
value makes it into schema just depends on which instance acts as the
coordinator for a given DCL statement".
bq. but I remain unconvinced that just picking the defaults from whatever node
happens to be coordinating is the right way to go.
I have talked with Sam shortly just to make sure I understand it correctly
before trying to describe it. Since this was first worded in a way that
suggested a problem but not directly proposed a solution (possibly described
elsewhere), I will attempt to do this. Sam has already described a part of the
solution as:
bq. That should probably be in a parallel local datastructure though, not in
the node's local log table as we don't want to ship those local defaults to
peers when providing log catchup (because they should use their own defaults).
The part that was missing for me was where would the values be coming from, and
what would be the precedence. When executing a {CREATE} statement on some node
_without_ specifying, say, compression, the statement will be created and
[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=17837230#comment-17837230
]
Jacek Lewandowski commented on CASSANDRA-12937:
---
[~samt] let's leave aside the discussion about whether CQL is good or not as
serialization format - I didn't mean that actually. I meant that we store the
raw CQL passed by the user which is known before processing the transformation.
The resolved table settings are available after the transformation and require
rebuilding the statement as we do in "describe".
Ok, it looks like the table should simply not store the resolved default but
just the "default marker" to use whatever default is set on the node. That is,
if we not provide any compression/compaction/memtable configuration explicitly,
we will apply the node specific defaults from the yaml.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837220#comment-17837220
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
1/2. I am not sure, you could easily test this, just set default compactions /
compressions on each node and see if schemas are in an agreement.
3/4. I think that, ideally, out of the box, it should be same everywhere and a
user would need to make a conscious choice if he wanted to override that.
Currently, nothing prevents the configuration to be diverged. It is not about
whether we should enable it or not, it should be rather about being sure that
we do not diverge when we do not know about that.
5. I am not sure, it would be interesting to go over yaml and indentify these
which _have to_ to be same everywhere, these would be candidates to put into
TCM I guess.
6. currently we do not, I think that TCM would achieve that.
7. I think this all leads to some kind of an extension of nodetool which would
talk to TCM and it would set defaults there which are not settable otherwise.
E.g. default compression, so you would use a nodetool's subcommand to talk to
TCM where you would say "commit this default compression for me", and then all
nodes would apply these defaults from the log, eventually. Any other config
change similar to this would be like that.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837214#comment-17837214
]
Claude Warren commented on CASSANDRA-12937:
---
I think a few questions are in order:
# Is compression selection really part of the schema? My impression is that
the schema defines what goes into the tables, not how the tables are written
(e.g. different SSTable formats).
# is compaction selection part of the schema?
# do we allow nodes to have different compaction?
# If we allow different compaction on different nodes why would we not allow
different compression?
# If we have settings that must be the same across all the nodes do we have a
way to identify them in the configuration?
# if we can identify them, how do we guarantee that they are not different
across the nodes?
# If we can identify them, how do we set them?
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837210#comment-17837210
]
Stefan Miklosovic edited comment on CASSANDRA-12937 at 4/15/24 12:06 PM:
-
{quote}It seems like if we actually want these to be cluster wide values and
not configurable on a per-node basis the defaults themselves should be in
TCM{quote}
Yes, I think this is the most ideal solution. If somebody wants to experiment
with a new compressor and similar, there would need to be some knob to override
it, like some JMX method or similar, and all risks attached to that (divergence
of the configuration caused by operator's negligence) would be on him.
However, who would be changing the defaults? What I mean by that is that if
defaults are committed in TCM, then if we change our mind about the defaults,
by what mean would we commit them into TCM again, now changed?
was (Author: smiklosovic):
{quote}It seems like if we actually want these to be cluster wide values and
not configurable on a per-node basis the defaults themselves should be in
TCM{quote}
Yes, I think this is the most ideal solution. If somebody wants to experiment
with a new compressor and similar, there would need to be some knob to override
it, like some JMX method or similar, and all risks attached to that (divergence
of the configuration caused by operator's negligence) would be on him.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837210#comment-17837210
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
{quote}It seems like if we actually want these to be cluster wide values and
not configurable on a per-node basis the defaults themselves should be in
TCM{quote}
Yes, I think this is the most ideal solution. If somebody wants to experiment
with a new compressor and similar, there would need to be some knob to override
it, like some JMX method or similar, and all risks attached to that (divergence
of the configuration caused by operator's negligence) would be on him.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837201#comment-17837201
]
Sam Tunnicliffe commented on CASSANDRA-12937:
-
So you're suggesting that we could have different default values in yaml across
the cluster, but that all nodes actually apply the same value regardless of
their own configured default? Which specific value makes it into schema just
depends on which instance acts as the coordinator for a given DCL statement? It
seems like if we actually want these to be cluster wide values and not
configurable on a per-node basis the defaults themselves should be in TCM,
independently of the schema transformations. In the past, we've used per-node
configuration like this to experiment with new compression algorithms on a
per-node basis and I can imagine potentially wanting to do the same with things
like compaction, so I'm not entirely convinced that this assumption is correct.
As far as the serialization format, schema transformations have to be
round-trippable via CQL for the purposes of recreating a schema from a
snapshot. So I don't think that using the CQL itself as the format is
inherently flawed and it does have a couple of big positives, namely that it's
great for visibility (for operators or when debugging) and that it doesn't
invent a new format, that we have version and manage as new
flags/features/defaults are added.
We should just need fully resolve and expand a DCL statement before serializing
it in {{SchemaAlteringStatement}} which would be entirely possible, but I
remain unconvinced that just picking the defaults from whatever node happens to
be coordinating is the right way to go.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837191#comment-17837191
]
Jacek Lewandowski commented on CASSANDRA-12937:
---
{quote}Ideally we should store the value that is actually resolved during
initial execution on each node so that it can be re-used if/when the
transformation is reapplied.
{quote}
So, if nodes had configurations out-of-sync, they would end up with local
schemas with different compression, compaction, etc. settings each?
I didn't mean storing defaults as defaults, just materializing all the settings
when the table is created. Currently it is not easy because the schema
transformation is stored as a raw CQL
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837188#comment-17837188
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
I don't think that nodes should diverge in any way when it comes to schemas.
All the schema should be taken from TCM, irrelevant how local node is
configured. I just do not see why would one want one node to compress with
Deflate and another one to compress with lz4 ... Basically, it should ignore
what is configured locally if it is different in TCM.
This problem will probably be visible e.g. in Guardrails in TCM. What
guardrails it should take into account when we join a new node and local
guardrails configuration is different from the one in TCM? I would say that TCM
should win here.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837179#comment-17837179
]
Sam Tunnicliffe edited comment on CASSANDRA-12937 at 4/15/24 11:11 AM:
---
The problem with that is that the defaults may be different on every instance,
so what exactly should be stored in the TCM log? Ideally we should store the
value that is actually resolved during initial execution on each node so that
it can be re-used if/when the transformation is reapplied. That should probably
be in a parallel local datastructure though, not in the node's local log table
as we don't want to ship those local defaults to peers when providing log
catchup (because they should use their own defaults).
was (Author: beobal):
The problem with that is that the defaults may be different on every instance,
so what exactly should be stored in the TCM log? Ideally we should store the
value that is actually resolved during initial execution on each node to be
persisted locally so that it can be re-used if/when the transformation is
reapplied. That should probably be in a parallel local datastructure though,
not in the node's local log table as we don't want to ship those local defaults
to peers when providing log catchup (because they should use their own
defaults).
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837179#comment-17837179
]
Sam Tunnicliffe commented on CASSANDRA-12937:
-
The problem with that is that the defaults may be different on every instance,
so what exactly should be stored in the TCM log? Ideally we should store the
value that is actually resolved during initial execution on each node to be
persisted locally so that it can be re-used if/when the transformation is
reapplied. That should probably be in a parallel local datastructure though,
not in the node's local log table as we don't want to ship those local defaults
to peers when providing log catchup (because they should use their own
defaults).
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837176#comment-17837176
]
Jacek Lewandowski edited comment on CASSANDRA-12937 at 4/15/24 11:01 AM:
-
The problem with the failing test is probably that the default configuration
for compression parameters (and other defaults for table / keyspace
creation/alteration) should be part of the schema transformation data and
stored in TCM log.
This is it not an issues related to this ticket because it applies to various
settings; For example, even without this PR, similar test would fail while
manipulating a value of "
cassandra.sstable_compression_default" property. Then, we would have the same
problem with default compaction and memtable options which are also got from
the configuration,
was (Author: jlewandowski):
The problem with the failing test is probably that the default configuration
for compression parameters (and other defaults for table / keyspace
creation/alteration) should be part of the schema transformation data and
stored in TCM log.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18954) Transformations should be pure so that replaying them results in the same outcome regardless of the node state or configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837177#comment-17837177 ] Sam Tunnicliffe commented on CASSANDRA-18954: - [~jlewandowski] bq. CASSANDRA-12937 problem is caused by the fact that the transformations are not pure. It is not enough that they are side-effects-free, they also cannot depend on any external properties other than the current cluster state and the store transformation data. Yes, this is exactly what I mean and we're looking into a proper fix for this now > Transformations should be pure so that replaying them results in the same > outcome regardless of the node state or configuration > --- > > Key: CASSANDRA-18954 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18954 > Project: Cassandra > Issue Type: Bug > Components: Transactional Cluster Metadata >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > > Discussed on Slack -- This message was sent by Atlassian Jira (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=17837176#comment-17837176
]
Jacek Lewandowski commented on CASSANDRA-12937:
---
The problem with the failing test is probably that the default configuration
for compression parameters (and other defaults for table / keyspace
creation/alteration) should be part of the schema transformation data and
stored in TCM log.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18954) Transformations should be pure so that replaying them results in the same outcome regardless of the node state or configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837173#comment-17837173 ] Jacek Lewandowski commented on CASSANDRA-18954: --- [~samt] - CASSANDRA-12937 problem is caused by the fact that the transformations are not pure. It is not enough that they are side-effects-free, they also cannot depend on any external properties other than the current cluster state and the store transformation data. I haven't looked at the fixed you mentioned, but in my PR there was just an example fix for one schema transformation - alter-table, one of the applied fixes was to not verify "enableDropCompactStorage" from the configuration in replay mode because the configuration is not the part of the transformation data. That could lead to different outcomes after replaying a log, in particular to inability to start the cluster after changing the configuration. > Transformations should be pure so that replaying them results in the same > outcome regardless of the node state or configuration > --- > > Key: CASSANDRA-18954 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18954 > Project: Cassandra > Issue Type: Bug > Components: Transactional Cluster Metadata >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > > Discussed on Slack -- This message was sent by Atlassian Jira (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-19498) Error reading data from credential file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837149#comment-17837149
]
Stefan Miklosovic commented on CASSANDRA-19498:
---
[~bschoeni] are you available to prepare 4.1 and 5.0 branches, please?
> Error reading data from credential file
> ---
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19538) Test Failure: test_assassinate_valid_node
[
https://issues.apache.org/jira/browse/CASSANDRA-19538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson reassigned CASSANDRA-19538:
---
Assignee: Marcus Eriksson
> Test Failure: test_assassinate_valid_node
> -
>
> Key: CASSANDRA-19538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19538
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.x
>
>
> Failing consistently on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after 120.11/120
> seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> Tail: ... some nodes were not ready
> INFO [OptionalTasks:1] 2024-04-03 19:39:30,454 CassandraRoleManager.java:484
> - Setup task failed with error, rescheduling
> self =
> def test_assassinate_valid_node(self):
> """
> @jira_ticket CASSANDRA-16588
> Test that after taking two non-seed nodes down and assassinating
> one of them, the other can come back up.
> """
> cluster = self.cluster
>
> cluster.populate(5).start()
> node1 = cluster.nodelist()[0]
> node3 = cluster.nodelist()[2]
>
> self.cluster.set_configuration_options({
> 'seed_provider': [{'class_name':
> 'org.apache.cassandra.locator.SimpleSeedProvider',
>'parameters': [{'seeds': node1.address()}]
> }]
> })
>
> non_seed_nodes = cluster.nodelist()[-2:]
> for node in non_seed_nodes:
> node.stop()
>
> assassination_target = non_seed_nodes[0]
> logger.debug("Assassinating non-seed node
> {}".format(assassination_target.address()))
> out, err, _ = node1.nodetool("assassinate
> {}".format(assassination_target.address()))
> assert_stderr_clean(err)
>
> logger.debug("Starting non-seed nodes")
> for node in non_seed_nodes:
> > node.start()
> gossip_test.py:78:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:915: in start
> node.watch_log_for_alive(self, from_mark=mark)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:684: in
> watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173052.8186479, timeout = 120
> msg = "Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:\n
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 1...[OptionalTasks:1]
> 2024-04-03 19:39:30,454 CassandraRoleManager.java:484 - Setup task failed
> with error, rescheduling\n"
> node = 'node1'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after
> 120.11/120 seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in
> system.log:
> EHead: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> ETail: ... some nodes were not ready
> E INFO [OptionalTasks:1] 2024-04-03 19:39:30,454
> CassandraRoleManager.java:484 - Setup task failed with error, rescheduling
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
