[jira] [Updated] (CASSANDRA-17228) WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why We Need Them"
[ https://issues.apache.org/jira/browse/CASSANDRA-17228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17228: -- Reviewers: Anthony Grasso, Erick Ramirez, Michael Semb Wever (was: Erick Ramirez, Michael Semb Wever) > WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why > We Need Them" > -- > > Key: CASSANDRA-17228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17228 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.2, 4.1 > > Attachments: c17228-01-blog_post.png > > > This ticket is to capture the work associated with publishing the December > 2021 blog post for "Configurable Storage Ports and Why We Need Them" > If this blog cannot be published by the *December 28, 2021 publish date*, > please contact me, suggest changes, or correct the date yourself when > possible in the pull request for the appropriate time that the blog will go > live (on blog.adoc and in the blog). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17228) WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why We Need Them"
[ https://issues.apache.org/jira/browse/CASSANDRA-17228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475131#comment-17475131 ] Anthony Grasso commented on CASSANDRA-17228: [~diotopper] great post! I added suggested changes to the pull request. There are few small typos we should probably fix before we push this out. > WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why > We Need Them" > -- > > Key: CASSANDRA-17228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17228 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.2, 4.1 > > Attachments: c17228-01-blog_post.png > > > This ticket is to capture the work associated with publishing the December > 2021 blog post for "Configurable Storage Ports and Why We Need Them" > If this blog cannot be published by the *December 28, 2021 publish date*, > please contact me, suggest changes, or correct the date yourself when > possible in the pull request for the appropriate time that the blog will go > live (on blog.adoc and in the blog). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17228) WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why We Need Them"
[ https://issues.apache.org/jira/browse/CASSANDRA-17228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17228: -- Attachment: c17228-01-blog_post.png > WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why > We Need Them" > -- > > Key: CASSANDRA-17228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17228 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.2, 4.1 > > Attachments: c17228-01-blog_post.png > > > This ticket is to capture the work associated with publishing the December > 2021 blog post for "Configurable Storage Ports and Why We Need Them" > If this blog cannot be published by the *December 28, 2021 publish date*, > please contact me, suggest changes, or correct the date yourself when > possible in the pull request for the appropriate time that the blog will go > live (on blog.adoc and in the blog). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17228) WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why We Need Them"
[ https://issues.apache.org/jira/browse/CASSANDRA-17228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17228: -- Status: Changes Suggested (was: Review In Progress) Apart from updating the publish date, I made a suggestion directly in the PR about updating the image caption to make it clear it is a credit to the owner. Otherwise, the post should be ready to publish Cheers! !c17228-01-blog_post.png|width=300! > WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why > We Need Them" > -- > > Key: CASSANDRA-17228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17228 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.2, 4.1 > > Attachments: c17228-01-blog_post.png > > > This ticket is to capture the work associated with publishing the December > 2021 blog post for "Configurable Storage Ports and Why We Need Them" > If this blog cannot be published by the *December 28, 2021 publish date*, > please contact me, suggest changes, or correct the date yourself when > possible in the pull request for the appropriate time that the blog will go > live (on blog.adoc and in the blog). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17228) WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why We Need Them"
[ https://issues.apache.org/jira/browse/CASSANDRA-17228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17228: -- Status: Review In Progress (was: Patch Available) > WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why > We Need Them" > -- > > Key: CASSANDRA-17228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17228 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.2, 4.1 > > > This ticket is to capture the work associated with publishing the December > 2021 blog post for "Configurable Storage Ports and Why We Need Them" > If this blog cannot be published by the *December 28, 2021 publish date*, > please contact me, suggest changes, or correct the date yourself when > possible in the pull request for the appropriate time that the blog will go > live (on blog.adoc and in the blog). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17228) WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why We Need Them"
[ https://issues.apache.org/jira/browse/CASSANDRA-17228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17228: -- Status: Patch Available (was: Open) > WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why > We Need Them" > -- > > Key: CASSANDRA-17228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17228 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.2, 4.1 > > > This ticket is to capture the work associated with publishing the December > 2021 blog post for "Configurable Storage Ports and Why We Need Them" > If this blog cannot be published by the *December 28, 2021 publish date*, > please contact me, suggest changes, or correct the date yourself when > possible in the pull request for the appropriate time that the blog will go > live (on blog.adoc and in the blog). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17228) WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why We Need Them"
[ https://issues.apache.org/jira/browse/CASSANDRA-17228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17228: -- Reviewers: Erick Ramirez, Michael Semb Wever (was: Anthony Grasso, Erick Ramirez, Michael Semb Wever) Status: Open (was: Triage Needed) > WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why > We Need Them" > -- > > Key: CASSANDRA-17228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17228 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.2, 4.1 > > > This ticket is to capture the work associated with publishing the December > 2021 blog post for "Configurable Storage Ports and Why We Need Them" > If this blog cannot be published by the *December 28, 2021 publish date*, > please contact me, suggest changes, or correct the date yourself when > possible in the pull request for the appropriate time that the blog will go > live (on blog.adoc and in the blog). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16958) Prewarm role and credentials caches to avoid timeouts at startup
[ https://issues.apache.org/jira/browse/CASSANDRA-16958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475107#comment-17475107 ] Caleb Rackliffe commented on CASSANDRA-16958: - Wrapped up my first pass at review. I'll probably be ready to approve once we resolve the [minor outstanding comments|https://github.com/apache/cassandra/pull/1205/files#r783622670]. > Prewarm role and credentials caches to avoid timeouts at startup > > > Key: CASSANDRA-16958 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16958 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > With our current auth querying setup, you can end up with a thundering herd > on reconnect due to delays on auth resolution. > We should instead allow the ability to do a 'select' on all roles and > pre-load the cache before turning on native transport. Notably, this could > present some unacceptable delays on start with a very large count of users > (thousands), or someone who uses a third party auth system rather than the > built-in authorizer so this should be configurable and opt-in. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475083#comment-17475083
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/13/22, 3:26 AM:
---
While rebasing and adding more parameters I hit a corner case, three duration
parameters without unit suffixes which I personally don't think they need name
change. That's fine. A converter was easy to add for them, BUT... what about
Virtual tables? In order to support backward compatibility we currently list
old parameters, those with new names are available in the old and the new form.
For example:
{code:java}
memtable_heap_space 2018MiB
memtable_heap_space_in_mb 2018
{code}
The parameters that I personally didn't find a reason to change names but only
the value formatting (adding the units to the value) are:
_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I
can easily say we introduce a breaking change and leave those alone in the new
format but I am open to hear also others' opinion. I feel I am getting too used
to this work and I might be missing something. Also, IMHO it's worth it not to
introduce breaking changes when/if possible.
In other news during the latest rebase and addition of parameters I found we
need to improve the precision for the _DataRateSpec._ I will publish this in a
separate patch soon, already handled.
I am doing last cleaning of tests and I will publish the final version with all
latest changes from November until now for the reviewers' consideration.
was (Author: e.dimitrova):
While rebasing and adding more parameters I hit a corner case, three duration
parameters without unit suffixes which I personally don't think they need name
change. That's fine. A converter was easy to add for them, BUT... what about
Virtual tables? In order to support backward compatibility we currently list
old parameters, those with new names are available in the old and the new form.
For example:
{code:java}
memtable_heap_space 2018MiB
memtable_heap_space_in_mb 2018
{code}
The parameters that I personally didn't find a reason to change names but only
the value formatting (adding the units to the value) are:
_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I
can easily say we introduce a breaking change and leave those alone in the new
format but I am open to hear also others' opinion. I feel I am getting too used
to this work and I might be missing something. Also, IMHO it's worth it not to
introduce breaking changes when/if possible.
In other news during the latest rebase and addition of parameters I found we
need to improve the precision for the _DataRateSpec._ I will publish this in a
separate patch soon, already handled.
I am doing last cleaning of tests and I will publish the final version with all
latest changes from November until now for the reviewers' consideration.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475083#comment-17475083
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/13/22, 3:25 AM:
---
While rebasing and adding more parameters I hit a corner case, three duration
parameters without unit suffixes which I personally don't think they need name
change. That's fine. A converter was easy to add for them, BUT... what about
Virtual tables? In order to support backward compatibility we currently list
old parameters, those with new names are available in the old and the new form.
For example:
{code:java}
memtable_heap_space 2018MiB
memtable_heap_space_in_mb 2018
{code}
The parameters that I personally didn't find a reason to change names but only
the value formatting (adding the units to the value) are:
_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I
can easily say we introduce a breaking change and leave those alone in the new
format but I am open to hear also others' opinion. I feel I am getting too used
to this work and I might be missing something. Also, IMHO it's worth it not to
introduce breaking changes when/if possible.
In other news during the latest rebase and addition of parameters I found we
need to improve the precision for the _DataRateSpec._ I will publish this in a
separate patch soon, already handled.
I am doing last cleaning of tests and I will publish the final version with all
latest changes from November until now for the reviewers' consideration.
was (Author: e.dimitrova):
While rebasing and adding more parameters I hit a corner case, three duration
parameters without unit suffixes which I personally don't think they need name
change. That's fine. A converter was easy to add for them, BUT... what about
Virtual tables? In order to support backward compatibility we currently list
old parameters, those with new names are available in the old and the new form.
For example:
{code:java}
memtable_heap_space 2018MiB
meltable_heap_space_in_mb 2018
{code}
The parameters that I personally didn't find a reason to change names but only
the value formatting (adding the units to the value) are:
_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I
can easily say we introduce a breaking change and leave those alone in the new
format but I am open to hear also others' opinion. I feel I am getting too used
to this work and I might be missing something. Also, IMHO it's worth it not to
introduce breaking changes when/if possible.
In other news during the latest rebase and addition of parameters I found we
need to improve the precision for the _DataRateSpec._ I will publish this in a
separate patch soon, already handled.
I am doing last cleaning of tests and I will publish the final version with all
latest changes from November until now for the reviewers' consideration.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475083#comment-17475083
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/13/22, 3:24 AM:
---
While rebasing and adding more parameters I hit a corner case, three duration
parameters without unit suffixes which I personally don't think they need name
change. That's fine. A converter was easy to add for them, BUT... what about
Virtual tables? In order to support backward compatibility we currently list
old parameters, those with new names are available in the old and the new form.
For example:
{code:java}
memtable_heap_space 2018MiB
meltable_heap_space_in_mb 2018
{code}
The parameters that I personally didn't find a reason to change names but only
the value formatting (adding the units to the value) are:
_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I
can easily say we introduce a breaking change and leave those alone in the new
format but I am open to hear also others' opinion. I feel I am getting too used
to this work and I might be missing something. Also, IMHO it's worth it not to
introduce breaking changes when/if possible.
In other news during the latest rebase and addition of parameters I found we
need to improve the precision for the _DataRateSpec._ I will publish this in a
separate patch soon, already handled.
I am doing last cleaning of tests and I will publish the final version with all
latest changes from November until now for the reviewers' consideration.
was (Author: e.dimitrova):
While rebasing and adding more parameters I hit a corner case, three duration
parameters without unit suffixes which I personally don't think they need name
change. That's fine. A converter was easy to add for them, BUT... what about
Virtual tables? In order to support backward compatibility we currently list
old parameters, those with new names are available in the old and the new form.
For example:
{code:java}
memtable_heap_space 2018MiB
meltable_heap_space_in_mb 2018
{code}
The parameters that I personally didn't find a reason to change names but only
the value formatting (adding the units to the value) are:
_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I
can easily say we introduce a breaking change and leave those alone in the new
format but I am open to hear also others' opinion. I feel I am getting too used
to this work and I might be missing something. Also, IMHO it's worth it not to
introduce breaking changes when/if possible.
In other news during the latest rebase and addition of parameters I found we
need to improve the precision for the _DataRateSpec._ I will publish this in a
separate patch soon.
I am doing last cleaning of tests and I will publish the final version with all
latest changes from November until now for the reviewers' consideration.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475083#comment-17475083
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/13/22, 3:24 AM:
---
While rebasing and adding more parameters I hit a corner case, three duration
parameters without unit suffixes which I personally don't think they need name
change. That's fine. A converter was easy to add for them, BUT... what about
Virtual tables? In order to support backward compatibility we currently list
old parameters, those with new names are available in the old and the new form.
For example:
{code:java}
memtable_heap_space 2018MiB
meltable_heap_space_in_mb 2018
{code}
The parameters that I personally didn't find a reason to change names but only
the value formatting (adding the units to the value) are:
_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I
can easily say we introduce a breaking change and leave those alone in the new
format but I am open to hear also others' opinion. I feel I am getting too used
to this work and I might be missing something. Also, IMHO it's worth it not to
introduce breaking changes when/if possible.
In other news during the latest rebase and addition of parameters I found we
need to improve the precision for the _DataRateSpec._ I will publish this in a
separate patch soon.
I am doing last cleaning of tests and I will publish the final version with all
latest changes from November until now for the reviewers' consideration.
was (Author: e.dimitrova):
While rebasing and adding more parameters I hit a corner case, three duration
parameters without unit suffixes which I personally don't think they need name
change. That's fine. A converter was easy to add for them, BUT... what about
Virtual tables? In order to support backward compatibility we currently list
old parameters, those with new names are available in the old and the new form.
For example:
{code:java}
memtable_heap_space 2018MiB
meltable_heap_space_in_mb 2018
{code}
The parameters that I personally didn't find a reason to change names but only
the value formatting (adding the units to the value) are:
_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I
can easily say we introduce a breaking change and leave those alone in the new
format but I am open to hear also others' opinion. I feel I am getting too used
to this work and I might be missing something. Also, IMHO it's worth it not to
introduce breaking changes when possible.
In other news during the latest rebase and addition of parameters I found we
need to improve the precision for the _DataRateSpec._ I will publish this in a
separate patch soon.
I am doing last cleaning of tests and I will publish the final version with all
latest changes from November until now for the reviewers' consideration.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475083#comment-17475083
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
While rebasing and adding more parameters I hit a corner case, three duration
parameters without unit suffixes which I personally don't think they need name
change. That's fine. A converter was easy to add for them, BUT... what about
Virtual tables? In order to support backward compatibility we currently list
old parameters, those with new names are available in the old and the new form.
For example:
{code:java}
memtable_heap_space 2018MiB
meltable_heap_space_in_mb 2018
{code}
The parameters that I personally didn't find a reason to change names but only
the value formatting (adding the units to the value) are:
_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I
can easily say we introduce a breaking change and leave those alone in the new
format but I am open to hear also others' opinion. I feel I am getting too used
to this work and I might be missing something. Also, IMHO it's worth it not to
introduce breaking changes when possible.
In other news during the latest rebase and addition of parameters I found we
need to improve the precision for the _DataRateSpec._ I will publish this in a
separate patch soon.
I am doing last cleaning of tests and I will publish the final version with all
latest changes from November until now for the reviewers' consideration.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17116) When streaming sees a ClosedChannelException this triggers the disk failure policy
[
https://issues.apache.org/jira/browse/CASSANDRA-17116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17116:
--
Authors: David Capwell, Francisco Guerrero (was: David Capwell)
> When streaming sees a ClosedChannelException this triggers the disk failure
> policy
> --
>
> Key: CASSANDRA-17116
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17116
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> Found in CASSANDRA-17085.
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7264
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7256
> {code}
> ERROR [Stream-Deserializer-/127.0.0.1:7000-f2eb1a15] 2021-11-02 21:35:40,983
> DefaultFSErrorHandler.java:104 - Exiting forcefully due to file system
> exception on startup, disk failure policy "stop"
> org.apache.cassandra.io.FSWriteError: java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:227)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.writeComponent(BigTableZeroCopyWriter.java:206)
> at
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:125)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:84)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:51)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:37)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)
> at
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:62)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.channels.ClosedChannelException: null
> at
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:136)
> at
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:155)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:217)
> ... 9 common frames omitted
> {code}
> When bootstrap fails and streaming is closed, this triggers the disk failure
> policy which causes the JVM to halt by default (if this happens outside of
> bootstrap, then we stop transports and keep the JVM up).
> org.apache.cassandra.streaming.StreamDeserializingTask attempts to handle
> this by ignoring this exception, but the call to
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize
> Does try/catch and inspects exception; triggering this condition.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17256) Fixes for intermittent in-JVM dtest failures
[ https://issues.apache.org/jira/browse/CASSANDRA-17256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-17256: - Status: Ready to Commit (was: Review In Progress) Starting commit CI Results (pending): ||Branch||Source||Circle CI||Jenkins|| |cassandra-3.0|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17256-cassandra-3.0-E9B2274D-8700-4B7A-B4C7-2700AE3EC2F3]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17256-cassandra-3.0-E9B2274D-8700-4B7A-B4C7-2700AE3EC2F3]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1366/]| |cassandra-3.11|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17256-cassandra-3.11-E9B2274D-8700-4B7A-B4C7-2700AE3EC2F3]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17256-cassandra-3.11-E9B2274D-8700-4B7A-B4C7-2700AE3EC2F3]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1367/]| |cassandra-4.0|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17256-cassandra-4.0-E9B2274D-8700-4B7A-B4C7-2700AE3EC2F3]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17256-cassandra-4.0-E9B2274D-8700-4B7A-B4C7-2700AE3EC2F3]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1368/]| |trunk|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17256-trunk-E9B2274D-8700-4B7A-B4C7-2700AE3EC2F3]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17256-trunk-E9B2274D-8700-4B7A-B4C7-2700AE3EC2F3]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1369/]| > Fixes for intermittent in-JVM dtest failures > > > Key: CASSANDRA-17256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17256 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 1h > Remaining Estimate: 0h > > Improvements to StreamingTransferTest, MixedModeMessageForwardTest and > SchemaDisagreementTest flakes. > For 3.0, adopt the ring settling properties used on trunk. For all releases > increase to 15s for ring settling. > For all branches, disable autocompaction during shutdown. > For 4.0 and up, shut down the scheduled executors a little later. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17204) Upgrade to Logback 1.2.9 (security)
[
https://issues.apache.org/jira/browse/CASSANDRA-17204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17204:
-
Summary: Upgrade to Logback 1.2.9 (security) (was: Upgrade to Logback
1.2.8 (security))
> Upgrade to Logback 1.2.9 (security)
> ---
>
> Key: CASSANDRA-17204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17204
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Jochen Schalanda
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Logback 1.2.8 has been released with a fix for a potential vulnerability in
> its JNDI lookup.
> * [http://logback.qos.ch/news.html]
> * [https://jira.qos.ch/browse/LOGBACK-1591]
> {quote}*14th of December, 2021, Release of version 1.2.8*
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite.
> * • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
> logback until further notice. This impacts {{ContextJNDISelector}} and
> {{}} element in configuration files.
> * Also in response to LOGBACK-1591, we have removed all database (JDBC)
> related code in the project with no replacement.
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite. A successful RCE
> requires all of the following to be true:
> * write access to logback.xml
> * use of versions < 1.2.8
> * reloading of poisoned configuration data, which implies application restart
> or scan="true" set prior to attack
> Therefore and as an additional precaution, in addition to upgrading to
> version 1.2.8, we also recommend users to set their logback configuration
> files as read-only.
> {quote}
> This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
> probably be fixed anyway.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17204) Upgrade to Logback 1.2.8 (security)
[
https://issues.apache.org/jira/browse/CASSANDRA-17204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474974#comment-17474974
]
Brandon Williams commented on CASSANDRA-17204:
--
Both 4.0 and trunk look good, unsurprisingly. 3.0 and 3.11 needed a test fix
from CASSANDRA-14183 to handle AggregationTest.testLogbackReload, which I've
added, leaving the only failing test to be
DatabaseDescriptorRefTest.testDatabaseDescriptorRef which is failing due to:
{quote}
[junit-timeout] Testsuite:
org.apache.cassandra.config.DatabaseDescriptorRefTest Tests run: 1, Failures:
1, Errors: 0, Skipped: 0, Time elapsed: 0.29 sec
[junit-timeout]
[junit-timeout] - Standard Output ---
[junit-timeout] ERROR [main] 2022-01-12 20:58:48,769 SubstituteLogger.java:250
- SLF4J: stderr
[junit-timeout] - ---
[junit-timeout] - Standard Error -
[junit-timeout]
[junit-timeout]
[junit-timeout] VIOLATION:
org.apache.cassandra.distributed.shared.InstanceClassLoader
[junit-timeout] java.lang.Exception
{quote}
I'm not really sure how this is exposing a dtest class, and I don't see it
being excluded in 4.0. [~mck] do you have any ideas?
> Upgrade to Logback 1.2.8 (security)
> ---
>
> Key: CASSANDRA-17204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17204
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Jochen Schalanda
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Logback 1.2.8 has been released with a fix for a potential vulnerability in
> its JNDI lookup.
> * [http://logback.qos.ch/news.html]
> * [https://jira.qos.ch/browse/LOGBACK-1591]
> {quote}*14th of December, 2021, Release of version 1.2.8*
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite.
> * • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
> logback until further notice. This impacts {{ContextJNDISelector}} and
> {{}} element in configuration files.
> * Also in response to LOGBACK-1591, we have removed all database (JDBC)
> related code in the project with no replacement.
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite. A successful RCE
> requires all of the following to be true:
> * write access to logback.xml
> * use of versions < 1.2.8
> * reloading of poisoned configuration data, which implies application restart
> or scan="true" set prior to attack
> Therefore and as an additional precaution, in addition to upgrading to
> version 1.2.8, we also recommend users to set their logback configuration
> files as read-only.
> {quote}
> This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
> probably be fixed anyway.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17258) Block writes to partitions over a threshold
[ https://issues.apache.org/jira/browse/CASSANDRA-17258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474943#comment-17474943 ] David Capwell commented on CASSANDRA-17258: --- will submit a patch after CASSANDRA-16310 merges > Block writes to partitions over a threshold > --- > > Key: CASSANDRA-17258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17258 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Local Write-Read Paths >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > With CASSANDRA-16310 we now know (node local) the top partitions (size and > number of tombstones) and can leverage this to block adding writes to > partitions over a given size (as defined by top partitions). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17258) Block writes to partitions over a threshold
[ https://issues.apache.org/jira/browse/CASSANDRA-17258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17258: -- Change Category: Performance Complexity: Low Hanging Fruit Fix Version/s: 4.x Status: Open (was: Triage Needed) > Block writes to partitions over a threshold > --- > > Key: CASSANDRA-17258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17258 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Local Write-Read Paths >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > With CASSANDRA-16310 we now know (node local) the top partitions (size and > number of tombstones) and can leverage this to block adding writes to > partitions over a given size (as defined by top partitions). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17258) Block writes to partitions over a threshold
[ https://issues.apache.org/jira/browse/CASSANDRA-17258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell reassigned CASSANDRA-17258: - Assignee: David Capwell > Block writes to partitions over a threshold > --- > > Key: CASSANDRA-17258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17258 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Local Write-Read Paths >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > > With CASSANDRA-16310 we now know (node local) the top partitions (size and > number of tombstones) and can leverage this to block adding writes to > partitions over a given size (as defined by top partitions). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17258) Block writes to partitions over a threshold
David Capwell created CASSANDRA-17258: - Summary: Block writes to partitions over a threshold Key: CASSANDRA-17258 URL: https://issues.apache.org/jira/browse/CASSANDRA-17258 Project: Cassandra Issue Type: Improvement Components: Legacy/Local Write-Read Paths Reporter: David Capwell With CASSANDRA-16310 we now know (node local) the top partitions (size and number of tombstones) and can leverage this to block adding writes to partitions over a given size (as defined by top partitions). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17256) Fixes for intermittent in-JVM dtest failures
[ https://issues.apache.org/jira/browse/CASSANDRA-17256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474939#comment-17474939 ] Caleb Rackliffe commented on CASSANDRA-17256: - +1 Left some minor comment in the PRs. > Fixes for intermittent in-JVM dtest failures > > > Key: CASSANDRA-17256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17256 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 50m > Remaining Estimate: 0h > > Improvements to StreamingTransferTest, MixedModeMessageForwardTest and > SchemaDisagreementTest flakes. > For 3.0, adopt the ring settling properties used on trunk. For all releases > increase to 15s for ring settling. > For all branches, disable autocompaction during shutdown. > For 4.0 and up, shut down the scheduled executors a little later. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17256) Fixes for intermittent in-JVM dtest failures
[ https://issues.apache.org/jira/browse/CASSANDRA-17256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-17256: Reviewers: Caleb Rackliffe, Caleb Rackliffe Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe) Status: Review In Progress (was: Patch Available) > Fixes for intermittent in-JVM dtest failures > > > Key: CASSANDRA-17256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17256 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > Improvements to StreamingTransferTest, MixedModeMessageForwardTest and > SchemaDisagreementTest flakes. > For 3.0, adopt the ring settling properties used on trunk. For all releases > increase to 15s for ring settling. > For all branches, disable autocompaction during shutdown. > For 4.0 and up, shut down the scheduled executors a little later. -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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 (b8dec3e -> d033139)
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 b8dec3e generate docs for b70dcb85 new d033139 generate docs for b70dcb85 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 (b8dec3e) \ N -- N -- N refs/heads/asf-staging (d033139) 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: site-ui/build/ui-bundle.zip | Bin 4740057 -> 4740057 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17068) Failed inbound internode authentication failures generate ugly warning with stack trace
[ https://issues.apache.org/jira/browse/CASSANDRA-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474779#comment-17474779 ] David Capwell commented on CASSANDRA-17068: --- +1 assuming CI is clean > Failed inbound internode authentication failures generate ugly warning with > stack trace > --- > > Key: CASSANDRA-17068 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17068 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.x > > > Inbound connections can come from anywhere and the warning / stack trace is > unhelpful so I'd like to downgrade to a simple single-line INFO message when > authorization fails to reduce clutter in the logs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17068) Failed inbound internode authentication failures generate ugly warning with stack trace
[ https://issues.apache.org/jira/browse/CASSANDRA-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474760#comment-17474760 ] David Capwell commented on CASSANDRA-17068: --- spoke to Jon, can take this up in a week or so > Failed inbound internode authentication failures generate ugly warning with > stack trace > --- > > Key: CASSANDRA-17068 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17068 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Jon Meredith >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > Inbound connections can come from anywhere and the warning / stack trace is > unhelpful so I'd like to downgrade to a simple single-line INFO message when > authorization fails to reduce clutter in the logs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17068) Failed inbound internode authentication failures generate ugly warning with stack trace
[ https://issues.apache.org/jira/browse/CASSANDRA-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell reassigned CASSANDRA-17068: - Assignee: Jon Meredith (was: David Capwell) > Failed inbound internode authentication failures generate ugly warning with > stack trace > --- > > Key: CASSANDRA-17068 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17068 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.x > > > Inbound connections can come from anywhere and the warning / stack trace is > unhelpful so I'd like to downgrade to a simple single-line INFO message when > authorization fails to reduce clutter in the logs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17068) Failed inbound internode authentication failures generate ugly warning with stack trace
[ https://issues.apache.org/jira/browse/CASSANDRA-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17068: -- Reviewers: David Capwell Status: Review In Progress (was: Patch Available) > Failed inbound internode authentication failures generate ugly warning with > stack trace > --- > > Key: CASSANDRA-17068 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17068 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.x > > > Inbound connections can come from anywhere and the warning / stack trace is > unhelpful so I'd like to downgrade to a simple single-line INFO message when > authorization fails to reduce clutter in the logs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-17068) Failed inbound internode authentication failures generate ugly warning with stack trace
[ https://issues.apache.org/jira/browse/CASSANDRA-17068 ] David Capwell deleted comment on CASSANDRA-17068: --- was (Author: dcapwell): spoke to Jon, can take this up in a week or so > Failed inbound internode authentication failures generate ugly warning with > stack trace > --- > > Key: CASSANDRA-17068 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17068 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Jon Meredith >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > Inbound connections can come from anywhere and the warning / stack trace is > unhelpful so I'd like to downgrade to a simple single-line INFO message when > authorization fails to reduce clutter in the logs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17068) Failed inbound internode authentication failures generate ugly warning with stack trace
[ https://issues.apache.org/jira/browse/CASSANDRA-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell reassigned CASSANDRA-17068: - Assignee: David Capwell (was: Jon Meredith) > Failed inbound internode authentication failures generate ugly warning with > stack trace > --- > > Key: CASSANDRA-17068 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17068 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Jon Meredith >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > Inbound connections can come from anywhere and the warning / stack trace is > unhelpful so I'd like to downgrade to a simple single-line INFO message when > authorization fails to reduce clutter in the logs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16958) Prewarm role and credentials caches to avoid timeouts at startup
[ https://issues.apache.org/jira/browse/CASSANDRA-16958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16958: Status: Review In Progress (was: Patch Available) > Prewarm role and credentials caches to avoid timeouts at startup > > > Key: CASSANDRA-16958 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16958 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > With our current auth querying setup, you can end up with a thundering herd > on reconnect due to delays on auth resolution. > We should instead allow the ability to do a 'select' on all roles and > pre-load the cache before turning on native transport. Notably, this could > present some unacceptable delays on start with a very large count of users > (thousands), or someone who uses a third party auth system rather than the > built-in authorizer so this should be configurable and opt-in. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17068) Failed inbound internode authentication failures generate ugly warning with stack trace
[ https://issues.apache.org/jira/browse/CASSANDRA-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-17068: - Fix Version/s: 4.x (was: 4.0.x) > Failed inbound internode authentication failures generate ugly warning with > stack trace > --- > > Key: CASSANDRA-17068 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17068 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.x > > > Inbound connections can come from anywhere and the warning / stack trace is > unhelpful so I'd like to downgrade to a simple single-line INFO message when > authorization fails to reduce clutter in the logs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17214) Cannot restart a node when there are other nodes being down in in-jvm dtest framework
[
https://issues.apache.org/jira/browse/CASSANDRA-17214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474687#comment-17474687
]
Michael Semb Wever commented on CASSANDRA-17214:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1362/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1362/]
> Cannot restart a node when there are other nodes being down in in-jvm dtest
> framework
> -
>
> Key: CASSANDRA-17214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17214
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.x
>
>
> Such scenario:
> {code:java}
> @Test
> public void test() throws Exception
> {
> try (Cluster cluster =
> init(Cluster.build(2).withDataDirCount(1)).start()))
> {
> FBUtilities.waitOnFuture(cluster.get(2).shutdown());
> FBUtilities.waitOnFuture(cluster.get(1).shutdown());
> cluster.get(1).startup();
> cluster.get(2).startup();
> }
> }
> {code}
> throws
> {noformat}
> java.lang.IllegalStateException: Can't use shut down instances, delegate is
> null
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.delegate(AbstractCluster.java:210)
> at
> org.apache.cassandra.distributed.impl.DelegatingInvokableInstance.getMessagingVersion(DelegatingInvokableInstance.java:90)
> at
> org.apache.cassandra.distributed.action.GossipHelper.unsafeStatusToNormal(GossipHelper.java:95)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$null$10(Instance.java:640)
> {noformat}
> when we do not use {{Gossiper}} feature flag.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17248) Fix Prepared Statements behaviours after 15252
[ https://issues.apache.org/jira/browse/CASSANDRA-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-17248: Reviewers: Marcus Eriksson, Alex Petrov Marcus Eriksson, Alex Petrov (was: Alex Petrov, Marcus Eriksson) Status: Review In Progress (was: Patch Available) > Fix Prepared Statements behaviours after 15252 > -- > > Key: CASSANDRA-17248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17248 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > [CASSANDRA-15252] has fixed an important issue: unwanted hash changes when > preparing fully qualified prepared statements which was causing > cluster-killing re-prepare loops. However, the fix introduced a regression: > non-qualified statements can get prepared against one keyspace but then > executed on another under some circumstances. This patch reconciles all > behaviours. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17248) Fix Prepared Statements behaviours after 15252
[ https://issues.apache.org/jira/browse/CASSANDRA-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-17248: Test and Documentation Plan: Tests included. 3.0 and 3.11 branches were also tested with mixed mode tester separately, but commit was not included since it required a change in driver version to work. It is included in 4.0 and trunk Status: Patch Available (was: Open) > Fix Prepared Statements behaviours after 15252 > -- > > Key: CASSANDRA-17248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17248 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > [CASSANDRA-15252] has fixed an important issue: unwanted hash changes when > preparing fully qualified prepared statements which was causing > cluster-killing re-prepare loops. However, the fix introduced a regression: > non-qualified statements can get prepared against one keyspace but then > executed on another under some circumstances. This patch reconciles all > behaviours. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Deleted] (CASSANDRA-17257) syl test
[ https://issues.apache.org/jira/browse/CASSANDRA-17257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams deleted CASSANDRA-17257: - > syl test > > > Key: CASSANDRA-17257 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17257 > Project: Cassandra > Issue Type: Improvement >Reporter: jxjgssylsg >Assignee: jxjgssylsg >Priority: Normal > Labels: lhf, ponies, qa-resolved > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17257) syl test
[ https://issues.apache.org/jira/browse/CASSANDRA-17257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jxjgssylsg updated CASSANDRA-17257: --- Flagged: (was: Impediment) > syl test > > > Key: CASSANDRA-17257 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17257 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Gossip >Reporter: jxjgssylsg >Assignee: jxjgssylsg >Priority: Normal > Labels: lhf, ponies, qa-resolved > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17257) syl test
[ https://issues.apache.org/jira/browse/CASSANDRA-17257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jxjgssylsg updated CASSANDRA-17257: --- Flagged: Impediment > syl test > > > Key: CASSANDRA-17257 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17257 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Gossip >Reporter: jxjgssylsg >Assignee: jxjgssylsg >Priority: Normal > Labels: lhf, ponies, qa-resolved > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17257) syl test
[ https://issues.apache.org/jira/browse/CASSANDRA-17257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jxjgssylsg reassigned CASSANDRA-17257: -- Assignee: jxjgssylsg > syl test > > > Key: CASSANDRA-17257 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17257 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Gossip >Reporter: jxjgssylsg >Assignee: jxjgssylsg >Priority: Normal > Labels: lhf, ponies, qa-resolved > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17214) Cannot restart a node when there are other nodes being down in in-jvm dtest framework
[
https://issues.apache.org/jira/browse/CASSANDRA-17214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474603#comment-17474603
]
Michael Semb Wever commented on CASSANDRA-17214:
bq. Thank you Michael Semb Wever I merged you PR to my branch - is that ok?
Yup! Feel free then to squash the squash. (And remember to throwaway the
throwaway - it's only for CI :)
> Cannot restart a node when there are other nodes being down in in-jvm dtest
> framework
> -
>
> Key: CASSANDRA-17214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17214
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.x
>
>
> Such scenario:
> {code:java}
> @Test
> public void test() throws Exception
> {
> try (Cluster cluster =
> init(Cluster.build(2).withDataDirCount(1)).start()))
> {
> FBUtilities.waitOnFuture(cluster.get(2).shutdown());
> FBUtilities.waitOnFuture(cluster.get(1).shutdown());
> cluster.get(1).startup();
> cluster.get(2).startup();
> }
> }
> {code}
> throws
> {noformat}
> java.lang.IllegalStateException: Can't use shut down instances, delegate is
> null
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.delegate(AbstractCluster.java:210)
> at
> org.apache.cassandra.distributed.impl.DelegatingInvokableInstance.getMessagingVersion(DelegatingInvokableInstance.java:90)
> at
> org.apache.cassandra.distributed.action.GossipHelper.unsafeStatusToNormal(GossipHelper.java:95)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$null$10(Instance.java:640)
> {noformat}
> when we do not use {{Gossiper}} feature flag.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17257) syl test
[ https://issues.apache.org/jira/browse/CASSANDRA-17257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jxjgssylsg updated CASSANDRA-17257: --- Change Category: Performance Complexity: Low Hanging Fruit Component/s: Cluster/Gossip Status: Open (was: Triage Needed) > syl test > > > Key: CASSANDRA-17257 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17257 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Gossip >Reporter: jxjgssylsg >Priority: Normal > Labels: lhf, ponies, qa-resolved > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17257) syl test
[ https://issues.apache.org/jira/browse/CASSANDRA-17257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jxjgssylsg updated CASSANDRA-17257: --- Labels: lhf ponies qa-resolved (was: ) > syl test > > > Key: CASSANDRA-17257 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17257 > Project: Cassandra > Issue Type: Improvement >Reporter: jxjgssylsg >Priority: Normal > Labels: lhf, ponies, qa-resolved > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17257) syl test
jxjgssylsg created CASSANDRA-17257: -- Summary: syl test Key: CASSANDRA-17257 URL: https://issues.apache.org/jira/browse/CASSANDRA-17257 Project: Cassandra Issue Type: Improvement Reporter: jxjgssylsg -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17248) Fix Prepared Statements behaviours after 15252
[ https://issues.apache.org/jira/browse/CASSANDRA-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472852#comment-17472852 ] Alex Petrov edited comment on CASSANDRA-17248 at 1/12/22, 2:12 PM: --- Preliminary patches (CI pending): |[17248-3.0|https://github.com/apache/cassandra/pull/1383]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=17248-3.0]| |[17248-3.11|https://github.com/apache/cassandra/pull/1394]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=17248-3.11]| |[17248-4.0|https://github.com/apache/cassandra/pull/1393]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=17248-4.0]| |[17248-trunk|https://github.com/apache/cassandra/pull/1403]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=17248-trunk]| was (Author: ifesdjeen): Preliminary patches (CI pending): |[17248-3.0|https://github.com/apache/cassandra/pull/1383]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=17248-3.0]| |[17248-3.11|https://github.com/apache/cassandra/pull/1394]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=17248-3.11]| |[17248-4.0|https://github.com/apache/cassandra/pull/1393]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=17248-4.0]| > Fix Prepared Statements behaviours after 15252 > -- > > Key: CASSANDRA-17248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17248 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > [CASSANDRA-15252] has fixed an important issue: unwanted hash changes when > preparing fully qualified prepared statements which was causing > cluster-killing re-prepare loops. However, the fix introduced a regression: > non-qualified statements can get prepared against one keyspace but then > executed on another under some circumstances. This patch reconciles all > behaviours. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17243) Fix BYTES_PER_MEGABIT in StreamManager
[
https://issues.apache.org/jira/browse/CASSANDRA-17243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474540#comment-17474540
]
Ekaterina Dimitrova edited comment on CASSANDRA-17243 at 1/12/22, 1:54 PM:
---
Oh, indeed you are right it dates earlier than CASSANDRA-16959.
Thinking more about it I am wondering whether it won't change a bit behavior
then and which branches to target for the fix.
Also, pre-4.0 we don't have _SetGetStreamThroughputTest_ which caught for me a
precision issue with CASSANDRA-15234 that _StreamManagerTest_ missed. But I
don't think this will be an issue here as 1000 * 1000 / 8 gives an integer
result. More of a concern to me is the change of the rate limit. On the other
hand it is a correctness issue...
I want to think of it a bit more on my end.
was (Author: e.dimitrova):
Oh, indeed you are right it dates earlier than CASSANDRA-16959.
Thinking more about it I am wondering whether it won't change a bit behavior
then and which branches to target for the fix.
Also, pre-4.0 we don't have _SetGetStreamThroughputTest_ which caught for me a
precision issue with CASSANDRA-15234 that _StreamManagerTest_ missed. But I
don't think this will be an issue here as 1000 * 1000 / 8 gives an integer
result. More of a concern to me is the change of the rate limit.
I want to think of it a bit more on my end.
> Fix BYTES_PER_MEGABIT in StreamManager
> --
>
> Key: CASSANDRA-17243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17243
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Ekaterina Dimitrova
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> While working on CASSANDRA-15234 I noticed BYTES_PER_MEGABIT constant in the
> {code:java}
> StreamManager
> {code}
> class. It was introduced in CASSANDRA-16959.
> The current formula converts actually bytes to mebibits.
> The change needed for 3.0, 3.11 and 4.0(I am currently changing rate
> parameters to be in MiB/s for trunk as part of CASSANDRA-15234):
> {code:java}
> public static final double BYTES_PER_MEGABIT = (1000 * 1000) / 8; // from bits
> {code}
> CC [~adelapena]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7409) Allow multiple overlapping sstables in L1
[ https://issues.apache.org/jira/browse/CASSANDRA-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-7409: Status: Open (was: Patch Available) > Allow multiple overlapping sstables in L1 > - > > Key: CASSANDRA-7409 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7409 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Carl Yeksigian >Assignee: Carl Yeksigian >Priority: Normal > Labels: compaction, lcs > Fix For: 4.x > > > Currently, when a normal L0 compaction takes place (not STCS), we take up to > MAX_COMPACTING_L0 L0 sstables and all of the overlapping L1 sstables and > compact them together. If we didn't have to deal with the overlapping L1 > tables, we could compact a higher number of L0 sstables together into a set > of non-overlapping L1 sstables. > This could be done by delaying the invariant that L1 has no overlapping > sstables. Going from L1 to L2, we would be compacting fewer sstables together > which overlap. > When reading, we will not have the same one sstable per level (except L0) > guarantee, but this can be bounded (once we have too many sets of sstables, > either compact them back into the same level, or compact them up to the next > level). > This could be generalized to allow any level to be the maximum for this > overlapping strategy. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17243) Fix BYTES_PER_MEGABIT in StreamManager
[
https://issues.apache.org/jira/browse/CASSANDRA-17243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474540#comment-17474540
]
Ekaterina Dimitrova edited comment on CASSANDRA-17243 at 1/12/22, 1:53 PM:
---
Oh, indeed you are right it dates earlier than CASSANDRA-16959.
Thinking more about it I am wondering whether it won't change a bit behavior
then and which branches to target for the fix.
Also, pre-4.0 we don't have _SetGetStreamThroughputTest_ which caught for me a
precision issue with CASSANDRA-15234 that _StreamManagerTest_ missed. But I
don't think this will be an issue here as 1000 * 1000 / 8 gives an integer
result. More of a concern to me is the change of the rate limit.
I want to think of it a bit more on my end.
was (Author: e.dimitrova):
Oh, indeed you are right it dates earlier than CASSANDRA-16959.
Thinking more about it I am wondering whether it won't change a bit behavior
then and which branches to target for the fix.
Pre-4.0 we don't have _SetGetStreamThroughputTest_ which caught for me a
precision issue with CASSANDRA-15234 that _StreamManagerTest_ missed.
I want to think of it a bit more on my end.
> Fix BYTES_PER_MEGABIT in StreamManager
> --
>
> Key: CASSANDRA-17243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17243
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Ekaterina Dimitrova
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> While working on CASSANDRA-15234 I noticed BYTES_PER_MEGABIT constant in the
> {code:java}
> StreamManager
> {code}
> class. It was introduced in CASSANDRA-16959.
> The current formula converts actually bytes to mebibits.
> The change needed for 3.0, 3.11 and 4.0(I am currently changing rate
> parameters to be in MiB/s for trunk as part of CASSANDRA-15234):
> {code:java}
> public static final double BYTES_PER_MEGABIT = (1000 * 1000) / 8; // from bits
> {code}
> CC [~adelapena]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17243) Fix BYTES_PER_MEGABIT in StreamManager
[
https://issues.apache.org/jira/browse/CASSANDRA-17243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474540#comment-17474540
]
Ekaterina Dimitrova commented on CASSANDRA-17243:
-
Oh, indeed you are right it dates earlier than CASSANDRA-16959.
Thinking more about it I am wondering whether it won't change a bit behavior
then and which branches to target for the fix.
Pre-4.0 we don't have _SetGetStreamThroughputTest_ which caught for me a
precision issue with CASSANDRA-15234 that _StreamManagerTest_ missed.
I want to think of it a bit more on my end.
> Fix BYTES_PER_MEGABIT in StreamManager
> --
>
> Key: CASSANDRA-17243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17243
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Ekaterina Dimitrova
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> While working on CASSANDRA-15234 I noticed BYTES_PER_MEGABIT constant in the
> {code:java}
> StreamManager
> {code}
> class. It was introduced in CASSANDRA-16959.
> The current formula converts actually bytes to mebibits.
> The change needed for 3.0, 3.11 and 4.0(I am currently changing rate
> parameters to be in MiB/s for trunk as part of CASSANDRA-15234):
> {code:java}
> public static final double BYTES_PER_MEGABIT = (1000 * 1000) / 8; // from bits
> {code}
> CC [~adelapena]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7409) Allow multiple overlapping sstables in L1
[ https://issues.apache.org/jira/browse/CASSANDRA-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jxjgssylsg updated CASSANDRA-7409: -- Test and Documentation Plan: test Status: Patch Available (was: Open) > Allow multiple overlapping sstables in L1 > - > > Key: CASSANDRA-7409 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7409 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Carl Yeksigian >Assignee: Carl Yeksigian >Priority: Normal > Labels: compaction, lcs > Fix For: 4.x > > > Currently, when a normal L0 compaction takes place (not STCS), we take up to > MAX_COMPACTING_L0 L0 sstables and all of the overlapping L1 sstables and > compact them together. If we didn't have to deal with the overlapping L1 > tables, we could compact a higher number of L0 sstables together into a set > of non-overlapping L1 sstables. > This could be done by delaying the invariant that L1 has no overlapping > sstables. Going from L1 to L2, we would be compacting fewer sstables together > which overlap. > When reading, we will not have the same one sstable per level (except L0) > guarantee, but this can be bounded (once we have too many sets of sstables, > either compact them back into the same level, or compact them up to the next > level). > This could be generalized to allow any level to be the maximum for this > overlapping strategy. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17243) Fix BYTES_PER_MEGABIT in StreamManager
[
https://issues.apache.org/jira/browse/CASSANDRA-17243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474522#comment-17474522
]
Andres de la Peña edited comment on CASSANDRA-17243 at 1/12/22, 1:37 PM:
-
Very good catch. Indeed the mistake of confusing megabits with mebibits was
originally introduced by CASSANDRA-5286, back in 2.0, and it has been
overlooked by multiple fixes around that calculation.
The straightforward fix is simply the one mentioned by [~e.dimitrova]:
||PR||CI||
|[3.0|https://github.com/apache/cassandra/pull/1399]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1236/workflows/e3c3a592-4be7-4bab-8ced-ec6719e78a18]|
|[3.11|https://github.com/apache/cassandra/pull/1400]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1235/workflows/679af579-50d6-46b5-a5cb-9bf4b3986cc6]|
|[4.0|https://github.com/apache/cassandra/pull/1401]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1238/workflows/c8981fa3-5770-4970-beee-1bc44f3b04b8]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1238/workflows/27fbf649-60d5-4d8f-b6bf-0a0055fe8917]|
|[trunk|https://github.com/apache/cassandra/pull/1402]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1237/workflows/0805970f-2358-40f9-87c7-ac429c979c08]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1237/workflows/91b1bec3-8bac-4771-9597-64546d7a6100]|
The CI runs above contain some repeated runs of {{{}StreamManagerTest{}}}. Any
test is going to be based on the definition of a megabit, so I don't know if we
can add a new test for this.
was (Author: adelapena):
Very good catch. Indeed the mistake of confusing megabits with mebibits was
originally introduced by CASSANDRA-5286, back in 2.0, and it has been
overlooked by multiple fixes around that calculation.
The straightforward fix is simply the one mentioned by [~e.dimitrova]:
||PR||CI||
|[3.0|https://github.com/apache/cassandra/pull/1399]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1236/workflows/e3c3a592-4be7-4bab-8ced-ec6719e78a18]|
|[3.11|https://github.com/apache/cassandra/pull/1400]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1235/workflows/679af579-50d6-46b5-a5cb-9bf4b3986cc6]|
|[4.0|https://github.com/apache/cassandra/pull/1401]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1238/workflows/c8981fa3-5770-4970-beee-1bc44f3b04b8]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1238/workflows/27fbf649-60d5-4d8f-b6bf-0a0055fe8917]|
|[trunk|https://github.com/apache/cassandra/pull/1402]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1237/workflows/0805970f-2358-40f9-87c7-ac429c979c08]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1237/workflows/91b1bec3-8bac-4771-9597-64546d7a6100]|
The CI runs above contain some repeated runs of {{{}StreamManagerTest{}}}. Any
test is going to be based on the definition of a megabit, so I don't know if we
should add anything there.
> Fix BYTES_PER_MEGABIT in StreamManager
> --
>
> Key: CASSANDRA-17243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17243
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Ekaterina Dimitrova
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> While working on CASSANDRA-15234 I noticed BYTES_PER_MEGABIT constant in the
> {code:java}
> StreamManager
> {code}
> class. It was introduced in CASSANDRA-16959.
> The current formula converts actually bytes to mebibits.
> The change needed for 3.0, 3.11 and 4.0(I am currently changing rate
> parameters to be in MiB/s for trunk as part of CASSANDRA-15234):
> {code:java}
> public static final double BYTES_PER_MEGABIT = (1000 * 1000) / 8; // from bits
> {code}
> CC [~adelapena]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17243) Fix BYTES_PER_MEGABIT in StreamManager
[
https://issues.apache.org/jira/browse/CASSANDRA-17243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474522#comment-17474522
]
Andres de la Peña edited comment on CASSANDRA-17243 at 1/12/22, 1:33 PM:
-
Very good catch. Indeed the mistake of confusing megabits with mebibits was
originally introduced by CASSANDRA-5286, back in 2.0, and it has been
overlooked by multiple fixes around that calculation.
The straightforward fix is simply the one mentioned by [~e.dimitrova]:
||PR||CI||
|[3.0|https://github.com/apache/cassandra/pull/1399]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1236/workflows/e3c3a592-4be7-4bab-8ced-ec6719e78a18]|
|[3.11|https://github.com/apache/cassandra/pull/1400]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1235/workflows/679af579-50d6-46b5-a5cb-9bf4b3986cc6]|
|[4.0|https://github.com/apache/cassandra/pull/1401]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1238/workflows/c8981fa3-5770-4970-beee-1bc44f3b04b8]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1238/workflows/27fbf649-60d5-4d8f-b6bf-0a0055fe8917]|
|[trunk|https://github.com/apache/cassandra/pull/1402]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1237/workflows/0805970f-2358-40f9-87c7-ac429c979c08]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1237/workflows/91b1bec3-8bac-4771-9597-64546d7a6100]|
The CI runs above contain some repeated runs of {{{}StreamManagerTest{}}}. Any
test is going to be based on the definition of a megabit, so I don't know if we
should add anything there.
was (Author: adelapena):
Very good catch. Indeed the mistake of confusing megabits with mebibits was
originally introduced by CASSANDRA-5286, back in 2.0, and it has been
overlooked by multiple fixes around that calculation.
The straightforward fix is simply the one mentioned by [~e.dimitrova]:
||PR||CI||
|[3.0|https://github.com/apache/cassandra/pull/1399]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1236/workflows/e3c3a592-4be7-4bab-8ced-ec6719e78a18]|
|[3.11|https://github.com/apache/cassandra/pull/1400]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1235/workflows/679af579-50d6-46b5-a5cb-9bf4b3986cc6]|
|[4.0|https://github.com/apache/cassandra/pull/1401]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1238/workflows/c8981fa3-5770-4970-beee-1bc44f3b04b8]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1238/workflows/27fbf649-60d5-4d8f-b6bf-0a0055fe8917]|
|[trunk|https://github.com/apache/cassandra/pull/1402]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1237/workflows/0805970f-2358-40f9-87c7-ac429c979c08]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1237/workflows/91b1bec3-8bac-4771-9597-64546d7a6100]|
The CI runs above contain some repeated runs of {{{}StreamManagerTest{}}}.
> Fix BYTES_PER_MEGABIT in StreamManager
> --
>
> Key: CASSANDRA-17243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17243
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Ekaterina Dimitrova
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> While working on CASSANDRA-15234 I noticed BYTES_PER_MEGABIT constant in the
> {code:java}
> StreamManager
> {code}
> class. It was introduced in CASSANDRA-16959.
> The current formula converts actually bytes to mebibits.
> The change needed for 3.0, 3.11 and 4.0(I am currently changing rate
> parameters to be in MiB/s for trunk as part of CASSANDRA-15234):
> {code:java}
> public static final double BYTES_PER_MEGABIT = (1000 * 1000) / 8; // from bits
> {code}
> CC [~adelapena]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17243) Fix BYTES_PER_MEGABIT in StreamManager
[
https://issues.apache.org/jira/browse/CASSANDRA-17243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17243:
--
Test and Documentation Plan: CI runs included
Status: Patch Available (was: In Progress)
> Fix BYTES_PER_MEGABIT in StreamManager
> --
>
> Key: CASSANDRA-17243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17243
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Ekaterina Dimitrova
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> While working on CASSANDRA-15234 I noticed BYTES_PER_MEGABIT constant in the
> {code:java}
> StreamManager
> {code}
> class. It was introduced in CASSANDRA-16959.
> The current formula converts actually bytes to mebibits.
> The change needed for 3.0, 3.11 and 4.0(I am currently changing rate
> parameters to be in MiB/s for trunk as part of CASSANDRA-15234):
> {code:java}
> public static final double BYTES_PER_MEGABIT = (1000 * 1000) / 8; // from bits
> {code}
> CC [~adelapena]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17243) Fix BYTES_PER_MEGABIT in StreamManager
[
https://issues.apache.org/jira/browse/CASSANDRA-17243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474522#comment-17474522
]
Andres de la Peña commented on CASSANDRA-17243:
---
Very good catch. Indeed the mistake of confusing megabits with mebibits was
originally introduced by CASSANDRA-5286, back in 2.0, and it has been
overlooked by multiple fixes around that calculation.
The straightforward fix is simply the one mentioned by [~e.dimitrova]:
||PR||CI||
|[3.0|https://github.com/apache/cassandra/pull/1399]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1236/workflows/e3c3a592-4be7-4bab-8ced-ec6719e78a18]|
|[3.11|https://github.com/apache/cassandra/pull/1400]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1235/workflows/679af579-50d6-46b5-a5cb-9bf4b3986cc6]|
|[4.0|https://github.com/apache/cassandra/pull/1401]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1238/workflows/c8981fa3-5770-4970-beee-1bc44f3b04b8]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1238/workflows/27fbf649-60d5-4d8f-b6bf-0a0055fe8917]|
|[trunk|https://github.com/apache/cassandra/pull/1402]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1237/workflows/0805970f-2358-40f9-87c7-ac429c979c08]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1237/workflows/91b1bec3-8bac-4771-9597-64546d7a6100]|
The CI runs above contain some repeated runs of {{{}StreamManagerTest{}}}.
> Fix BYTES_PER_MEGABIT in StreamManager
> --
>
> Key: CASSANDRA-17243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17243
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Ekaterina Dimitrova
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> While working on CASSANDRA-15234 I noticed BYTES_PER_MEGABIT constant in the
> {code:java}
> StreamManager
> {code}
> class. It was introduced in CASSANDRA-16959.
> The current formula converts actually bytes to mebibits.
> The change needed for 3.0, 3.11 and 4.0(I am currently changing rate
> parameters to be in MiB/s for trunk as part of CASSANDRA-15234):
> {code:java}
> public static final double BYTES_PER_MEGABIT = (1000 * 1000) / 8; // from bits
> {code}
> CC [~adelapena]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
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 (eb4b1dd -> b8dec3e)
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 eb4b1dd generate docs for b70dcb85 new b8dec3e generate docs for b70dcb85 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 (eb4b1dd) \ N -- N -- N refs/heads/asf-staging (b8dec3e) 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 4740057 -> 4740057 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-17214) Cannot restart a node when there are other nodes being down in in-jvm dtest framework
[
https://issues.apache.org/jira/browse/CASSANDRA-17214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474489#comment-17474489
]
Jacek Lewandowski commented on CASSANDRA-17214:
---
Thank you [~mck] I merged you PR to my branch - is that ok?
> Cannot restart a node when there are other nodes being down in in-jvm dtest
> framework
> -
>
> Key: CASSANDRA-17214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17214
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.x
>
>
> Such scenario:
> {code:java}
> @Test
> public void test() throws Exception
> {
> try (Cluster cluster =
> init(Cluster.build(2).withDataDirCount(1)).start()))
> {
> FBUtilities.waitOnFuture(cluster.get(2).shutdown());
> FBUtilities.waitOnFuture(cluster.get(1).shutdown());
> cluster.get(1).startup();
> cluster.get(2).startup();
> }
> }
> {code}
> throws
> {noformat}
> java.lang.IllegalStateException: Can't use shut down instances, delegate is
> null
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.delegate(AbstractCluster.java:210)
> at
> org.apache.cassandra.distributed.impl.DelegatingInvokableInstance.getMessagingVersion(DelegatingInvokableInstance.java:90)
> at
> org.apache.cassandra.distributed.action.GossipHelper.unsafeStatusToNormal(GossipHelper.java:95)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$null$10(Instance.java:640)
> {noformat}
> when we do not use {{Gossiper}} feature flag.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17248) Fix Prepared Statements behaviours after 15252
[ https://issues.apache.org/jira/browse/CASSANDRA-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-17248: Bug Category: Parent values: Correctness(12982)Level 1 values: Recoverable Corruption / Loss(12986) Complexity: Challenging Component/s: Messaging/Client Discovered By: Fuzz Test Severity: Critical Status: Open (was: Triage Needed) > Fix Prepared Statements behaviours after 15252 > -- > > Key: CASSANDRA-17248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17248 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > [CASSANDRA-15252] has fixed an important issue: unwanted hash changes when > preparing fully qualified prepared statements which was causing > cluster-killing re-prepare loops. However, the fix introduced a regression: > non-qualified statements can get prepared against one keyspace but then > executed on another under some circumstances. This patch reconciles all > behaviours. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17248) Fix Prepared Statements behaviours after 15252
[ https://issues.apache.org/jira/browse/CASSANDRA-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov reassigned CASSANDRA-17248: --- Assignee: Alex Petrov > Fix Prepared Statements behaviours after 15252 > -- > > Key: CASSANDRA-17248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17248 > Project: Cassandra > Issue Type: Bug >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > [CASSANDRA-15252] has fixed an important issue: unwanted hash changes when > preparing fully qualified prepared statements which was causing > cluster-killing re-prepare loops. However, the fix introduced a regression: > non-qualified statements can get prepared against one keyspace but then > executed on another under some circumstances. This patch reconciles all > behaviours. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16801) PasswordObfuscator should not assume PASSWORD is the last item in the WITH clause
[
https://issues.apache.org/jira/browse/CASSANDRA-16801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474450#comment-17474450
]
Berenguer Blasi commented on CASSANDRA-16801:
-
Thanks [~blerer] for your latest review. I have rebased, added a PR for trunk
which happens to be identical and CI for both. Now waiting on final +1s and
let's merge it! :-)
> PasswordObfuscator should not assume PASSWORD is the last item in the WITH
> clause
> -
>
> Key: CASSANDRA-16801
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16801
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Caleb Rackliffe
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> CASSANDRA-16669 introduced support for obfuscating passwords for audit log
> statements, but there are a few cases where the obfuscation logic can destroy
> some of the contents of the original/provided string.
> ex. This is perfectly valid...
> {noformat}
> WITH LOGIN = false AND PASSWORD = 'bar' AND SUPERUSER = false
> {noformat}
> ...but calling obfuscate() on it will produce...
> {noformat}
> WITH LOGIN = false AND PASSWORD ***
> {noformat}
> -We should be able to create a reasonable RegEx and use String#replaceAll()
> to both simplify and correct PasswordObfuscator#obfuscate().-
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
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 (bc54922 -> eb4b1dd)
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 bc54922 generate docs for b70dcb85 new eb4b1dd generate docs for b70dcb85 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 (bc54922) \ N -- N -- N refs/heads/asf-staging (eb4b1dd) 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 4740057 -> 4740057 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-16916) Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474336#comment-17474336
]
Jogesh Anand commented on CASSANDRA-16916:
--
[~blerer] - thanks for taking the time to review. (y) Addressed & pushed the
changes. Also, updated PR with my comments. Please take a look.
[~e.dimitrova] - thank you for running CI. :) please review and would wait for
your review comments. I see some failures on CI and maybe those are related to
the changes. Would be great if you could share some info on those as well.
Once, I address the review comments, I was thinking of rebasing with
_cassandra-4.0_ branch, squashing commits and force-push.
> Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
> ---
>
> Key: CASSANDRA-16916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16916
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Jogesh Anand
>Priority: Normal
>
> It would make sense to add support for {{IF EXISTS}} and {{IF NOT EXISTS}} in
> the different {{ALTER}} statements.
> For example:
> * {{ALTER TABLE IF EXISTS myTable ...}}
> * {{ALTER TABLE myTable ADD IF NOT EXISTS ...}}
> * {{ALTER TABLE myTable DROP IF EXISTS ...}}
> * {{ALTER TYPE IF EXISTS myType ...}}
> * {{ALTER TYPE myType ADD IF NOT EXISTS ...}}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the {{Parser.g}}
> ANTLR file located in the src/antlr directory and the java classes
> corresponding to the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package. You can look at the
> CreateTableStatement class to see how it was done there.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
