[cassandra-website] branch asf-staging updated (b53b217fc -> c16ab3bf7)
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 b53b217fc generate docs for 9b5fa3b6 new c16ab3bf7 generate docs for 9b5fa3b6 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 (b53b217fc) \ N -- N -- N refs/heads/asf-staging (c16ab3bf7) 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/doc/4.2/cassandra/cql/functions.html | 41 + .../4.2/cassandra/tools/nodetool/bootstrap.html| 6 +- .../doc/4.2/cassandra/tools/nodetool/nodetool.html | 8 +-- .../4.2/cassandra/tools/nodetool/repair_admin.html | 64 ++--- content/doc/trunk/cassandra/cql/functions.html | 41 + .../trunk/cassandra/tools/nodetool/bootstrap.html | 6 +- .../trunk/cassandra/tools/nodetool/nodetool.html | 8 +-- .../cassandra/tools/nodetool/repair_admin.html | 64 ++--- content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4970139 -> 4970139 bytes 10 files changed, 159 insertions(+), 81 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637382#comment-17637382
]
Stefan Miklosovic edited comment on CASSANDRA-18042 at 11/22/22 6:27 PM:
-
I ve just finished this version in a different PR (we can just throw it away if
decided as not worthy to merge)
That one includes "ensureDisabled" methods and the logic is done as I suggested
above. Properties are
{code}
zero_default_ttl_on_twcs_disallowed: false
zero_default_ttl_on_twcs_warned: true
{code}
I think that adding "ensureDisabled" methods to EnableFlag are quite handy and
it is easy to code and it improves readability when we do not have to revert
that logic in the code.
https://github.com/apache/cassandra/pull/2027/files
EDIT: btw we might have this:
{code}
zero_default_ttl_on_twcs_disabled: false
zero_default_ttl_on_twcs_warned: true
{code}
_enabled is there already, _disabled could be introduced too. It is not easy to
"invert" zero_default_ttl_on_twcs itself so we might have "_enabled". For that
reason it seems to be more user-friendly if we have _disabled for this one.
Then in the code it would be like this which is quite natural to me.
{code}
Guardrails.zeroDefaultTTLOnTWCSDisabled.ensureDisabled(state);
{code}
was (Author: smiklosovic):
I ve just finished this version in a different PR (we can just throw it away if
decided as not worthy to merge)
That one includes "ensureDisabled" methods and the logic is done as I suggested
above. Properties are
{code}
zero_default_ttl_on_twcs_disallowed: false
zero_default_ttl_on_twcs_warned: true
{code}
I think that adding "ensureDisabled" methods to EnableFlag are quite handy and
it is easy to code and it improves readability when we do not have to revert
that logic in the code.
https://github.com/apache/cassandra/pull/2027/files
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637384#comment-17637384
]
Ekaterina Dimitrova commented on CASSANDRA-17221:
-
For the record, I am fine with all the last rebase, changes, etc. The one
failing test is a known failure I've seen before and has nothing to do with the
current patch. There Is a ticket CASSANDRA-15239
Thank you so much [~xvade] for your work and patience!
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.2
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637382#comment-17637382
]
Stefan Miklosovic commented on CASSANDRA-18042:
---
I ve just finished this version in a different PR (we can just throw it away if
decided as not worthy to merge)
That one includes "ensureDisabled" methods and the logic is done as I suggested
above. Properties are
{code}
zero_default_ttl_on_twcs_disallowed: false
zero_default_ttl_on_twcs_warned: true
{code}
I think that adding "ensureDisabled" methods to EnableFlag are quite handy and
it is easy to code and it improves readability when we do not have to revert
that logic in the code.
https://github.com/apache/cassandra/pull/2027/files
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637380#comment-17637380
]
Benjamin Lerer commented on CASSANDRA-17221:
Thanks a lot for your hard work [~xvade] and sorry for dropping the ball so
often.
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.2
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17221:
---
Fix Version/s: 4.2
(was: 4.x)
Source Control Link: https://github.com/apache/cassandra/commits/trunk
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into trunk at 88dc64d2086c9a91f00ee024b8ef13cb2c193ee6
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.2
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Add Mathematical Functions
This is an automated email from the ASF dual-hosted git repository. blerer pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 88dc64d208 Add Mathematical Functions 88dc64d208 is described below commit 88dc64d2086c9a91f00ee024b8ef13cb2c193ee6 Author: XV4DE AuthorDate: Sat May 14 12:28:40 2022 -0700 Add Mathematical Functions Patch by Simon Chess; review by Benjamin Lerer Ekaterina Dimitrova for CASSANDRA-17221 This patch add the abs, exp, log, log10, and round functions for the numeric types. --- .build/cassandra-deps-template.xml | 4 + .build/parent-pom-template.xml | 5 + CHANGES.txt| 1 + NEWS.txt | 1 + doc/modules/cassandra/pages/cql/functions.adoc | 20 ++ .../apache/cassandra/cql3/functions/MathFcts.java | 134 + .../cassandra/cql3/functions/NativeFunctions.java | 1 + .../org/apache/cassandra/db/marshal/ByteType.java | 30 ++ .../cassandra/db/marshal/CounterColumnType.java| 30 ++ .../apache/cassandra/db/marshal/DecimalType.java | 59 .../apache/cassandra/db/marshal/DoubleType.java| 30 ++ .../org/apache/cassandra/db/marshal/FloatType.java | 30 ++ .../org/apache/cassandra/db/marshal/Int32Type.java | 30 ++ .../apache/cassandra/db/marshal/IntegerType.java | 44 +++ .../org/apache/cassandra/db/marshal/LongType.java | 30 ++ .../apache/cassandra/db/marshal/NumberType.java| 49 +++ .../org/apache/cassandra/db/marshal/ShortType.java | 30 ++ .../cassandra/cql3/functions/MathFctsTest.java | 331 + 18 files changed, 859 insertions(+) diff --git a/.build/cassandra-deps-template.xml b/.build/cassandra-deps-template.xml index 96c6c5379b..44f9f35ab3 100644 --- a/.build/cassandra-deps-template.xml +++ b/.build/cassandra-deps-template.xml @@ -340,6 +340,10 @@ com.github.seancfoley ipaddress + + ch.obermuhlner + big-math + org.agrona agrona diff --git a/.build/parent-pom-template.xml b/.build/parent-pom-template.xml index a76c46bc72..752645599d 100644 --- a/.build/parent-pom-template.xml +++ b/.build/parent-pom-template.xml @@ -1029,6 +1029,11 @@ agrona 1.17.1 + +ch.obermuhlner +big-math +2.3.0 + diff --git a/CHANGES.txt b/CHANGES.txt index 39363ac4c4..d64521fdea 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.2 + * Add Mathematical functions (CASSANDRA-17221) * Make incremental backup configurable per table (CASSANDRA-15402) * Change shebangs of Python scripts to resolve Python 3 from env command (CASSANDRA-17832) * Add reasons to guardrail messages and consider guardrails in the error message for needed ALLOW FILTERING (CASSANDRA-17967) diff --git a/NEWS.txt b/NEWS.txt index bc94c640c0..2238c43f36 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -57,6 +57,7 @@ using the provided 'sstableupgrade' tool. New features +- Added new Mathematical CQL functions: abs, exp, log, log10 and round. - Adds a trie-based memtable implementation, which improves memory use, garbage collection efficiency and lookup performance. The new memtable is implemented by the TrieMemtable class and can be selected using the memtable API, see src/java/org/apache/cassandra/db/memtable/Memtable_API.md. diff --git a/doc/modules/cassandra/pages/cql/functions.adoc b/doc/modules/cassandra/pages/cql/functions.adoc index 93439a322e..39fc9860a4 100644 --- a/doc/modules/cassandra/pages/cql/functions.adoc +++ b/doc/modules/cassandra/pages/cql/functions.adoc @@ -238,6 +238,26 @@ For every xref:cql/types.adoc#native-types[type] supported by CQL, the function Conversely, the function `blobAsType` takes a 64-bit `blob` argument and converts it to a `bigint` value. For example, `bigintAsBlob(3)` returns `0x0003` and `blobAsBigint(0x0003)` returns `3`. + Math Functions + +Cql provides the following math functions: `abs`, `exp`, `log`, `log10`, and `round`. +The return type for these functions is always the same as the input type. + +[cols=",",options="header",] +|=== +|Function name |Description + +|`abs` | Returns the absolute value of the input. + +|`exp` | Returns the number e to the power of the input. + +|`log` | Returns the natural log of the input. + +|`log10` | Returns the log base 10 of the input. + +|`round` | Rounds the input to the nearest whole number using rounding mode `HALF_UP`. +|=== + [[user-defined-scalar-functions]] User-defined functions diff --git a/src/java/org/apache/cassandra/cql3/functions/MathFcts.java b/src/java/org/apache/cassandra/cql3/functions/MathFcts.java new file mode 100644 index 00..553ac40fe0 --- /dev/null +++
[jira] [Comment Edited] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637373#comment-17637373
]
Andres de la Peña edited comment on CASSANDRA-18042 at 11/22/22 5:22 PM:
-
I was thinking on {{_warned}} instead of {{{}_warn{}}}, so it's more similar to
the existing {{{}_enabled{}}}:
{code:java}
zero_default_ttl_on_twcs_warned: true
zero_default_ttl_on_twcs_enabled: true
{code}
Or it could also be:
{code:java}
zero_default_ttl_on_twcs_discouraged: true
zero_default_ttl_on_twcs_enabled: true
{code}
It's a bit odd however that the two boolean properties have different
behaviours, where {{_enabled}} triggers the guardrails when it's {{{}false{}}},
whereas and {{_warned}} triggers it when it's {{{}true{}}}.
That would be solved by:
{code:java}
zero_default_ttl_on_twcs_warn: true
zero_default_ttl_on_twcs_fail: false
{code}
However, we already have multiple guardrails using {{_enabled}} in 4.1, and we
have to preserve them.
So using {{_fail}} for this guardrail would mean that {{EnableFlag}} sometimes
would receive {{_enabled}} properties, and sometimes would receive {{_fail}}
properties. That's not ideal and it might be problematic if at some point we
want to automatically generate property names from guardrail names.
Maybe [~jmckenzie], who has added a bunch of enable flags, has an opinion on
this.
As for how we manage the true/false properties, we could easily reverse the
predicates that we pass to the constructor.
was (Author: adelapena):
I was thinking on {{_warned}} instead of {{{}_warn{}}}, so it's more similar to
the existing {{{}_enabled{}}}:
{code:java}
zero_default_ttl_on_twcs_warned: true
zero_default_ttl_on_twcs_enabled: true
{code}
Or it could also be:
{code:java}
zero_default_ttl_on_twcs_discouraged: true
zero_default_ttl_on_twcs_enabled: true
{code}
It's a bit odd however that the two boolean properties have different
behaviours, where {{_enabled}} triggers the guardrails when it's {{{}false{}}},
whereas and {{_warned}} triggers it when it's {{{}true{}}}.
That would be solved by:
{code:java}
zero_default_ttl_on_twcs_fail: false
zero_default_ttl_on_twcs_warn: true
{code}
However, we already have multiple guardrails using {{_enabled}} in 4.1, and we
have to preserve them.
So using {{_fail}} for this guardrail would mean that {{EnableFlag}} sometimes
would receive {{_enabled}} properties, and sometimes would receive {{_fail}}
properties. That's not ideal and it might be problematic if at some point we
want to automatically generate property names from guardrail names.
Maybe [~jmckenzie], who has added a bunch of enable flags, has an opinion on
this.
As for how we manage the true/false properties, we could easily reverse the
predicates that we pass to the constructor.
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing
[jira] [Commented] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637373#comment-17637373
]
Andres de la Peña commented on CASSANDRA-18042:
---
I was thinking on {{_warned}} instead of {{{}_warn{}}}, so it's more similar to
the existing {{{}_enabled{}}}:
{code:java}
zero_default_ttl_on_twcs_warned: true
zero_default_ttl_on_twcs_enabled: true
{code}
Or it could also be:
{code:java}
zero_default_ttl_on_twcs_discouraged: true
zero_default_ttl_on_twcs_enabled: true
{code}
It's a bit odd however that the two boolean properties have different
behaviours, where {{_enabled}} triggers the guardrails when it's {{{}false{}}},
whereas and {{_warned}} triggers it when it's {{{}true{}}}.
That would be solved by:
{code:java}
zero_default_ttl_on_twcs_fail: false
zero_default_ttl_on_twcs_warn: true
{code}
However, we already have multiple guardrails using {{_enabled}} in 4.1, and we
have to preserve them.
So using {{_fail}} for this guardrail would mean that {{EnableFlag}} sometimes
would receive {{_enabled}} properties, and sometimes would receive {{_fail}}
properties. That's not ideal and it might be problematic if at some point we
want to automatically generate property names from guardrail names.
Maybe [~jmckenzie], who has added a bunch of enable flags, has an opinion on
this.
As for how we manage the true/false properties, we could easily reverse the
predicates that we pass to the constructor.
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637371#comment-17637371
]
Benjamin Lerer commented on CASSANDRA-17221:
Hi [~xvade], I made some small changes to the patch as it needed rebasing due
to some changes in this area.
I reverted the renaming as we do not use {{Util}} for the Functions classes
([~e.dimitrova] did not know that ;-) ).
The patch is
[here|https://github.com/blerer/cassandra/commit/31c1938c1d306a2ba98d011a9d32a3a849a97e53].
[Ci|https://app.circleci.com/pipelines/github/blerer/cassandra/325/workflows/50b6065d-a8d2-4836-bfd8-316e4dfec400]
looks good.
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17221:
---
Status: Ready to Commit (was: Review In Progress)
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637364#comment-17637364
]
Benedict Elliott Smith commented on CASSANDRA-17530:
It wasn't when the patch was prepared, but it looks like it was merged shortly
after alpha.
> Paxos v2 Linearizability Violation
> --
>
> Key: CASSANDRA-17530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17530
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1-beta1, 4.1, 4.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The version of Paxos introduced recently had a subtle mistake that
> introduced a linearizability flaw that has been detected by the simulator,
> and also a flaw with the simulator has been found that may erroneously report
> a linearizability violation.
> The true linearizability fault is quite simple: fast read permissions were
> erroneously being escalated to promises when an incomplete proposal was
> discovered. This was likely due in part to the naming of the state
> {{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will
> be used to re-propose this proposal using the promises we have obtained. The
> fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.
> The false linearizability fault was triggered when two different competing
> incomplete proposals were reproposed multiple times, with the winning
> proposal being the one with the lower original ballot, and the proposal with
> the higher ballot having been successfully proposed to a majority of nodes
> but across multiple different ballots (so that no single ballot reached a
> majority), while the most recently successful ballot (at a minority) was the
> older original ballot. The range movement validation logic looked only at the
> original ballot, and since it saw the higher original ballot as having
> reached a majority perceived that it should have become persistent, when in
> fact the older ballot did so.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637349#comment-17637349
]
Stefan Miklosovic edited comment on CASSANDRA-18042 at 11/22/22 4:21 PM:
-
Thanks [~adelapena] for the review. I ve already incorporated your suggestions.
I do not mind to call it zero_default_ttl_on_twcs_enabled. With comments
included in cassandra.yaml it is pretty descriptive. However, I left MBean
method as it was, people invoking that does not have any documentation to look
into when called by tooling and it is better to be as much specific as possible.
PR reflects these changes.
So the only question is whether we should have warning flag too. For the
maximum flexibility we may include it. It is acceptable to have it if it is by
default enabled.
If we are going to have these properties:
{code:java}
zero_default_ttl_on_twcs_enabled: true
zero_default_ttl_on_twcs_warn: true
{code}
I think it would be better to call it like this:
{code:java}
zero_default_ttl_on_twcs_fail: false
zero_default_ttl_on_twcs_warn: true
{code}
We would then need to "revert" the logic so it would look like (notice negation
in the body of that if)
{code:java}
if (params.defaultTimeToLive == 0
&& !SchemaConstants.isSystemKeyspace(keyspaceName)
&&
TimeWindowCompactionStrategy.class.isAssignableFrom(params.compaction.klass()))
!Guardrails.zeroDefaultTTLOnTWCSEnabled.ensureEnabled(state);
{code}
This is a little bit hard to follow, what would be nice to have is to have
methods called "ensureDisabled" which is more natural to me so it would be like
{code:java}
if (params.defaultTimeToLive == 0
&& !SchemaConstants.isSystemKeyspace(keyspaceName)
&&
TimeWindowCompactionStrategy.class.isAssignableFrom(params.compaction.klass()))
Guardrails.zeroDefaultTTLOnTWCS.ensureDisabled(state);
{code}
what do you think?
EDIT:
looking at this more intensively, it is weird to be sure something is disabled
on a guardrail called "zeroDefaultTTLOnTWCS". It reads as if we are making sure
that zero ttl is NOT enabled, which is wrong as we want to proceed if it is
enabled.
was (Author: smiklosovic):
Thanks [~adelapena] for the review. I ve already incorporated your suggestions.
I do not mind to call it zero_default_ttl_on_twcs_enabled. With comments
included in cassandra.yaml it is pretty descriptive. However, I left MBean
method as it was, people invoking that does not have any documentation to look
into when called by tooling and it is better to be as much specific as
possible.
PR reflects these changes.
So the only question is whether we should have warning flag too. For the
maximum flexibility we may include it. It is acceptable to have it if it is by
default enabled.
If we are going to have these properties:
{code}
zero_default_ttl_on_twcs_enabled: true
zero_default_ttl_on_twcs_warn: true
{code}
I think it would be better to call it like this:
{code}
zero_default_ttl_on_twcs_fail: false
zero_default_ttl_on_twcs_warn: true
{code}
We would then need to "revert" the logic so it would look like (notice negation
in the body of that if)
{code}
if (params.defaultTimeToLive == 0
&& !SchemaConstants.isSystemKeyspace(keyspaceName)
&&
TimeWindowCompactionStrategy.class.isAssignableFrom(params.compaction.klass()))
!Guardrails.zeroDefaultTTLOnTWCSEnabled.ensureEnabled(state);
{code}
This is a little bit hard to follow, what would be nice to have is to have
methods called "ensureDisabled" which is more natural to me so it would be like
{code}
if (params.defaultTimeToLive == 0
&& !SchemaConstants.isSystemKeyspace(keyspaceName)
&&
TimeWindowCompactionStrategy.class.isAssignableFrom(params.compaction.klass()))
Guardrails.zeroDefaultTTLOnTWCS.ensureDisabled(state);
{code}
what do you think?
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
>
[jira] [Commented] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637349#comment-17637349
]
Stefan Miklosovic commented on CASSANDRA-18042:
---
Thanks [~adelapena] for the review. I ve already incorporated your suggestions.
I do not mind to call it zero_default_ttl_on_twcs_enabled. With comments
included in cassandra.yaml it is pretty descriptive. However, I left MBean
method as it was, people invoking that does not have any documentation to look
into when called by tooling and it is better to be as much specific as
possible.
PR reflects these changes.
So the only question is whether we should have warning flag too. For the
maximum flexibility we may include it. It is acceptable to have it if it is by
default enabled.
If we are going to have these properties:
{code}
zero_default_ttl_on_twcs_enabled: true
zero_default_ttl_on_twcs_warn: true
{code}
I think it would be better to call it like this:
{code}
zero_default_ttl_on_twcs_fail: false
zero_default_ttl_on_twcs_warn: true
{code}
We would then need to "revert" the logic so it would look like (notice negation
in the body of that if)
{code}
if (params.defaultTimeToLive == 0
&& !SchemaConstants.isSystemKeyspace(keyspaceName)
&&
TimeWindowCompactionStrategy.class.isAssignableFrom(params.compaction.klass()))
!Guardrails.zeroDefaultTTLOnTWCSEnabled.ensureEnabled(state);
{code}
This is a little bit hard to follow, what would be nice to have is to have
methods called "ensureDisabled" which is more natural to me so it would be like
{code}
if (params.defaultTimeToLive == 0
&& !SchemaConstants.isSystemKeyspace(keyspaceName)
&&
TimeWindowCompactionStrategy.class.isAssignableFrom(params.compaction.klass()))
Guardrails.zeroDefaultTTLOnTWCS.ensureDisabled(state);
{code}
what do you think?
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637345#comment-17637345
]
Michael Semb Wever edited comment on CASSANDRA-17530 at 11/22/22 4:02 PM:
--
bq. I don't think the bug didn't make it into any release, so was there any
change to note?
Was it not in {{4.1-alpha1}} ? (or have i misunderstood the since field field?)
was (Author: michaelsembwever):
bq. I don't think the bug didn't make it into any release, so was there any
change to note?
Was it not in {{4.1-alpha`}} ? (or have i misunderstood the since field field?)
> Paxos v2 Linearizability Violation
> --
>
> Key: CASSANDRA-17530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17530
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1-beta1, 4.1, 4.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The version of Paxos introduced recently had a subtle mistake that
> introduced a linearizability flaw that has been detected by the simulator,
> and also a flaw with the simulator has been found that may erroneously report
> a linearizability violation.
> The true linearizability fault is quite simple: fast read permissions were
> erroneously being escalated to promises when an incomplete proposal was
> discovered. This was likely due in part to the naming of the state
> {{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will
> be used to re-propose this proposal using the promises we have obtained. The
> fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.
> The false linearizability fault was triggered when two different competing
> incomplete proposals were reproposed multiple times, with the winning
> proposal being the one with the lower original ballot, and the proposal with
> the higher ballot having been successfully proposed to a majority of nodes
> but across multiple different ballots (so that no single ballot reached a
> majority), while the most recently successful ballot (at a minority) was the
> older original ballot. The range movement validation logic looked only at the
> original ballot, and since it saw the higher original ballot as having
> reached a majority perceived that it should have become persistent, when in
> fact the older ballot did so.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637345#comment-17637345
]
Michael Semb Wever commented on CASSANDRA-17530:
bq. I don't think the bug didn't make it into any release, so was there any
change to note?
Was it not in {{4.1-alpha`}} ? (or have i misunderstood the since field field?)
> Paxos v2 Linearizability Violation
> --
>
> Key: CASSANDRA-17530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17530
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1-beta1, 4.1, 4.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The version of Paxos introduced recently had a subtle mistake that
> introduced a linearizability flaw that has been detected by the simulator,
> and also a flaw with the simulator has been found that may erroneously report
> a linearizability violation.
> The true linearizability fault is quite simple: fast read permissions were
> erroneously being escalated to promises when an incomplete proposal was
> discovered. This was likely due in part to the naming of the state
> {{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will
> be used to re-propose this proposal using the promises we have obtained. The
> fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.
> The false linearizability fault was triggered when two different competing
> incomplete proposals were reproposed multiple times, with the winning
> proposal being the one with the lower original ballot, and the proposal with
> the higher ballot having been successfully proposed to a majority of nodes
> but across multiple different ballots (so that no single ballot reached a
> majority), while the most recently successful ballot (at a minority) was the
> older original ballot. The range movement validation logic looked only at the
> original ballot, and since it saw the higher original ballot as having
> reached a majority perceived that it should have become persistent, when in
> fact the older ballot did so.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637345#comment-17637345
]
Michael Semb Wever edited comment on CASSANDRA-17530 at 11/22/22 4:02 PM:
--
bq. I don't think the bug didn't make it into any release, so was there any
change to note?
Was it not in {{4.1-alpha1}} ? (or have i misunderstood the since field?)
was (Author: michaelsembwever):
bq. I don't think the bug didn't make it into any release, so was there any
change to note?
Was it not in {{4.1-alpha1}} ? (or have i misunderstood the since field field?)
> Paxos v2 Linearizability Violation
> --
>
> Key: CASSANDRA-17530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17530
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1-beta1, 4.1, 4.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The version of Paxos introduced recently had a subtle mistake that
> introduced a linearizability flaw that has been detected by the simulator,
> and also a flaw with the simulator has been found that may erroneously report
> a linearizability violation.
> The true linearizability fault is quite simple: fast read permissions were
> erroneously being escalated to promises when an incomplete proposal was
> discovered. This was likely due in part to the naming of the state
> {{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will
> be used to re-propose this proposal using the promises we have obtained. The
> fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.
> The false linearizability fault was triggered when two different competing
> incomplete proposals were reproposed multiple times, with the winning
> proposal being the one with the lower original ballot, and the proposal with
> the higher ballot having been successfully proposed to a majority of nodes
> but across multiple different ballots (so that no single ballot reached a
> majority), while the most recently successful ballot (at a minority) was the
> older original ballot. The range movement validation logic looked only at the
> original ballot, and since it saw the higher original ballot as having
> reached a majority perceived that it should have become persistent, when in
> fact the older ballot did so.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (707d6bb527 -> 48d4897828)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 707d6bb527 Merge branch 'cassandra-4.1' into trunk add b807f97b37 Prepare debian changelog for 4.1.0 new 48d4897828 Merge branch 'cassandra-4.1' into trunk 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: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 48d4897828e9f3fbbd033feb383ea6fbe6d0d96c Merge: 707d6bb527 b807f97b37 Author: Mick Semb Wever AuthorDate: Tue Nov 22 16:48:11 2022 +0100 Merge branch 'cassandra-4.1' into trunk * cassandra-4.1: Prepare debian changelog for 4.1.0 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (676b3e4483 -> b807f97b37)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 676b3e4483 Increment version to 4.1.0 add b807f97b37 Prepare debian changelog for 4.1.0 No new revisions were added by this update. Summary of changes: debian/changelog | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17769) Fix org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
[ https://issues.apache.org/jira/browse/CASSANDRA-17769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17769: --- Fix Version/s: 4.2 (was: 4.x) > Fix > org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest > --- > > Key: CASSANDRA-17769 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17769 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.1-rc1, 4.1, 4.2 > > Time Spent: 2h > Remaining Estimate: 0h > > Fix > org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest > failing on current trunk: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1795/workflows/bc8619bb-7301-4428-9662-bc24e5f38b87/jobs/13335/tests#failed-test-0 > and also in this run > https://app.circleci.com/pipelines/github/driftx/cassandra/551/workflows/ba8cadb9-025f-46f9-b663-69d9e956d30d/jobs/6596/tests -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17945) Fix StorageService.getNativeaddress handling of IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17945:
---
Fix Version/s: 4.0.7
(was: 4.0.x)
> Fix StorageService.getNativeaddress handling of IPv6 addresses
> --
>
> Key: CASSANDRA-17945
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17945
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.0.7, 4.1-rc1, 4.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> While upgrading a cluster using IPv6 addresses from 3.0 to 4.0 I noticed the
> following in logs for upgraded nodes when processing down events for 3.0
> nodes that are going down as part of an upgrade:
>
> {noformat}
> 2022-09-28 20:18:48,244 ERROR [GossipStage:1]
> org.apache.cassandra.transport.Server - Problem retrieving RPC address for
> /[0:0:0:0:0:0:0:d9]:7000
> java.net.UnknownHostException: 0:0:0:0:0:0:0:d9:9042: invalid IPv6 address
> at java.net.InetAddress.getAllByName(InetAddress.java:1355) ~[?:?]
> at java.net.InetAddress.getAllByName(InetAddress.java:1306) ~[?:?]
> at java.net.InetAddress.getByName(InetAddress.java:1256) ~[?:?]
> at
> org.apache.cassandra.locator.InetAddressAndPort.getByNameOverrideDefaults(InetAddressAndPort.java:227)
>
> at
> org.apache.cassandra.locator.InetAddressAndPort.getByName(InetAddressAndPort.java:212)
>
> at
> org.apache.cassandra.transport.Server$EventNotifier.getNativeAddress(Server.java:377)
>
> at
> org.apache.cassandra.transport.Server$EventNotifier.onDown(Server.java:438)
> at
> org.apache.cassandra.service.StorageService.notifyDown(StorageService.java:2651)
>
> at
> org.apache.cassandra.service.StorageService.onDead(StorageService.java:3516)
> at org.apache.cassandra.gms.Gossiper.markDead(Gossiper.java:1347)
> at org.apache.cassandra.gms.Gossiper.markAsShutdown(Gossiper.java:590)
> at
> org.apache.cassandra.gms.GossipShutdownVerbHandler.doVerb(GossipShutdownVerbHandler.java:39)
>
> at org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
>
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
> at java.lang.Thread.run(Thread.java:829) [?:?]{noformat}
> It appears that StorageService.getNativeaddress does not account for the fact
> that an endpoint may be an IPv6 address, which required brackets when
> specified with a port:
>
> [https://github.com/apache/cassandra/blob/cassandra-4.0.6/src/java/org/apache/cassandra/service/StorageService.java#L1978-L1981]
>
>
> {code:java}
> /**
> * Return the native address associated with an endpoint as a string.
> * @param endpoint The endpoint to get rpc address for
> * @return the native address
> */
> public String getNativeaddress(InetAddressAndPort endpoint, boolean
> withPort)
> {
> if (endpoint.equals(FBUtilities.getBroadcastAddressAndPort()))
> return
> FBUtilities.getBroadcastNativeAddressAndPort().getHostAddress(withPort);
> else if
> (Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT)
> != null)
> {
> try
> {
> InetAddressAndPort address =
> InetAddressAndPort.getByName(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT).value);
> return address.getHostAddress(withPort);
> }
> catch (UnknownHostException e)
> {
> throw new RuntimeException(e);
> }
> }
> else if
> (Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS)
> == null)
> return endpoint.address.getHostAddress() + ":" +
>
[jira] [Updated] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17005:
---
Fix Version/s: (was: 4.1-rc)
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.7, 4.1-rc1, 4.1, 4.2
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeout. For more information about
> server-side coordinator timeouts, see :class:`.policies.RetryPolicy`. Example
> usage:: >>> future = session.execute_async("SELECT * FROM mycf") >>> # do
> other stuff... >>> try: ... rows = future.result() ... for row in rows: ...
> ... # process results ... except
[jira] [Updated] (CASSANDRA-17617) CQLSH unicode control character list is too liberal
[ https://issues.apache.org/jira/browse/CASSANDRA-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17617: --- Fix Version/s: (was: 4.1-rc) > CQLSH unicode control character list is too liberal > --- > > Key: CASSANDRA-17617 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17617 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Tanuj Nayak >Assignee: Tanuj Nayak >Priority: Normal > Fix For: 3.11.14, 4.0.5, 4.1-rc1, 4.1, 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > It appears that the list of escaped unicode control characters > [here|https://github.com/apache/cassandra/blob/53a67ff2c36d90d337aba1409498de29931d4279/pylib/cqlshlib/formatting.py#L32] > is a bit too liberal. It seems to include characters such as '1' (0x31) and > '0' (0x30) which do not need to be escaped. It seems that the actual range > should be 0x00 - 0x1F and 0x7F+ as corroborated [by this > page|https://en.wikipedia.org/wiki/Unicode_control_characters]. > > This causes unnecessary escaping and regex substitutions on the CQLSH end > whenever common characters such as any punctuation or a 0 or a 1 appear in > the text column of a table. One might notice that a table with a text column > filled with 2's will take much less time to print than one with all 0's for > this reason. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17955) Race condition on repair snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-17955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17955:
---
Fix Version/s: (was: 4.1-rc)
> Race condition on repair snapshots
> --
>
> Key: CASSANDRA-17955
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17955
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Snapshots
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: 4.0
> Fix For: 4.0.8, 4.1-rc1, 4.1, 4.2
>
> Attachments: signature.asc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> If an endpoint is convicted and that endpoint is a coordinator then
> ActiveRepairService::removeParentRepairSession is called.
> The issue is that this occurs on clearSnapshotExecutor and can happen while
> RepairMessageVerbHandler is in process of taking a snapshot. So then you get
> a race condition and clearSnapshot will throw a
> java.nio.file.DirectoryNotEmptyException
>
> {code:java}
> public static void deleteRecursiveWithThrottle(File dir, RateLimiter
> rateLimiter)
> {
> if (dir.isDirectory())
> {
> String[] children = dir.list();
> for (String child : children)
> deleteRecursiveWithThrottle(new File(dir, child), rateLimiter);
> }
> // The directory is now empty so now it can be smoked
> deleteWithConfirmWithThrottle(dir, rateLimiter);
> } {code}
> Due to the directory not being empty when it goes to remove the directory at
> the end.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17934) Add --resolve-ip option on 'nodetool gossipinfo'
[ https://issues.apache.org/jira/browse/CASSANDRA-17934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17934: --- Fix Version/s: (was: 4.1-rc) > Add --resolve-ip option on 'nodetool gossipinfo' > > > Key: CASSANDRA-17934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17934 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Paulo Motta >Assignee: Maxim Chanturiay >Priority: Normal > Labels: lhf > Fix For: 4.1-rc1, 4.1, 4.2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Give nodetool gossipinfo the option of either displaying IPs or hostnames for > the nodes in a ring. > Note: this option is already present for "nodetool status" and "nodetool ring" -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17933) Zero length file in Audit log folder, prevents a node from starting
[
https://issues.apache.org/jira/browse/CASSANDRA-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17933:
---
Fix Version/s: (was: 4.1-rc)
> Zero length file in Audit log folder, prevents a node from starting
> ---
>
> Key: CASSANDRA-17933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17933
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Andrew Hogg
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.7, 4.1-rc1, 4.1, 4.2
>
> Attachments: signature.asc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have encountered a 4.0.3 cluster where the audit log folder had a zero
> byte length file within it after the node had stopped. It is not clear how
> Cassandra got to the point of this file existing. On restarting the node, the
> node will not start and throws the following stack trace.
> {code:java}
> ERROR [main] 2022-09-26 14:01:27,892 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:468)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException: Unable to
> create instance of IAuditLogger.
> at
> org.apache.cassandra.utils.FBUtilities.newAuditLogger(FBUtilities.java:686)
> at
> org.apache.cassandra.audit.AuditLogManager.getAuditLogger(AuditLogManager.java:95)
> at
> org.apache.cassandra.audit.AuditLogManager.(AuditLogManager.java:74)
> at
> org.apache.cassandra.audit.AuditLogManager.(AuditLogManager.java:60)
> ... 3 common frames omitted
> Caused by: java.lang.reflect.InvocationTargetException: null
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.cassandra.utils.FBUtilities.newAuditLogger(FBUtilities.java:682)
> ... 6 common frames omitted
> Caused by: java.nio.channels.OverlappingFileLockException: null
> at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
> at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152)
> at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1068)
> at java.nio.channels.FileChannel.lock(FileChannel.java:1053)
> at
> net.openhft.chronicle.bytes.MappedFile.resizeRafIfTooSmall(MappedFile.java:369)
> at
> net.openhft.chronicle.bytes.MappedFile.acquireByteStore(MappedFile.java:307)
> at
> net.openhft.chronicle.bytes.MappedFile.acquireByteStore(MappedFile.java:269)
> at
> net.openhft.chronicle.bytes.MappedBytes.acquireNextByteStore0(MappedBytes.java:434)
> at
> net.openhft.chronicle.bytes.MappedBytes.readVolatileInt(MappedBytes.java:792)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue$StoreSupplier.headerRecovery(SingleChronicleQueue.java:1027)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue$StoreSupplier.acquire(SingleChronicleQueue.java:981)
> at
> net.openhft.chronicle.queue.impl.WireStorePool.acquire(WireStorePool.java:53)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.cleanupStoreFilesWithNoData(SingleChronicleQueue.java:821)
> at
> net.openhft.chronicle.queue.impl.single.StoreAppender.(StoreAppender.java:75)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.newAppender(SingleChronicleQueue.java:422)
> at
> net.openhft.chronicle.core.threads.CleaningThreadLocal.initialValue(CleaningThreadLocal.java:54)
> at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:180)
> at java.lang.ThreadLocal.get(ThreadLocal.java:170)
> at
> net.openhft.chronicle.core.threads.CleaningThreadLocal.get(CleaningThreadLocal.java:59)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.acquireAppender(SingleChronicleQueue.java:441)
> at org.apache.cassandra.utils.binlog.BinLog.(BinLog.java:133)
> at org.apache.cassandra.utils.binlog.BinLog.(BinLog.java:65)
> at
> org.apache.cassandra.utils.binlog.BinLog$Builder.build(BinLog.java:453)
> at
>
[jira] [Updated] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17950: --- Fix Version/s: (was: 4.1-rc) > Enable dtest-offheap in CircleCI > > > Key: CASSANDRA-17950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17950 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Urgent > Fix For: 3.11.15, 4.0.8, 4.1-rc1, 4.1, 4.2 > > Time Spent: 3.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17995) CircleCI: generate.sh without options modifies config
[
https://issues.apache.org/jira/browse/CASSANDRA-17995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17995:
---
Fix Version/s: (was: 4.1-rc)
> CircleCI: generate.sh without options modifies config
> -
>
> Key: CASSANDRA-17995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17995
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1-rc1, 4.1, 4.2
>
>
> Calling {{.circleci/generate.sh}} without any options should print the help
> and exit without editing the {{config.yml}} file. However, after
> CASSANDRA-17939 it wrongly enters into the automatic detection of new or
> modified tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17939) CircleCI: Automatically detect and repeat new or modified JUnit tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17939:
---
Fix Version/s: (was: 4.1-rc)
> CircleCI: Automatically detect and repeat new or modified JUnit tests
> -
>
> Key: CASSANDRA-17939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17939
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.28, 3.11.14, 4.0.7, 4.1-rc1, 4.1, 4.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The purpose of this ticket is adding a new CircleCI job that automatically
> detects new or modified test classes and runs them repeatedly. That way we
> wouldn't need to manually specify those tests with {{.circleci/generate.sh}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17769) Fix org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
[ https://issues.apache.org/jira/browse/CASSANDRA-17769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17769: --- Fix Version/s: (was: 4.1-rc) > Fix > org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest > --- > > Key: CASSANDRA-17769 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17769 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.1-rc1, 4.1, 4.x > > Time Spent: 2h > Remaining Estimate: 0h > > Fix > org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest > failing on current trunk: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1795/workflows/bc8619bb-7301-4428-9662-bc24e5f38b87/jobs/13335/tests#failed-test-0 > and also in this run > https://app.circleci.com/pipelines/github/driftx/cassandra/551/workflows/ba8cadb9-025f-46f9-b663-69d9e956d30d/jobs/6596/tests -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17945) Fix StorageService.getNativeaddress handling of IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17945:
---
Fix Version/s: (was: 4.1-rc)
> Fix StorageService.getNativeaddress handling of IPv6 addresses
> --
>
> Key: CASSANDRA-17945
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17945
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc1, 4.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> While upgrading a cluster using IPv6 addresses from 3.0 to 4.0 I noticed the
> following in logs for upgraded nodes when processing down events for 3.0
> nodes that are going down as part of an upgrade:
>
> {noformat}
> 2022-09-28 20:18:48,244 ERROR [GossipStage:1]
> org.apache.cassandra.transport.Server - Problem retrieving RPC address for
> /[0:0:0:0:0:0:0:d9]:7000
> java.net.UnknownHostException: 0:0:0:0:0:0:0:d9:9042: invalid IPv6 address
> at java.net.InetAddress.getAllByName(InetAddress.java:1355) ~[?:?]
> at java.net.InetAddress.getAllByName(InetAddress.java:1306) ~[?:?]
> at java.net.InetAddress.getByName(InetAddress.java:1256) ~[?:?]
> at
> org.apache.cassandra.locator.InetAddressAndPort.getByNameOverrideDefaults(InetAddressAndPort.java:227)
>
> at
> org.apache.cassandra.locator.InetAddressAndPort.getByName(InetAddressAndPort.java:212)
>
> at
> org.apache.cassandra.transport.Server$EventNotifier.getNativeAddress(Server.java:377)
>
> at
> org.apache.cassandra.transport.Server$EventNotifier.onDown(Server.java:438)
> at
> org.apache.cassandra.service.StorageService.notifyDown(StorageService.java:2651)
>
> at
> org.apache.cassandra.service.StorageService.onDead(StorageService.java:3516)
> at org.apache.cassandra.gms.Gossiper.markDead(Gossiper.java:1347)
> at org.apache.cassandra.gms.Gossiper.markAsShutdown(Gossiper.java:590)
> at
> org.apache.cassandra.gms.GossipShutdownVerbHandler.doVerb(GossipShutdownVerbHandler.java:39)
>
> at org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
>
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
> at java.lang.Thread.run(Thread.java:829) [?:?]{noformat}
> It appears that StorageService.getNativeaddress does not account for the fact
> that an endpoint may be an IPv6 address, which required brackets when
> specified with a port:
>
> [https://github.com/apache/cassandra/blob/cassandra-4.0.6/src/java/org/apache/cassandra/service/StorageService.java#L1978-L1981]
>
>
> {code:java}
> /**
> * Return the native address associated with an endpoint as a string.
> * @param endpoint The endpoint to get rpc address for
> * @return the native address
> */
> public String getNativeaddress(InetAddressAndPort endpoint, boolean
> withPort)
> {
> if (endpoint.equals(FBUtilities.getBroadcastAddressAndPort()))
> return
> FBUtilities.getBroadcastNativeAddressAndPort().getHostAddress(withPort);
> else if
> (Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT)
> != null)
> {
> try
> {
> InetAddressAndPort address =
> InetAddressAndPort.getByName(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT).value);
> return address.getHostAddress(withPort);
> }
> catch (UnknownHostException e)
> {
> throw new RuntimeException(e);
> }
> }
> else if
> (Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS)
> == null)
> return endpoint.address.getHostAddress() + ":" +
> DatabaseDescriptor.getNativeTransportPort();
>
[jira] [Updated] (CASSANDRA-17596) Fix NPE in SimpleBuilders.ParititionUpdateBulder.RTBuilder.build
[ https://issues.apache.org/jira/browse/CASSANDRA-17596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17596: --- Fix Version/s: (was: 4.1-rc) > Fix NPE in SimpleBuilders.ParititionUpdateBulder.RTBuilder.build > > > Key: CASSANDRA-17596 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17596 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.5, 4.1-rc1, 4.1, 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > These two arrays are not initialised (1) which means that if I do not set > start nor end, when ClusteringBound.create is called, it will be null, but it > will fail here (2) as values will be null. > The fix consists of check if values are null and if they are, we build that > bound immediately. > (1) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SimpleBuilders.java#L257-L258 > (2) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ClusteringBound.java#L128 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17891) Fix hintedhandoff_test.py::TestHintedHandoff::test_hintedhandoff_window
[
https://issues.apache.org/jira/browse/CASSANDRA-17891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17891:
---
Fix Version/s: (was: 4.1-rc)
> Fix hintedhandoff_test.py::TestHintedHandoff::test_hintedhandoff_window
> ---
>
> Key: CASSANDRA-17891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17891
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1-rc1, 4.1, 4.2
>
>
> hintedhandoff_test.py::TestHintedHandoff::test_hintedhandoff_window is flaky
>
> {code:java}
> self =
> @since('4.1')
> def test_hintedhandoff_window(self):
> """
> Test that we only store at a maximum the hint window worth of
> hints.
> Prior to CASSANDRA-14309 we would store another window worth of
> hints
> if the down node was brought up and then taken back down
> immediately.
> We would also store another window of hints on a live node if the
> live
> node was restarted.
> @jira_ticket CASSANDRA-14309
> """
>
> # hint_window_persistent_enabled is set to true by default
> self.cluster.set_configuration_options({'max_hint_window_in_ms':
> 1,
> 'hinted_handoff_enabled':
> True,
> 'max_hints_delivery_threads':
> 1,
> 'hints_flush_period_in_ms':
> 100, })
> self.cluster.populate(2).start()
> node1, node2 = self.cluster.nodelist()
> session = self.patient_cql_connection(node1)
> create_ks(session, 'ks', 2)
> create_c1c2_table(self, session)
>
> # Stop handoff until very end and take node2 down for first round of
> hints
> node1.nodetool('pausehandoff')
>
> node2.nodetool('disablebinary')
> node2.watch_log_for(["Stop listening for CQL clients"], timeout=120)
>
> node2.nodetool('disablegossip')
> node2.watch_log_for(["Announcing shutdown", "state jump to
> shutdown"], timeout=120)
> node1.watch_log_for(["state jump to shutdown"], timeout=120)
>
> log_mark_node_1 = node1.mark_log()
> log_mark_node_2 = node2.mark_log()
>
> # First round of hints. We expect these to be replayed and the only
> # hints within the window
> insert_c1c2(session, n=(0, 100), consistency=ConsistencyLevel.ONE)
>
> # Let hint window pass
> time.sleep(15)
>
> # Re-enable and disable the node. Prior to CASSANDRA-14215 this
> should make the hint window on node1 reset.
> node2.nodetool('enablegossip')
> node2.watch_log_for(["state jump to NORMAL"], timeout=120,
> from_mark=log_mark_node_2)
> node1.watch_log_for(["state jump to NORMAL"], timeout=120,
> from_mark=log_mark_node_1)
>
> log_mark_node_1 = node1.mark_log()
> log_mark_node_2 = node2.mark_log()
>
> node2.nodetool('disablegossip')
>
> node2.watch_log_for(["Announcing shutdown", "state jump to
> shutdown"], timeout=120, from_mark=log_mark_node_2)
> node1.watch_log_for(["state jump to shutdown"], timeout=120,
> from_mark=log_mark_node_1)
>
> log_mark_node_1 = node1.mark_log()
> log_mark_node_2 = node2.mark_log()
>
> def endpoint_downtime(node_to_query, node):
> mbean = make_mbean('net', type='Gossiper')
> with JolokiaAgent(node_to_query) as jmx:
> return jmx.execute_method(mbean,
> 'getEndpointDowntime(java.lang.String)', [node])
>
> while endpoint_downtime(node1, "127.0.0.2") <= 5000:
> time.sleep(1)
>
> # Second round of inserts. We do not expect hints to be stored.
> insert_c1c2(session, n=(100, 200), consistency=ConsistencyLevel.ONE)
>
> # Restart node1. Prior to CASSANDRA-14215 this would reset node1's
> hint window.
> node1.stop()
> node1.start(wait_for_binary_proto=True, wait_other_notice=False)
> session = self.patient_exclusive_cql_connection(node1)
> session.execute('USE ks')
> # Third round of inserts. We do not expect hints to be stored.
> insert_c1c2(session, n=(200, 300), consistency=ConsistencyLevel.ONE)
>
> # Enable node2 and wait for hints to be replayed
> node2.nodetool('enablegossip')
> node2.watch_log_for(["state jump to NORMAL"], timeout=120,
> from_mark=log_mark_node_2)
>
> node2.nodetool('enablebinary')
>
[jira] [Updated] (CASSANDRA-17337) Fix flaky test - dtest.secondary_indexes_test.TestSecondaryIndexes.test_6924_dropping_ks
[
https://issues.apache.org/jira/browse/CASSANDRA-17337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17337:
---
Fix Version/s: (was: 4.1-rc)
> Fix flaky test -
> dtest.secondary_indexes_test.TestSecondaryIndexes.test_6924_dropping_ks
>
>
> Key: CASSANDRA-17337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17337
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1-rc1, 4.1, 4.1.x
>
> Attachments: test.cql
>
>
> Failed 1 times in the last 30 runs. Flakiness: 6%, Stability: 96%
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17639) WEBSITE - May 2022 blog "The Path to Green CI"
[ https://issues.apache.org/jira/browse/CASSANDRA-17639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17639: --- Fix Version/s: (was: 4.1-rc) > WEBSITE - May 2022 blog "The Path to Green CI" > -- > > Key: CASSANDRA-17639 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17639 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: 4.1-rc1, 4.1 > > Attachments: c17639-01-blog-index.png, c17639-02-blog-post.png, > c17639-03-blog-post-v2.png, c17639-04-blog-post-v2.png > > > This ticket is to capture the work associated with publishing the May 2022 > blog "The Path to Green CI" > If this blog cannot be published by the *May 19, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17928:
---
Fix Version/s: (was: 4.1-rc)
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.8, 4.1-rc1, 4.1, 4.2
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17337) Fix flaky test - dtest.secondary_indexes_test.TestSecondaryIndexes.test_6924_dropping_ks
[
https://issues.apache.org/jira/browse/CASSANDRA-17337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17337:
---
Fix Version/s: 4.1-rc1
> Fix flaky test -
> dtest.secondary_indexes_test.TestSecondaryIndexes.test_6924_dropping_ks
>
>
> Key: CASSANDRA-17337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17337
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1-rc1, 4.1-rc, 4.1, 4.1.x
>
> Attachments: test.cql
>
>
> Failed 1 times in the last 30 runs. Flakiness: 6%, Stability: 96%
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17950: --- Fix Version/s: 4.1-rc1 > Enable dtest-offheap in CircleCI > > > Key: CASSANDRA-17950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17950 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Urgent > Fix For: 3.11.15, 4.0.8, 4.1-rc1, 4.1-rc, 4.1, 4.2 > > Time Spent: 3.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17005:
---
Fix Version/s: 4.1-rc1
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.7, 4.1-rc1, 4.1-rc, 4.1, 4.2
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeout. For more information about
> server-side coordinator timeouts, see :class:`.policies.RetryPolicy`. Example
> usage:: >>> future = session.execute_async("SELECT * FROM mycf") >>> # do
> other stuff... >>> try: ... rows = future.result() ... for row in rows: ...
> ... # process results ... except
[jira] [Updated] (CASSANDRA-17955) Race condition on repair snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-17955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17955:
---
Fix Version/s: 4.1-rc1
> Race condition on repair snapshots
> --
>
> Key: CASSANDRA-17955
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17955
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Snapshots
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: 4.0
> Fix For: 4.0.8, 4.1-rc1, 4.1-rc, 4.1, 4.2
>
> Attachments: signature.asc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> If an endpoint is convicted and that endpoint is a coordinator then
> ActiveRepairService::removeParentRepairSession is called.
> The issue is that this occurs on clearSnapshotExecutor and can happen while
> RepairMessageVerbHandler is in process of taking a snapshot. So then you get
> a race condition and clearSnapshot will throw a
> java.nio.file.DirectoryNotEmptyException
>
> {code:java}
> public static void deleteRecursiveWithThrottle(File dir, RateLimiter
> rateLimiter)
> {
> if (dir.isDirectory())
> {
> String[] children = dir.list();
> for (String child : children)
> deleteRecursiveWithThrottle(new File(dir, child), rateLimiter);
> }
> // The directory is now empty so now it can be smoked
> deleteWithConfirmWithThrottle(dir, rateLimiter);
> } {code}
> Due to the directory not being empty when it goes to remove the directory at
> the end.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17769) Fix org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
[ https://issues.apache.org/jira/browse/CASSANDRA-17769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17769: --- Fix Version/s: 4.1-rc1 > Fix > org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest > --- > > Key: CASSANDRA-17769 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17769 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.1-rc1, 4.1-rc, 4.1, 4.x > > Time Spent: 2h > Remaining Estimate: 0h > > Fix > org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest > failing on current trunk: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1795/workflows/bc8619bb-7301-4428-9662-bc24e5f38b87/jobs/13335/tests#failed-test-0 > and also in this run > https://app.circleci.com/pipelines/github/driftx/cassandra/551/workflows/ba8cadb9-025f-46f9-b663-69d9e956d30d/jobs/6596/tests -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17596) Fix NPE in SimpleBuilders.ParititionUpdateBulder.RTBuilder.build
[ https://issues.apache.org/jira/browse/CASSANDRA-17596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17596: --- Fix Version/s: 4.1-rc1 > Fix NPE in SimpleBuilders.ParititionUpdateBulder.RTBuilder.build > > > Key: CASSANDRA-17596 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17596 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.5, 4.1-rc1, 4.1-rc, 4.1, 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > These two arrays are not initialised (1) which means that if I do not set > start nor end, when ClusteringBound.create is called, it will be null, but it > will fail here (2) as values will be null. > The fix consists of check if values are null and if they are, we build that > bound immediately. > (1) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SimpleBuilders.java#L257-L258 > (2) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ClusteringBound.java#L128 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17933) Zero length file in Audit log folder, prevents a node from starting
[
https://issues.apache.org/jira/browse/CASSANDRA-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17933:
---
Fix Version/s: 4.1-rc1
> Zero length file in Audit log folder, prevents a node from starting
> ---
>
> Key: CASSANDRA-17933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17933
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Andrew Hogg
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.7, 4.1-rc1, 4.1-rc, 4.1, 4.2
>
> Attachments: signature.asc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have encountered a 4.0.3 cluster where the audit log folder had a zero
> byte length file within it after the node had stopped. It is not clear how
> Cassandra got to the point of this file existing. On restarting the node, the
> node will not start and throws the following stack trace.
> {code:java}
> ERROR [main] 2022-09-26 14:01:27,892 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:468)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException: Unable to
> create instance of IAuditLogger.
> at
> org.apache.cassandra.utils.FBUtilities.newAuditLogger(FBUtilities.java:686)
> at
> org.apache.cassandra.audit.AuditLogManager.getAuditLogger(AuditLogManager.java:95)
> at
> org.apache.cassandra.audit.AuditLogManager.(AuditLogManager.java:74)
> at
> org.apache.cassandra.audit.AuditLogManager.(AuditLogManager.java:60)
> ... 3 common frames omitted
> Caused by: java.lang.reflect.InvocationTargetException: null
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.cassandra.utils.FBUtilities.newAuditLogger(FBUtilities.java:682)
> ... 6 common frames omitted
> Caused by: java.nio.channels.OverlappingFileLockException: null
> at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
> at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152)
> at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1068)
> at java.nio.channels.FileChannel.lock(FileChannel.java:1053)
> at
> net.openhft.chronicle.bytes.MappedFile.resizeRafIfTooSmall(MappedFile.java:369)
> at
> net.openhft.chronicle.bytes.MappedFile.acquireByteStore(MappedFile.java:307)
> at
> net.openhft.chronicle.bytes.MappedFile.acquireByteStore(MappedFile.java:269)
> at
> net.openhft.chronicle.bytes.MappedBytes.acquireNextByteStore0(MappedBytes.java:434)
> at
> net.openhft.chronicle.bytes.MappedBytes.readVolatileInt(MappedBytes.java:792)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue$StoreSupplier.headerRecovery(SingleChronicleQueue.java:1027)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue$StoreSupplier.acquire(SingleChronicleQueue.java:981)
> at
> net.openhft.chronicle.queue.impl.WireStorePool.acquire(WireStorePool.java:53)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.cleanupStoreFilesWithNoData(SingleChronicleQueue.java:821)
> at
> net.openhft.chronicle.queue.impl.single.StoreAppender.(StoreAppender.java:75)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.newAppender(SingleChronicleQueue.java:422)
> at
> net.openhft.chronicle.core.threads.CleaningThreadLocal.initialValue(CleaningThreadLocal.java:54)
> at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:180)
> at java.lang.ThreadLocal.get(ThreadLocal.java:170)
> at
> net.openhft.chronicle.core.threads.CleaningThreadLocal.get(CleaningThreadLocal.java:59)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.acquireAppender(SingleChronicleQueue.java:441)
> at org.apache.cassandra.utils.binlog.BinLog.(BinLog.java:133)
> at org.apache.cassandra.utils.binlog.BinLog.(BinLog.java:65)
> at
> org.apache.cassandra.utils.binlog.BinLog$Builder.build(BinLog.java:453)
> at
>
[jira] [Updated] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17928:
---
Fix Version/s: 4.1-rc1
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.8, 4.1-rc1, 4.1-rc, 4.1, 4.2
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17939) CircleCI: Automatically detect and repeat new or modified JUnit tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17939:
---
Fix Version/s: 4.1-rc1
> CircleCI: Automatically detect and repeat new or modified JUnit tests
> -
>
> Key: CASSANDRA-17939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17939
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.28, 3.11.14, 4.0.7, 4.1-rc1, 4.1-rc, 4.1, 4.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The purpose of this ticket is adding a new CircleCI job that automatically
> detects new or modified test classes and runs them repeatedly. That way we
> wouldn't need to manually specify those tests with {{.circleci/generate.sh}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17934) Add --resolve-ip option on 'nodetool gossipinfo'
[ https://issues.apache.org/jira/browse/CASSANDRA-17934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17934: --- Fix Version/s: 4.1-rc1 > Add --resolve-ip option on 'nodetool gossipinfo' > > > Key: CASSANDRA-17934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17934 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Paulo Motta >Assignee: Maxim Chanturiay >Priority: Normal > Labels: lhf > Fix For: 4.1-rc1, 4.1-rc, 4.1, 4.2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Give nodetool gossipinfo the option of either displaying IPs or hostnames for > the nodes in a ring. > Note: this option is already present for "nodetool status" and "nodetool ring" -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17639) WEBSITE - May 2022 blog "The Path to Green CI"
[ https://issues.apache.org/jira/browse/CASSANDRA-17639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17639: --- Fix Version/s: 4.1-rc1 > WEBSITE - May 2022 blog "The Path to Green CI" > -- > > Key: CASSANDRA-17639 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17639 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: 4.1-rc1, 4.1-rc, 4.1 > > Attachments: c17639-01-blog-index.png, c17639-02-blog-post.png, > c17639-03-blog-post-v2.png, c17639-04-blog-post-v2.png > > > This ticket is to capture the work associated with publishing the May 2022 > blog "The Path to Green CI" > If this blog cannot be published by the *May 19, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17617) CQLSH unicode control character list is too liberal
[ https://issues.apache.org/jira/browse/CASSANDRA-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17617: --- Fix Version/s: 4.1-rc1 > CQLSH unicode control character list is too liberal > --- > > Key: CASSANDRA-17617 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17617 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Tanuj Nayak >Assignee: Tanuj Nayak >Priority: Normal > Fix For: 3.11.14, 4.0.5, 4.1-rc1, 4.1-rc, 4.1, 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > It appears that the list of escaped unicode control characters > [here|https://github.com/apache/cassandra/blob/53a67ff2c36d90d337aba1409498de29931d4279/pylib/cqlshlib/formatting.py#L32] > is a bit too liberal. It seems to include characters such as '1' (0x31) and > '0' (0x30) which do not need to be escaped. It seems that the actual range > should be 0x00 - 0x1F and 0x7F+ as corroborated [by this > page|https://en.wikipedia.org/wiki/Unicode_control_characters]. > > This causes unnecessary escaping and regex substitutions on the CQLSH end > whenever common characters such as any punctuation or a 0 or a 1 appear in > the text column of a table. One might notice that a table with a text column > filled with 2's will take much less time to print than one with all 0's for > this reason. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17995) CircleCI: generate.sh without options modifies config
[
https://issues.apache.org/jira/browse/CASSANDRA-17995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17995:
---
Fix Version/s: 4.1-rc1
> CircleCI: generate.sh without options modifies config
> -
>
> Key: CASSANDRA-17995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17995
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1-rc1, 4.1-rc, 4.1, 4.2
>
>
> Calling {{.circleci/generate.sh}} without any options should print the help
> and exit without editing the {{config.yml}} file. However, after
> CASSANDRA-17939 it wrongly enters into the automatic detection of new or
> modified tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17945) Fix StorageService.getNativeaddress handling of IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17945:
---
Fix Version/s: 4.1-rc1
> Fix StorageService.getNativeaddress handling of IPv6 addresses
> --
>
> Key: CASSANDRA-17945
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17945
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc1, 4.1-rc, 4.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> While upgrading a cluster using IPv6 addresses from 3.0 to 4.0 I noticed the
> following in logs for upgraded nodes when processing down events for 3.0
> nodes that are going down as part of an upgrade:
>
> {noformat}
> 2022-09-28 20:18:48,244 ERROR [GossipStage:1]
> org.apache.cassandra.transport.Server - Problem retrieving RPC address for
> /[0:0:0:0:0:0:0:d9]:7000
> java.net.UnknownHostException: 0:0:0:0:0:0:0:d9:9042: invalid IPv6 address
> at java.net.InetAddress.getAllByName(InetAddress.java:1355) ~[?:?]
> at java.net.InetAddress.getAllByName(InetAddress.java:1306) ~[?:?]
> at java.net.InetAddress.getByName(InetAddress.java:1256) ~[?:?]
> at
> org.apache.cassandra.locator.InetAddressAndPort.getByNameOverrideDefaults(InetAddressAndPort.java:227)
>
> at
> org.apache.cassandra.locator.InetAddressAndPort.getByName(InetAddressAndPort.java:212)
>
> at
> org.apache.cassandra.transport.Server$EventNotifier.getNativeAddress(Server.java:377)
>
> at
> org.apache.cassandra.transport.Server$EventNotifier.onDown(Server.java:438)
> at
> org.apache.cassandra.service.StorageService.notifyDown(StorageService.java:2651)
>
> at
> org.apache.cassandra.service.StorageService.onDead(StorageService.java:3516)
> at org.apache.cassandra.gms.Gossiper.markDead(Gossiper.java:1347)
> at org.apache.cassandra.gms.Gossiper.markAsShutdown(Gossiper.java:590)
> at
> org.apache.cassandra.gms.GossipShutdownVerbHandler.doVerb(GossipShutdownVerbHandler.java:39)
>
> at org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
>
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
> at java.lang.Thread.run(Thread.java:829) [?:?]{noformat}
> It appears that StorageService.getNativeaddress does not account for the fact
> that an endpoint may be an IPv6 address, which required brackets when
> specified with a port:
>
> [https://github.com/apache/cassandra/blob/cassandra-4.0.6/src/java/org/apache/cassandra/service/StorageService.java#L1978-L1981]
>
>
> {code:java}
> /**
> * Return the native address associated with an endpoint as a string.
> * @param endpoint The endpoint to get rpc address for
> * @return the native address
> */
> public String getNativeaddress(InetAddressAndPort endpoint, boolean
> withPort)
> {
> if (endpoint.equals(FBUtilities.getBroadcastAddressAndPort()))
> return
> FBUtilities.getBroadcastNativeAddressAndPort().getHostAddress(withPort);
> else if
> (Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT)
> != null)
> {
> try
> {
> InetAddressAndPort address =
> InetAddressAndPort.getByName(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT).value);
> return address.getHostAddress(withPort);
> }
> catch (UnknownHostException e)
> {
> throw new RuntimeException(e);
> }
> }
> else if
> (Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS)
> == null)
> return endpoint.address.getHostAddress() + ":" +
> DatabaseDescriptor.getNativeTransportPort();
>
[jira] [Updated] (CASSANDRA-17891) Fix hintedhandoff_test.py::TestHintedHandoff::test_hintedhandoff_window
[
https://issues.apache.org/jira/browse/CASSANDRA-17891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17891:
---
Fix Version/s: 4.1-rc1
> Fix hintedhandoff_test.py::TestHintedHandoff::test_hintedhandoff_window
> ---
>
> Key: CASSANDRA-17891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17891
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1-rc1, 4.1-rc, 4.1, 4.2
>
>
> hintedhandoff_test.py::TestHintedHandoff::test_hintedhandoff_window is flaky
>
> {code:java}
> self =
> @since('4.1')
> def test_hintedhandoff_window(self):
> """
> Test that we only store at a maximum the hint window worth of
> hints.
> Prior to CASSANDRA-14309 we would store another window worth of
> hints
> if the down node was brought up and then taken back down
> immediately.
> We would also store another window of hints on a live node if the
> live
> node was restarted.
> @jira_ticket CASSANDRA-14309
> """
>
> # hint_window_persistent_enabled is set to true by default
> self.cluster.set_configuration_options({'max_hint_window_in_ms':
> 1,
> 'hinted_handoff_enabled':
> True,
> 'max_hints_delivery_threads':
> 1,
> 'hints_flush_period_in_ms':
> 100, })
> self.cluster.populate(2).start()
> node1, node2 = self.cluster.nodelist()
> session = self.patient_cql_connection(node1)
> create_ks(session, 'ks', 2)
> create_c1c2_table(self, session)
>
> # Stop handoff until very end and take node2 down for first round of
> hints
> node1.nodetool('pausehandoff')
>
> node2.nodetool('disablebinary')
> node2.watch_log_for(["Stop listening for CQL clients"], timeout=120)
>
> node2.nodetool('disablegossip')
> node2.watch_log_for(["Announcing shutdown", "state jump to
> shutdown"], timeout=120)
> node1.watch_log_for(["state jump to shutdown"], timeout=120)
>
> log_mark_node_1 = node1.mark_log()
> log_mark_node_2 = node2.mark_log()
>
> # First round of hints. We expect these to be replayed and the only
> # hints within the window
> insert_c1c2(session, n=(0, 100), consistency=ConsistencyLevel.ONE)
>
> # Let hint window pass
> time.sleep(15)
>
> # Re-enable and disable the node. Prior to CASSANDRA-14215 this
> should make the hint window on node1 reset.
> node2.nodetool('enablegossip')
> node2.watch_log_for(["state jump to NORMAL"], timeout=120,
> from_mark=log_mark_node_2)
> node1.watch_log_for(["state jump to NORMAL"], timeout=120,
> from_mark=log_mark_node_1)
>
> log_mark_node_1 = node1.mark_log()
> log_mark_node_2 = node2.mark_log()
>
> node2.nodetool('disablegossip')
>
> node2.watch_log_for(["Announcing shutdown", "state jump to
> shutdown"], timeout=120, from_mark=log_mark_node_2)
> node1.watch_log_for(["state jump to shutdown"], timeout=120,
> from_mark=log_mark_node_1)
>
> log_mark_node_1 = node1.mark_log()
> log_mark_node_2 = node2.mark_log()
>
> def endpoint_downtime(node_to_query, node):
> mbean = make_mbean('net', type='Gossiper')
> with JolokiaAgent(node_to_query) as jmx:
> return jmx.execute_method(mbean,
> 'getEndpointDowntime(java.lang.String)', [node])
>
> while endpoint_downtime(node1, "127.0.0.2") <= 5000:
> time.sleep(1)
>
> # Second round of inserts. We do not expect hints to be stored.
> insert_c1c2(session, n=(100, 200), consistency=ConsistencyLevel.ONE)
>
> # Restart node1. Prior to CASSANDRA-14215 this would reset node1's
> hint window.
> node1.stop()
> node1.start(wait_for_binary_proto=True, wait_other_notice=False)
> session = self.patient_exclusive_cql_connection(node1)
> session.execute('USE ks')
> # Third round of inserts. We do not expect hints to be stored.
> insert_c1c2(session, n=(200, 300), consistency=ConsistencyLevel.ONE)
>
> # Enable node2 and wait for hints to be replayed
> node2.nodetool('enablegossip')
> node2.watch_log_for(["state jump to NORMAL"], timeout=120,
> from_mark=log_mark_node_2)
>
> node2.nodetool('enablebinary')
>
svn commit: r58196 - in /dev/cassandra/4.1.0/redhat: ./ noboolean/ noboolean/repodata/ repodata/
Author: mck Date: Tue Nov 22 15:40:21 2022 New Revision: 58196 Log: staging cassandra rpm packages for 4.1.0 Added: dev/cassandra/4.1.0/redhat/ dev/cassandra/4.1.0/redhat/cassandra-4.1.0-1.noarch.rpm (with props) dev/cassandra/4.1.0/redhat/cassandra-4.1.0-1.src.rpm (with props) dev/cassandra/4.1.0/redhat/cassandra-tools-4.1.0-1.noarch.rpm (with props) dev/cassandra/4.1.0/redhat/noboolean/ dev/cassandra/4.1.0/redhat/noboolean/cassandra-4.1.0-1.noarch.rpm (with props) dev/cassandra/4.1.0/redhat/noboolean/cassandra-4.1.0-1.src.rpm (with props) dev/cassandra/4.1.0/redhat/noboolean/cassandra-tools-4.1.0-1.noarch.rpm (with props) dev/cassandra/4.1.0/redhat/noboolean/repodata/ dev/cassandra/4.1.0/redhat/noboolean/repodata/124b80b6ba81ccfcf18d65a1f1237bb3694a88b3c22165d905d9f39dec651d31-other.xml.gz (with props) dev/cassandra/4.1.0/redhat/noboolean/repodata/124b80b6ba81ccfcf18d65a1f1237bb3694a88b3c22165d905d9f39dec651d31-other.xml.gz.asc dev/cassandra/4.1.0/redhat/noboolean/repodata/3f05ba4a949f7bf8a674e84a105058a4f0735c982fb0833851fff920bfbb529b-filelists.xml.gz (with props) dev/cassandra/4.1.0/redhat/noboolean/repodata/3f05ba4a949f7bf8a674e84a105058a4f0735c982fb0833851fff920bfbb529b-filelists.xml.gz.asc dev/cassandra/4.1.0/redhat/noboolean/repodata/874e033f3738597a7d44e3472d28f219026c26d1b5d799056abba4aa437fd093-primary.xml.gz (with props) dev/cassandra/4.1.0/redhat/noboolean/repodata/874e033f3738597a7d44e3472d28f219026c26d1b5d799056abba4aa437fd093-primary.xml.gz.asc dev/cassandra/4.1.0/redhat/noboolean/repodata/87e36c636b4e87a478e6bb0f17f5f3c5e61f1e4fd3a5549f1f1080465316f71e-other.sqlite.bz2 (with props) dev/cassandra/4.1.0/redhat/noboolean/repodata/87e36c636b4e87a478e6bb0f17f5f3c5e61f1e4fd3a5549f1f1080465316f71e-other.sqlite.bz2.asc dev/cassandra/4.1.0/redhat/noboolean/repodata/966c0db07bf9e6d2ec2a4e8fb1ccfc49307069dbdd5e7b052d2e328732c39235-filelists.sqlite.bz2 (with props) dev/cassandra/4.1.0/redhat/noboolean/repodata/966c0db07bf9e6d2ec2a4e8fb1ccfc49307069dbdd5e7b052d2e328732c39235-filelists.sqlite.bz2.asc dev/cassandra/4.1.0/redhat/noboolean/repodata/b3caad47e3c75871957038c435fd56bb8748d38054d5110eb63bd753b7fa04f0-primary.sqlite.bz2 (with props) dev/cassandra/4.1.0/redhat/noboolean/repodata/b3caad47e3c75871957038c435fd56bb8748d38054d5110eb63bd753b7fa04f0-primary.sqlite.bz2.asc dev/cassandra/4.1.0/redhat/noboolean/repodata/repomd.xml dev/cassandra/4.1.0/redhat/noboolean/repodata/repomd.xml.asc dev/cassandra/4.1.0/redhat/repodata/ dev/cassandra/4.1.0/redhat/repodata/08137de433ca05db5004d945013be587ee0a0b6ecd9eec7843b35f79a39e94bc-primary.xml.gz (with props) dev/cassandra/4.1.0/redhat/repodata/08137de433ca05db5004d945013be587ee0a0b6ecd9eec7843b35f79a39e94bc-primary.xml.gz.asc dev/cassandra/4.1.0/redhat/repodata/23a8b915def136295eb4a90aa2741aa4eb80253f4a5f890d96403e93e18f3217-other.xml.gz (with props) dev/cassandra/4.1.0/redhat/repodata/23a8b915def136295eb4a90aa2741aa4eb80253f4a5f890d96403e93e18f3217-other.xml.gz.asc dev/cassandra/4.1.0/redhat/repodata/5bc85e5cfa4aa774410fd1933c9ab896851b25c19cddcd15669cf6420388a510-filelists.xml.gz (with props) dev/cassandra/4.1.0/redhat/repodata/5bc85e5cfa4aa774410fd1933c9ab896851b25c19cddcd15669cf6420388a510-filelists.xml.gz.asc dev/cassandra/4.1.0/redhat/repodata/827fe6685269bb2d449e259278a6debaf585c41574f495d00e1e96075e4f79c7-filelists.sqlite.bz2 (with props) dev/cassandra/4.1.0/redhat/repodata/827fe6685269bb2d449e259278a6debaf585c41574f495d00e1e96075e4f79c7-filelists.sqlite.bz2.asc dev/cassandra/4.1.0/redhat/repodata/90468a83867284fafc0442f162216cd8a74536d013f052a44450643c01be32f7-primary.sqlite.bz2 (with props) dev/cassandra/4.1.0/redhat/repodata/90468a83867284fafc0442f162216cd8a74536d013f052a44450643c01be32f7-primary.sqlite.bz2.asc dev/cassandra/4.1.0/redhat/repodata/e7b15dee7680915be57aa459e737535aed6996a3835e5a23c2bc4ae7a7c6db16-other.sqlite.bz2 (with props) dev/cassandra/4.1.0/redhat/repodata/e7b15dee7680915be57aa459e737535aed6996a3835e5a23c2bc4ae7a7c6db16-other.sqlite.bz2.asc dev/cassandra/4.1.0/redhat/repodata/repomd.xml dev/cassandra/4.1.0/redhat/repodata/repomd.xml.asc Added: dev/cassandra/4.1.0/redhat/cassandra-4.1.0-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.1.0/redhat/cassandra-4.1.0-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.1.0/redhat/cassandra-4.1.0-1.src.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.1.0/redhat/cassandra-4.1.0-1.src.rpm
[jira] [Comment Edited] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637326#comment-17637326
]
Benedict Elliott Smith edited comment on CASSANDRA-17530 at 11/22/22 3:37 PM:
--
I don't think the bug didn't make it into any release, so was there any change
to note?
was (Author: benedict):
The bug didn't make it into a release, so there was no public change to note?
> Paxos v2 Linearizability Violation
> --
>
> Key: CASSANDRA-17530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17530
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1-beta1, 4.1, 4.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The version of Paxos introduced recently had a subtle mistake that
> introduced a linearizability flaw that has been detected by the simulator,
> and also a flaw with the simulator has been found that may erroneously report
> a linearizability violation.
> The true linearizability fault is quite simple: fast read permissions were
> erroneously being escalated to promises when an incomplete proposal was
> discovered. This was likely due in part to the naming of the state
> {{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will
> be used to re-propose this proposal using the promises we have obtained. The
> fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.
> The false linearizability fault was triggered when two different competing
> incomplete proposals were reproposed multiple times, with the winning
> proposal being the one with the lower original ballot, and the proposal with
> the higher ballot having been successfully proposed to a majority of nodes
> but across multiple different ballots (so that no single ballot reached a
> majority), while the most recently successful ballot (at a minority) was the
> older original ballot. The range movement validation logic looked only at the
> original ballot, and since it saw the higher original ballot as having
> reached a majority perceived that it should have become persistent, when in
> fact the older ballot did so.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637326#comment-17637326
]
Benedict Elliott Smith commented on CASSANDRA-17530:
The bug didn't make it into a release, so there was no public change to note?
> Paxos v2 Linearizability Violation
> --
>
> Key: CASSANDRA-17530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17530
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1-beta1, 4.1, 4.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The version of Paxos introduced recently had a subtle mistake that
> introduced a linearizability flaw that has been detected by the simulator,
> and also a flaw with the simulator has been found that may erroneously report
> a linearizability violation.
> The true linearizability fault is quite simple: fast read permissions were
> erroneously being escalated to promises when an incomplete proposal was
> discovered. This was likely due in part to the naming of the state
> {{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will
> be used to re-propose this proposal using the promises we have obtained. The
> fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.
> The false linearizability fault was triggered when two different competing
> incomplete proposals were reproposed multiple times, with the winning
> proposal being the one with the lower original ballot, and the proposal with
> the higher ballot having been successfully proposed to a majority of nodes
> but across multiple different ballots (so that no single ballot reached a
> majority), while the most recently successful ballot (at a minority) was the
> older original ballot. The range movement validation logic looked only at the
> original ballot, and since it saw the higher original ballot as having
> reached a majority perceived that it should have become persistent, when in
> fact the older ballot did so.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r58195 - in /dev/cassandra/4.1.0/debian: ./ dists/ dists/41x/ dists/41x/main/ dists/41x/main/binary-amd64/ dists/41x/main/binary-arm64/ dists/41x/main/binary-i386/ dists/41x/main/source/ p
Author: mck Date: Tue Nov 22 15:21:47 2022 New Revision: 58195 Log: staging cassandra debian packages for 4.1.0 Added: dev/cassandra/4.1.0/debian/ dev/cassandra/4.1.0/debian/cassandra-tools_4.1.0_all.deb (with props) dev/cassandra/4.1.0/debian/cassandra_4.1.0.dsc dev/cassandra/4.1.0/debian/cassandra_4.1.0.tar.gz (with props) dev/cassandra/4.1.0/debian/cassandra_4.1.0_all.deb (with props) dev/cassandra/4.1.0/debian/cassandra_4.1.0_amd64.buildinfo dev/cassandra/4.1.0/debian/cassandra_4.1.0_amd64.changes dev/cassandra/4.1.0/debian/dists/ dev/cassandra/4.1.0/debian/dists/41x/ dev/cassandra/4.1.0/debian/dists/41x/InRelease dev/cassandra/4.1.0/debian/dists/41x/Release dev/cassandra/4.1.0/debian/dists/41x/Release.gpg dev/cassandra/4.1.0/debian/dists/41x/main/ dev/cassandra/4.1.0/debian/dists/41x/main/binary-amd64/ dev/cassandra/4.1.0/debian/dists/41x/main/binary-amd64/Packages dev/cassandra/4.1.0/debian/dists/41x/main/binary-amd64/Packages.gz (with props) dev/cassandra/4.1.0/debian/dists/41x/main/binary-amd64/Release dev/cassandra/4.1.0/debian/dists/41x/main/binary-arm64/ dev/cassandra/4.1.0/debian/dists/41x/main/binary-arm64/Packages dev/cassandra/4.1.0/debian/dists/41x/main/binary-arm64/Packages.gz (with props) dev/cassandra/4.1.0/debian/dists/41x/main/binary-arm64/Release dev/cassandra/4.1.0/debian/dists/41x/main/binary-i386/ dev/cassandra/4.1.0/debian/dists/41x/main/binary-i386/Packages dev/cassandra/4.1.0/debian/dists/41x/main/binary-i386/Packages.gz (with props) dev/cassandra/4.1.0/debian/dists/41x/main/binary-i386/Release dev/cassandra/4.1.0/debian/dists/41x/main/source/ dev/cassandra/4.1.0/debian/dists/41x/main/source/Release dev/cassandra/4.1.0/debian/dists/41x/main/source/Sources.gz (with props) dev/cassandra/4.1.0/debian/pool/ dev/cassandra/4.1.0/debian/pool/main/ dev/cassandra/4.1.0/debian/pool/main/c/ dev/cassandra/4.1.0/debian/pool/main/c/cassandra/ dev/cassandra/4.1.0/debian/pool/main/c/cassandra/cassandra-tools_4.1.0_all.deb (with props) dev/cassandra/4.1.0/debian/pool/main/c/cassandra/cassandra_4.1.0.dsc dev/cassandra/4.1.0/debian/pool/main/c/cassandra/cassandra_4.1.0.tar.gz (with props) dev/cassandra/4.1.0/debian/pool/main/c/cassandra/cassandra_4.1.0_all.deb (with props) Added: dev/cassandra/4.1.0/debian/cassandra-tools_4.1.0_all.deb == Binary file - no diff available. Propchange: dev/cassandra/4.1.0/debian/cassandra-tools_4.1.0_all.deb -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.1.0/debian/cassandra_4.1.0.dsc == --- dev/cassandra/4.1.0/debian/cassandra_4.1.0.dsc (added) +++ dev/cassandra/4.1.0/debian/cassandra_4.1.0.dsc Tue Nov 22 15:21:47 2022 @@ -0,0 +1,41 @@ +-BEGIN PGP SIGNED MESSAGE- +Hash: SHA512 + +Format: 1.0 +Source: cassandra +Binary: cassandra, cassandra-tools +Architecture: all +Version: 4.1.0 +Maintainer: Eric Evans +Uploaders: Sylvain Lebresne +Homepage: http://cassandra.apache.org +Standards-Version: 3.8.3 +Vcs-Browser: https://gitbox.apache.org/repos/asf?p=cassandra.git +Vcs-Git: https://gitbox.apache.org/repos/asf/cassandra.git +Build-Depends: debhelper (>= 11), openjdk-8-jdk | java8-jdk | openjdk-11-jdk | java11-jdk, ant (>= 1.9), ant-optional (>= 1.9), dh-python, python3-dev (>= 3.6), quilt, bash-completion +Package-List: + cassandra deb misc extra arch=all + cassandra-tools deb misc extra arch=all +Checksums-Sha1: + 7c8c2e116d5b59584e519bb1459e90bdebb9dc15 239606493 cassandra_4.1.0.tar.gz +Checksums-Sha256: + 3d3087a842618d7f73406957b4f9d2032044dd2d125ffad96ecf16fa12a1dcf7 239606493 cassandra_4.1.0.tar.gz +Files: + a5d03010d6db543f70243a716ee45262 239606493 cassandra_4.1.0.tar.gz + +-BEGIN PGP SIGNATURE- + +iQIzBAEBCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAmN86HQACgkQ6RM1134+ +h8tPPBAAgOclNe9F9Ks3bGezlol6VzPSnWR98VUVb1v1dP1xDGviigJkDVXDClvr +Q0EmxjNmFB5BG494P4bc9fqWLH4xaAlQk9nmjvaDF0mwN5vnFuYO4oJ83AD3zjbg +E2vNL/bughubp04YGngv0M7qnRxw2vBQaWtGP4lMOopW2d0u8rFxelQ+JlFh/I4F +Uy8yBIygo4+jbEb4UHnvGS6q/bwjdBRgG5nRx+pCGG0+DiOxIJFNajcbz499q48R +pytwpl7JRJ7IiXuZ3Yg29qG+inswcBybRhWUB36aBTyynKnuEzzvd3SDCevJGfrV +A+QUj78AvM/uPkVsfYGOMnFBqEc8iFF9f09imc6tAWq4Sx58X4C9Y3pJHBLfJsbr +TbEQ9Or8TAy4G6xY1UpU/Q68DZGOq39dGd04iz3u6dKvy14aJyZk7TzSqK4IDw6S +MBnaVkg1j0/iZ9pIzEcy5XqtsT5SEG1wLjldr9HIbOTVlW6x8wm0YW9i4mP2uJNq +ycga7r8foMpHxarsN8U4L3YEkKaixCvQLFFMX8d3ZVvyveXyuoRpxZvWxDDm5/Ip +XyYNG+9c6IoTZtiYLJ5cQF2Hv4GQd0vM2ru2HGarh0ojXBurMPtMPaIjBQEANCj4 +QbM2kwPL9A6JeGrDGI3h1tGlcsAXXsh4vP9x6HlujL80ACY8e0Y= +=K1QM +-END PGP SIGNATURE- Added: dev/cassandra/4.1.0/debian/cassandra_4.1.0.tar.gz
[jira] [Updated] (CASSANDRA-17769) Fix org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
[ https://issues.apache.org/jira/browse/CASSANDRA-17769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17769: --- Fix Version/s: 4.1 > Fix > org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest > --- > > Key: CASSANDRA-17769 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17769 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.1-rc, 4.1, 4.x > > Time Spent: 2h > Remaining Estimate: 0h > > Fix > org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest > failing on current trunk: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1795/workflows/bc8619bb-7301-4428-9662-bc24e5f38b87/jobs/13335/tests#failed-test-0 > and also in this run > https://app.circleci.com/pipelines/github/driftx/cassandra/551/workflows/ba8cadb9-025f-46f9-b663-69d9e956d30d/jobs/6596/tests -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17617) CQLSH unicode control character list is too liberal
[ https://issues.apache.org/jira/browse/CASSANDRA-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17617: --- Fix Version/s: 4.1 > CQLSH unicode control character list is too liberal > --- > > Key: CASSANDRA-17617 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17617 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Tanuj Nayak >Assignee: Tanuj Nayak >Priority: Normal > Fix For: 3.11.14, 4.0.5, 4.1-rc, 4.1, 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > It appears that the list of escaped unicode control characters > [here|https://github.com/apache/cassandra/blob/53a67ff2c36d90d337aba1409498de29931d4279/pylib/cqlshlib/formatting.py#L32] > is a bit too liberal. It seems to include characters such as '1' (0x31) and > '0' (0x30) which do not need to be escaped. It seems that the actual range > should be 0x00 - 0x1F and 0x7F+ as corroborated [by this > page|https://en.wikipedia.org/wiki/Unicode_control_characters]. > > This causes unnecessary escaping and regex substitutions on the CQLSH end > whenever common characters such as any punctuation or a 0 or a 1 appear in > the text column of a table. One might notice that a table with a text column > filled with 2's will take much less time to print than one with all 0's for > this reason. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17337) Fix flaky test - dtest.secondary_indexes_test.TestSecondaryIndexes.test_6924_dropping_ks
[
https://issues.apache.org/jira/browse/CASSANDRA-17337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17337:
---
Fix Version/s: 4.1
> Fix flaky test -
> dtest.secondary_indexes_test.TestSecondaryIndexes.test_6924_dropping_ks
>
>
> Key: CASSANDRA-17337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17337
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1-rc, 4.1, 4.1.x
>
> Attachments: test.cql
>
>
> Failed 1 times in the last 30 runs. Flakiness: 6%, Stability: 96%
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17928:
---
Fix Version/s: 4.1
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.8, 4.1-rc, 4.1, 4.2
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17005:
---
Fix Version/s: 4.1
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.7, 4.1-rc, 4.1, 4.2
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeout. For more information about
> server-side coordinator timeouts, see :class:`.policies.RetryPolicy`. Example
> usage:: >>> future = session.execute_async("SELECT * FROM mycf") >>> # do
> other stuff... >>> try: ... rows = future.result() ... for row in rows: ...
> ... # process results ... except Exception: ...
[jira] [Updated] (CASSANDRA-17891) Fix hintedhandoff_test.py::TestHintedHandoff::test_hintedhandoff_window
[
https://issues.apache.org/jira/browse/CASSANDRA-17891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17891:
---
Fix Version/s: 4.1
> Fix hintedhandoff_test.py::TestHintedHandoff::test_hintedhandoff_window
> ---
>
> Key: CASSANDRA-17891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17891
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1-rc, 4.1, 4.2
>
>
> hintedhandoff_test.py::TestHintedHandoff::test_hintedhandoff_window is flaky
>
> {code:java}
> self =
> @since('4.1')
> def test_hintedhandoff_window(self):
> """
> Test that we only store at a maximum the hint window worth of
> hints.
> Prior to CASSANDRA-14309 we would store another window worth of
> hints
> if the down node was brought up and then taken back down
> immediately.
> We would also store another window of hints on a live node if the
> live
> node was restarted.
> @jira_ticket CASSANDRA-14309
> """
>
> # hint_window_persistent_enabled is set to true by default
> self.cluster.set_configuration_options({'max_hint_window_in_ms':
> 1,
> 'hinted_handoff_enabled':
> True,
> 'max_hints_delivery_threads':
> 1,
> 'hints_flush_period_in_ms':
> 100, })
> self.cluster.populate(2).start()
> node1, node2 = self.cluster.nodelist()
> session = self.patient_cql_connection(node1)
> create_ks(session, 'ks', 2)
> create_c1c2_table(self, session)
>
> # Stop handoff until very end and take node2 down for first round of
> hints
> node1.nodetool('pausehandoff')
>
> node2.nodetool('disablebinary')
> node2.watch_log_for(["Stop listening for CQL clients"], timeout=120)
>
> node2.nodetool('disablegossip')
> node2.watch_log_for(["Announcing shutdown", "state jump to
> shutdown"], timeout=120)
> node1.watch_log_for(["state jump to shutdown"], timeout=120)
>
> log_mark_node_1 = node1.mark_log()
> log_mark_node_2 = node2.mark_log()
>
> # First round of hints. We expect these to be replayed and the only
> # hints within the window
> insert_c1c2(session, n=(0, 100), consistency=ConsistencyLevel.ONE)
>
> # Let hint window pass
> time.sleep(15)
>
> # Re-enable and disable the node. Prior to CASSANDRA-14215 this
> should make the hint window on node1 reset.
> node2.nodetool('enablegossip')
> node2.watch_log_for(["state jump to NORMAL"], timeout=120,
> from_mark=log_mark_node_2)
> node1.watch_log_for(["state jump to NORMAL"], timeout=120,
> from_mark=log_mark_node_1)
>
> log_mark_node_1 = node1.mark_log()
> log_mark_node_2 = node2.mark_log()
>
> node2.nodetool('disablegossip')
>
> node2.watch_log_for(["Announcing shutdown", "state jump to
> shutdown"], timeout=120, from_mark=log_mark_node_2)
> node1.watch_log_for(["state jump to shutdown"], timeout=120,
> from_mark=log_mark_node_1)
>
> log_mark_node_1 = node1.mark_log()
> log_mark_node_2 = node2.mark_log()
>
> def endpoint_downtime(node_to_query, node):
> mbean = make_mbean('net', type='Gossiper')
> with JolokiaAgent(node_to_query) as jmx:
> return jmx.execute_method(mbean,
> 'getEndpointDowntime(java.lang.String)', [node])
>
> while endpoint_downtime(node1, "127.0.0.2") <= 5000:
> time.sleep(1)
>
> # Second round of inserts. We do not expect hints to be stored.
> insert_c1c2(session, n=(100, 200), consistency=ConsistencyLevel.ONE)
>
> # Restart node1. Prior to CASSANDRA-14215 this would reset node1's
> hint window.
> node1.stop()
> node1.start(wait_for_binary_proto=True, wait_other_notice=False)
> session = self.patient_exclusive_cql_connection(node1)
> session.execute('USE ks')
> # Third round of inserts. We do not expect hints to be stored.
> insert_c1c2(session, n=(200, 300), consistency=ConsistencyLevel.ONE)
>
> # Enable node2 and wait for hints to be replayed
> node2.nodetool('enablegossip')
> node2.watch_log_for(["state jump to NORMAL"], timeout=120,
> from_mark=log_mark_node_2)
>
> node2.nodetool('enablebinary')
> node2.watch_log_for(["Starting
[jira] [Updated] (CASSANDRA-17933) Zero length file in Audit log folder, prevents a node from starting
[
https://issues.apache.org/jira/browse/CASSANDRA-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17933:
---
Fix Version/s: 4.1
> Zero length file in Audit log folder, prevents a node from starting
> ---
>
> Key: CASSANDRA-17933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17933
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Andrew Hogg
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.7, 4.1-rc, 4.1, 4.2
>
> Attachments: signature.asc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have encountered a 4.0.3 cluster where the audit log folder had a zero
> byte length file within it after the node had stopped. It is not clear how
> Cassandra got to the point of this file existing. On restarting the node, the
> node will not start and throws the following stack trace.
> {code:java}
> ERROR [main] 2022-09-26 14:01:27,892 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:468)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException: Unable to
> create instance of IAuditLogger.
> at
> org.apache.cassandra.utils.FBUtilities.newAuditLogger(FBUtilities.java:686)
> at
> org.apache.cassandra.audit.AuditLogManager.getAuditLogger(AuditLogManager.java:95)
> at
> org.apache.cassandra.audit.AuditLogManager.(AuditLogManager.java:74)
> at
> org.apache.cassandra.audit.AuditLogManager.(AuditLogManager.java:60)
> ... 3 common frames omitted
> Caused by: java.lang.reflect.InvocationTargetException: null
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.cassandra.utils.FBUtilities.newAuditLogger(FBUtilities.java:682)
> ... 6 common frames omitted
> Caused by: java.nio.channels.OverlappingFileLockException: null
> at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
> at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152)
> at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1068)
> at java.nio.channels.FileChannel.lock(FileChannel.java:1053)
> at
> net.openhft.chronicle.bytes.MappedFile.resizeRafIfTooSmall(MappedFile.java:369)
> at
> net.openhft.chronicle.bytes.MappedFile.acquireByteStore(MappedFile.java:307)
> at
> net.openhft.chronicle.bytes.MappedFile.acquireByteStore(MappedFile.java:269)
> at
> net.openhft.chronicle.bytes.MappedBytes.acquireNextByteStore0(MappedBytes.java:434)
> at
> net.openhft.chronicle.bytes.MappedBytes.readVolatileInt(MappedBytes.java:792)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue$StoreSupplier.headerRecovery(SingleChronicleQueue.java:1027)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue$StoreSupplier.acquire(SingleChronicleQueue.java:981)
> at
> net.openhft.chronicle.queue.impl.WireStorePool.acquire(WireStorePool.java:53)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.cleanupStoreFilesWithNoData(SingleChronicleQueue.java:821)
> at
> net.openhft.chronicle.queue.impl.single.StoreAppender.(StoreAppender.java:75)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.newAppender(SingleChronicleQueue.java:422)
> at
> net.openhft.chronicle.core.threads.CleaningThreadLocal.initialValue(CleaningThreadLocal.java:54)
> at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:180)
> at java.lang.ThreadLocal.get(ThreadLocal.java:170)
> at
> net.openhft.chronicle.core.threads.CleaningThreadLocal.get(CleaningThreadLocal.java:59)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.acquireAppender(SingleChronicleQueue.java:441)
> at org.apache.cassandra.utils.binlog.BinLog.(BinLog.java:133)
> at org.apache.cassandra.utils.binlog.BinLog.(BinLog.java:65)
> at
> org.apache.cassandra.utils.binlog.BinLog$Builder.build(BinLog.java:453)
> at
>
[jira] [Updated] (CASSANDRA-17945) Fix StorageService.getNativeaddress handling of IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17945:
---
Fix Version/s: 4.1
> Fix StorageService.getNativeaddress handling of IPv6 addresses
> --
>
> Key: CASSANDRA-17945
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17945
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc, 4.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> While upgrading a cluster using IPv6 addresses from 3.0 to 4.0 I noticed the
> following in logs for upgraded nodes when processing down events for 3.0
> nodes that are going down as part of an upgrade:
>
> {noformat}
> 2022-09-28 20:18:48,244 ERROR [GossipStage:1]
> org.apache.cassandra.transport.Server - Problem retrieving RPC address for
> /[0:0:0:0:0:0:0:d9]:7000
> java.net.UnknownHostException: 0:0:0:0:0:0:0:d9:9042: invalid IPv6 address
> at java.net.InetAddress.getAllByName(InetAddress.java:1355) ~[?:?]
> at java.net.InetAddress.getAllByName(InetAddress.java:1306) ~[?:?]
> at java.net.InetAddress.getByName(InetAddress.java:1256) ~[?:?]
> at
> org.apache.cassandra.locator.InetAddressAndPort.getByNameOverrideDefaults(InetAddressAndPort.java:227)
>
> at
> org.apache.cassandra.locator.InetAddressAndPort.getByName(InetAddressAndPort.java:212)
>
> at
> org.apache.cassandra.transport.Server$EventNotifier.getNativeAddress(Server.java:377)
>
> at
> org.apache.cassandra.transport.Server$EventNotifier.onDown(Server.java:438)
> at
> org.apache.cassandra.service.StorageService.notifyDown(StorageService.java:2651)
>
> at
> org.apache.cassandra.service.StorageService.onDead(StorageService.java:3516)
> at org.apache.cassandra.gms.Gossiper.markDead(Gossiper.java:1347)
> at org.apache.cassandra.gms.Gossiper.markAsShutdown(Gossiper.java:590)
> at
> org.apache.cassandra.gms.GossipShutdownVerbHandler.doVerb(GossipShutdownVerbHandler.java:39)
>
> at org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
>
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
> at java.lang.Thread.run(Thread.java:829) [?:?]{noformat}
> It appears that StorageService.getNativeaddress does not account for the fact
> that an endpoint may be an IPv6 address, which required brackets when
> specified with a port:
>
> [https://github.com/apache/cassandra/blob/cassandra-4.0.6/src/java/org/apache/cassandra/service/StorageService.java#L1978-L1981]
>
>
> {code:java}
> /**
> * Return the native address associated with an endpoint as a string.
> * @param endpoint The endpoint to get rpc address for
> * @return the native address
> */
> public String getNativeaddress(InetAddressAndPort endpoint, boolean
> withPort)
> {
> if (endpoint.equals(FBUtilities.getBroadcastAddressAndPort()))
> return
> FBUtilities.getBroadcastNativeAddressAndPort().getHostAddress(withPort);
> else if
> (Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT)
> != null)
> {
> try
> {
> InetAddressAndPort address =
> InetAddressAndPort.getByName(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT).value);
> return address.getHostAddress(withPort);
> }
> catch (UnknownHostException e)
> {
> throw new RuntimeException(e);
> }
> }
> else if
> (Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS)
> == null)
> return endpoint.address.getHostAddress() + ":" +
> DatabaseDescriptor.getNativeTransportPort();
> else
>
[jira] [Updated] (CASSANDRA-17939) CircleCI: Automatically detect and repeat new or modified JUnit tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17939:
---
Fix Version/s: 4.1
> CircleCI: Automatically detect and repeat new or modified JUnit tests
> -
>
> Key: CASSANDRA-17939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17939
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.28, 3.11.14, 4.0.7, 4.1-rc, 4.1, 4.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The purpose of this ticket is adding a new CircleCI job that automatically
> detects new or modified test classes and runs them repeatedly. That way we
> wouldn't need to manually specify those tests with {{.circleci/generate.sh}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17639) WEBSITE - May 2022 blog "The Path to Green CI"
[ https://issues.apache.org/jira/browse/CASSANDRA-17639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17639: --- Fix Version/s: 4.1 > WEBSITE - May 2022 blog "The Path to Green CI" > -- > > Key: CASSANDRA-17639 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17639 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: 4.1-rc, 4.1 > > Attachments: c17639-01-blog-index.png, c17639-02-blog-post.png, > c17639-03-blog-post-v2.png, c17639-04-blog-post-v2.png > > > This ticket is to capture the work associated with publishing the May 2022 > blog "The Path to Green CI" > If this blog cannot be published by the *May 19, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17955) Race condition on repair snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-17955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17955:
---
Fix Version/s: 4.1
> Race condition on repair snapshots
> --
>
> Key: CASSANDRA-17955
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17955
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Snapshots
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: 4.0
> Fix For: 4.0.8, 4.1-rc, 4.1, 4.2
>
> Attachments: signature.asc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> If an endpoint is convicted and that endpoint is a coordinator then
> ActiveRepairService::removeParentRepairSession is called.
> The issue is that this occurs on clearSnapshotExecutor and can happen while
> RepairMessageVerbHandler is in process of taking a snapshot. So then you get
> a race condition and clearSnapshot will throw a
> java.nio.file.DirectoryNotEmptyException
>
> {code:java}
> public static void deleteRecursiveWithThrottle(File dir, RateLimiter
> rateLimiter)
> {
> if (dir.isDirectory())
> {
> String[] children = dir.list();
> for (String child : children)
> deleteRecursiveWithThrottle(new File(dir, child), rateLimiter);
> }
> // The directory is now empty so now it can be smoked
> deleteWithConfirmWithThrottle(dir, rateLimiter);
> } {code}
> Due to the directory not being empty when it goes to remove the directory at
> the end.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17995) CircleCI: generate.sh without options modifies config
[
https://issues.apache.org/jira/browse/CASSANDRA-17995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17995:
---
Fix Version/s: 4.1
> CircleCI: generate.sh without options modifies config
> -
>
> Key: CASSANDRA-17995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17995
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1-rc, 4.1, 4.2
>
>
> Calling {{.circleci/generate.sh}} without any options should print the help
> and exit without editing the {{config.yml}} file. However, after
> CASSANDRA-17939 it wrongly enters into the automatic detection of new or
> modified tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17934) Add --resolve-ip option on 'nodetool gossipinfo'
[ https://issues.apache.org/jira/browse/CASSANDRA-17934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17934: --- Fix Version/s: 4.1 > Add --resolve-ip option on 'nodetool gossipinfo' > > > Key: CASSANDRA-17934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17934 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Paulo Motta >Assignee: Maxim Chanturiay >Priority: Normal > Labels: lhf > Fix For: 4.1-rc, 4.1, 4.2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Give nodetool gossipinfo the option of either displaying IPs or hostnames for > the nodes in a ring. > Note: this option is already present for "nodetool status" and "nodetool ring" -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17596) Fix NPE in SimpleBuilders.ParititionUpdateBulder.RTBuilder.build
[ https://issues.apache.org/jira/browse/CASSANDRA-17596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17596: --- Fix Version/s: 4.1 > Fix NPE in SimpleBuilders.ParititionUpdateBulder.RTBuilder.build > > > Key: CASSANDRA-17596 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17596 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.5, 4.1-rc, 4.1, 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > These two arrays are not initialised (1) which means that if I do not set > start nor end, when ClusteringBound.create is called, it will be null, but it > will fail here (2) as values will be null. > The fix consists of check if values are null and if they are, we build that > bound immediately. > (1) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SimpleBuilders.java#L257-L258 > (2) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ClusteringBound.java#L128 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17950: --- Fix Version/s: 4.1 > Enable dtest-offheap in CircleCI > > > Key: CASSANDRA-17950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17950 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Urgent > Fix For: 3.11.15, 4.0.8, 4.1-rc, 4.1, 4.2 > > Time Spent: 3.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14500) Debian package to include systemd file and conf
[ https://issues.apache.org/jira/browse/CASSANDRA-14500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned CASSANDRA-14500: - Assignee: (was: Stefan Miklosovic) > Debian package to include systemd file and conf > --- > > Key: CASSANDRA-14500 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14500 > Project: Cassandra > Issue Type: Improvement > Components: Packaging >Reporter: Lerh Chuan Low >Priority: Low > > I've been testing Cassandra on trunk on Debian stretch, and have been > creating my own systemd service files for Cassandra. My Cassandra clusters > would sometimes die due to too many open files. > As it turns out after some digging, this is because systemd ignores > */etc/security/limits.conf.* It relies on a configuration file in > .d/.conf. There's more information here: > [https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html]. > So, for example, for */etc/systemd/system/cassandra.service*, the ulimits are > read from */etc/systemd/system/cassandra.service.d/cassandra.conf*. > Crosschecking with the limits of my Cassandra process, it looks like the > */etc/security/limits.conf* really were not respected. If I make the change > above, then it works as expected. */etc/security/limits.conf* is shipped in > Cassandra's debian package. > Given that there are far more distributions using Systemd (Ubuntu is now as > well), I was wondering if it's worth the effort to change Cassandra's debian > packaging to use systemd (or at least, include systemd service). I'm not > totally familiar with whether it's common or normal to include a service file > in packaging so happy to be corrected/cancelled depending on what people > think. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17530:
---
Fix Version/s: 4.1
4.2
4.1-beta1
(was: 4.1-beta)
> Paxos v2 Linearizability Violation
> --
>
> Key: CASSANDRA-17530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17530
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1-beta1, 4.1, 4.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The version of Paxos introduced recently had a subtle mistake that
> introduced a linearizability flaw that has been detected by the simulator,
> and also a flaw with the simulator has been found that may erroneously report
> a linearizability violation.
> The true linearizability fault is quite simple: fast read permissions were
> erroneously being escalated to promises when an incomplete proposal was
> discovered. This was likely due in part to the naming of the state
> {{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will
> be used to re-propose this proposal using the promises we have obtained. The
> fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.
> The false linearizability fault was triggered when two different competing
> incomplete proposals were reproposed multiple times, with the winning
> proposal being the one with the lower original ballot, and the proposal with
> the higher ballot having been successfully proposed to a majority of nodes
> but across multiple different ballots (so that no single ballot reached a
> majority), while the most recently successful ballot (at a minority) was the
> older original ballot. The range movement validation logic looked only at the
> original ballot, and since it saw the higher original ballot as having
> reached a majority perceived that it should have become persistent, when in
> fact the older ballot did so.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637316#comment-17637316
]
Andres de la Peña commented on CASSANDRA-18042:
---
By the way, the name of the property is very long, what would you think about
{{zero_default_ttl_on_twcs_enabled}}? Too cryptic even with the nice comments
that we have around it?
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637314#comment-17637314
]
Michael Semb Wever commented on CASSANDRA-17530:
Was there a {{CHANGES.txt}} entry for this? (There are runtime classes touched
here…)
> Paxos v2 Linearizability Violation
> --
>
> Key: CASSANDRA-17530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17530
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The version of Paxos introduced recently had a subtle mistake that
> introduced a linearizability flaw that has been detected by the simulator,
> and also a flaw with the simulator has been found that may erroneously report
> a linearizability violation.
> The true linearizability fault is quite simple: fast read permissions were
> erroneously being escalated to promises when an incomplete proposal was
> discovered. This was likely due in part to the naming of the state
> {{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will
> be used to re-propose this proposal using the promises we have obtained. The
> fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.
> The false linearizability fault was triggered when two different competing
> incomplete proposals were reproposed multiple times, with the winning
> proposal being the one with the lower original ballot, and the proposal with
> the higher ballot having been successfully proposed to a majority of nodes
> but across multiple different ballots (so that no single ballot reached a
> majority), while the most recently successful ballot (at a minority) was the
> older original ballot. The range movement validation logic looked only at the
> original ballot, and since it saw the higher original ballot as having
> reached a majority perceived that it should have become persistent, when in
> fact the older ballot did so.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637312#comment-17637312
]
Andres de la Peña commented on CASSANDRA-18042:
---
The approach looks good to me. As previously discussed on Slack conversation, I
think it makes sense to have a soft limit on {{EnableFlag}} for this kind of
things, and it might come handy in the future for other stuff like
guardrail-based experimental flags.
As of whether we need to have a
{{zero_default_ttl_on_time_window_compaction_strategy_warned}} to configure the
warning, I guess that depends on whether the zero TTL is always risky or not.
If we think the warning might bother some users then we should have the
{{zero_default_ttl_on_time_window_compaction_strategy_warned}} property,
probably enabled by default.
I have left a bunch of comments on the PR, which overall is looking good. Most
are about nits and testing. The only slightly more serious thing is the
duplicated emission of warnings when {{ClientState}} is {{null}}. That happens
on background processes that are guarded but shouldn't be interrupted by
exceptions. We some of these for disk size, collection size, etc.
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637312#comment-17637312
]
Andres de la Peña edited comment on CASSANDRA-18042 at 11/22/22 3:13 PM:
-
The approach looks good to me. As previously discussed on Slack conversation, I
think it makes sense to have a soft limit on {{EnableFlag}} for this kind of
things, and it might come handy in the future for other stuff like
guardrail-based experimental flags.
As of whether we need to have a
{{zero_default_ttl_on_time_window_compaction_strategy_warned}} to configure the
warning, I guess that depends on whether the zero TTL is always risky or not.
If we think the warning might bother some users then we should have the
{{zero_default_ttl_on_time_window_compaction_strategy_warned}} property,
probably enabled by default.
I have left a bunch of comments on the PR, which overall is looking good. Most
are about nits and testing. The only slightly more serious thing is the
duplicated emission of warnings when {{ClientState}} is {{null}}. That happens
on background processes that are guarded but shouldn't be interrupted by
exceptions. We have some of these for disk size, collection size, etc.
was (Author: adelapena):
The approach looks good to me. As previously discussed on Slack conversation, I
think it makes sense to have a soft limit on {{EnableFlag}} for this kind of
things, and it might come handy in the future for other stuff like
guardrail-based experimental flags.
As of whether we need to have a
{{zero_default_ttl_on_time_window_compaction_strategy_warned}} to configure the
warning, I guess that depends on whether the zero TTL is always risky or not.
If we think the warning might bother some users then we should have the
{{zero_default_ttl_on_time_window_compaction_strategy_warned}} property,
probably enabled by default.
I have left a bunch of comments on the PR, which overall is looking good. Most
are about nits and testing. The only slightly more serious thing is the
duplicated emission of warnings when {{ClientState}} is {{null}}. That happens
on background processes that are guarded but shouldn't be interrupted by
exceptions. We some of these for disk size, collection size, etc.
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail:
svn commit: r58194 - /dev/cassandra/4.1.0/
Author: mck Date: Tue Nov 22 15:08:11 2022 New Revision: 58194 Log: staging cassandra 4.1.0 Added: dev/cassandra/4.1.0/ dev/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz (with props) dev/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz.asc dev/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz.sha256 dev/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz.sha512 dev/cassandra/4.1.0/apache-cassandra-4.1.0-src.tar.gz (with props) dev/cassandra/4.1.0/apache-cassandra-4.1.0-src.tar.gz.asc dev/cassandra/4.1.0/apache-cassandra-4.1.0-src.tar.gz.sha256 dev/cassandra/4.1.0/apache-cassandra-4.1.0-src.tar.gz.sha512 Added: dev/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz.asc == --- dev/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz.asc (added) +++ dev/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz.asc Tue Nov 22 15:08:11 2022 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAmN85TEACgkQ6RM1134+ +h8tF0w/8DA/H+HBqzVWq9A2E3aEdjXtciAXhPMiVOm1esbXABOe/4Ju1DKoEIuB6 +UpYqXUCtKLTq3b2Chjlan5h1uLSZp4YltGcQFp79UPtycY65DwRcdjV2mlh+X5Yq +Pk4wFmjeA3M4fNxAnYV62Uk9BG159QFZLMLxBJzWlCgz6Y7dL7JSAZ/HDNVp+7Ee +8kiEGi4PfFqDlu4TtvhHBu50QTD96R0J+xm57EIReIH38/Pn4RgIHddnSZIt1Zqp +oO2CB+NmLBehmpYod9JX9Km7R5svk5iUphdIO2lOIhINKeJbJ25ddvbrtceLEvyK +6+p/cNX6ADQG8rawlY83enVkvqznzi5kFUGARBo+Hf46jpHk94ktXsWqe5pcTjaY +Xe7PMwzwyTDF+sLcK/Qkyaf1mZ1HC78J8pPP2GwrIASO3llLMzWjuOW1scd4TdTC +YpUF1bDFYpoa2s7hcYcdSzWjrk6IZtiGBnveaGjz8Q8X8Jsr5LwnsIeZ9R9XjQl+ +jM1ugL/nCBOpOF03uHAu5tT04D5iU9Lpaj+HprrJQreWkCmohbJuoi/KF1qp+UD/ +JCrSDEkOxqXMcm90wmLDWblzTfm7mshOhDQonk1aT6jm2bxF7+dsljj0uE7y+GJl +3g6+jiu5OPeosyM54tZrOgMWyxs7Rz2ghT2RskzrYb2OrOCC+o0= +=KjPl +-END PGP SIGNATURE- Added: dev/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz.sha256 == --- dev/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz.sha256 (added) +++ dev/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz.sha256 Tue Nov 22 15:08:11 2022 @@ -0,0 +1 @@ +301927d88e91825ddf75876a3ccb8d198f68f02475f6ceea9e912e432d79d77a Added: dev/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz.sha512 == --- dev/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz.sha512 (added) +++ dev/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz.sha512 Tue Nov 22 15:08:11 2022 @@ -0,0 +1 @@ +1167f65e80f95b6d1fe46eae43d390128b5ebc1e1fbb364085f87a06e595cb6112ea79fdcb87eae834f587a01ca74a9595432bb3d8af77fd60c8ed6ace65b403 Added: dev/cassandra/4.1.0/apache-cassandra-4.1.0-src.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/4.1.0/apache-cassandra-4.1.0-src.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.1.0/apache-cassandra-4.1.0-src.tar.gz.asc == --- dev/cassandra/4.1.0/apache-cassandra-4.1.0-src.tar.gz.asc (added) +++ dev/cassandra/4.1.0/apache-cassandra-4.1.0-src.tar.gz.asc Tue Nov 22 15:08:11 2022 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAmN85TQACgkQ6RM1134+ +h8vZdg//QD4E5D6hSFACS0MjrIJjH3XyG0NEf7ijPsdB/AXBU8wPlEnE/B6tqwJW +L8kpVlHfeOIMV3K5CGEWGpKr7UOHGtBW8chrphivK9dE7TKfVMF6gRJbODlZXnLn +yO32sZ0zu2bc63YY/UB6HaP2Ck0oUqGSilbJvJWF9zcx9wx9hrWKCFIVWhDFJo2z +ZjTI//SHWtmKlhcgdBX4ME7Wf2dJRrYItEoZwYlrJLz9WLVSHv41zD8DPxdtvOn8 +zUJmFS+QC2WnLWv+VoUusTKYeBmeAWGHivFRQ09dnlOR1S61vXMqsU/IU0Ncew5k +z9aARS6acD+0Fl6bPAAdH81xdKY7fLiUSH08BObqF04W7CBa2wA5bp01FnZAh05j +JTzVahC8o+CcDvTZAe1dqdX3be/t5VFI/4z1aS7Yo7eOxVtMsoAP0wo2nevW4ztU +bbdYh6KR7K2Je01u6vnwYYTqjoqMseJGiIGnXUlzyB/z6Wrghr2yvOKZ6SixetlI +jp1U0sRi+SY8XxInXjDzgTvxRHAEWkTfobg/UrwAXWx9u4LiSPtuBmbcqcmAuZxa +9DRGuzmj+LPQCEYffA6rka3YxFHWDaUVse8CG4kwZAC4v5gV10yPpJ9dsMU/xBZU +dfndY0QtkO/ijTumXU6I86OSS/HRVoFEnUcqIbgRen8ADzTf1TI= +=7PUb +-END PGP SIGNATURE- Added: dev/cassandra/4.1.0/apache-cassandra-4.1.0-src.tar.gz.sha256 == --- dev/cassandra/4.1.0/apache-cassandra-4.1.0-src.tar.gz.sha256 (added) +++ dev/cassandra/4.1.0/apache-cassandra-4.1.0-src.tar.gz.sha256 Tue Nov 22 15:08:11 2022 @@ -0,0 +1 @@ +a68e7f07cf903c353bc5b936043d0b24cf8c8fa78710a28b2c09401b2065c600 Added:
[cassandra] tag 4.1.0-tentative created (now b807f97b37)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to tag 4.1.0-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git at b807f97b37 (commit) This tag includes the following new commits: new b807f97b37 Prepare debian changelog for 4.1.0 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. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Prepare debian changelog for 4.1.0
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to tag 4.1.0-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit b807f97b37933fac251020dbd949ee8ef245b158 Author: Mick Semb Wever AuthorDate: Tue Nov 22 15:58:24 2022 +0100 Prepare debian changelog for 4.1.0 --- debian/changelog | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/changelog b/debian/changelog index 52752dbb80..351ce25fb7 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,8 +1,8 @@ -cassandra (4.1.0) UNRELEASED; urgency=medium +cassandra (4.1.0) unstable; urgency=medium * New release - -- Mick Semb Wever Thu, 17 Nov 2022 11:33:25 +0100 + -- Mick Semb Wever Tue, 22 Nov 2022 15:57:55 +0100 cassandra (4.1~rc1) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated: Increment version to 4.1.0
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-4.1 by this push: new 676b3e4483 Increment version to 4.1.0 676b3e4483 is described below commit 676b3e448375b409a2721ff74f830c8db70410be Author: Mick Semb Wever AuthorDate: Tue Nov 22 15:41:18 2022 +0100 Increment version to 4.1.0 --- CHANGES.txt | 6 ++ build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/CHANGES.txt b/CHANGES.txt index 3a13c6b805..967cbc0f22 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,3 +1,9 @@ +4.1.0 +Merged from 4.0: +Merged from 3.11: +Merged from 3.0: + + 4.1-rc1 * Avoid schema mismatch problems on memtable API misconfiguration (CASSANDRA-18040) * Start Paxos auto repair in CassandraDaemon (CASSANDRA-18029) diff --git a/build.xml b/build.xml index 1de773550c..8c0e9804ae 100644 --- a/build.xml +++ b/build.xml @@ -33,7 +33,7 @@ - + https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=tree"/> diff --git a/debian/changelog b/debian/changelog index 94092646be..52752dbb80 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (4.1.0) UNRELEASED; urgency=medium + + * New release + + -- Mick Semb Wever Thu, 17 Nov 2022 11:33:25 +0100 + cassandra (4.1~rc1) unstable; urgency=medium * New release - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (ee8b66da8c -> 707d6bb527)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from ee8b66da8c Make incremental backup configurable per table new 676b3e4483 Increment version to 4.1.0 new 707d6bb527 Merge branch 'cassandra-4.1' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 707d6bb527c378fda9cc2a7b3c446593bdffdd19 Merge: ee8b66da8c 676b3e4483 Author: Mick Semb Wever AuthorDate: Tue Nov 22 15:43:03 2022 +0100 Merge branch 'cassandra-4.1' into trunk * cassandra-4.1: Increment version to 4.1.0 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18066) Server should be started in @Before rather than @BeforeClass in CQLTester
Jacek Lewandowski created CASSANDRA-18066:
-
Summary: Server should be started in @Before rather than
@BeforeClass in CQLTester
Key: CASSANDRA-18066
URL: https://issues.apache.org/jira/browse/CASSANDRA-18066
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Jacek Lewandowski
I can see that there is some misunderstanding in the project of
{{@BeforeClass}} annotated methods.
Given we have a static method {{@BeforeClass static void initA()}} in
{{CQLTester}} and {{@BeforeClass static void initB()}} in {{SomeTestClass
extends CQLTester}}, it will run like the following:
1. static initializer of {{CQLTester}}
2. {{initA()}}
3. static initializer of {{SomeTestClass}}
4. {{initB()}}
Since the server is started in (2), there is essentially no way to consistently
set startup properties or configuration of {{DatabaseDescriptor}} in
{{SomeTestClass}} so that the starting server can pick it consistently. That
is, if something works, it is just because some server class has not been used
yet, but this actually cannot be guaranteed.
When I look in the code, it seems like the understanding of JUnit was that if
{{initB()}} is defined, then {{initA()}} is not called, but this is not true.
Therefore, I propose to move the server initialization from {{initA()}} (call
to {{SchemaLoader.prepareServer()}} to a method annotated with {{@Before}} in
{{CQLTester}} so that the server is started with the first test case. Then, we
will be sure that call to {{initB()}} will happen before the server is
initialized and we will be able to set configuration consistently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-18042: -- Reviewers: Andres de la Peña > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r58193 - /release/cassandra/4.1-rc1/redhat/
Author: mck Date: Tue Nov 22 14:10:45 2022 New Revision: 58193 Log: Apache Cassandra 4.1-rc1 redhat artifacts Removed: release/cassandra/4.1-rc1/redhat/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r58192 - /release/cassandra/4.1-rc1/debian/
Author: mck Date: Tue Nov 22 14:08:06 2022 New Revision: 58192 Log: Apache Cassandra 4.1-rc1 debian artifacts Removed: release/cassandra/4.1-rc1/debian/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18060) Add aggregation scalar functions on collections
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637277#comment-17637277
]
Andres de la Peña commented on CASSANDRA-18060:
---
CI after rebase:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2024]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2512/workflows/3b076050-4dc5-49b6-afbc-059188b1a99a]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2512/workflows/cfa16b44-c54f-4497-a12d-b36eed71045f]|
> Add aggregation scalar functions on collections
> ---
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) | system.collection_max(l)
> --+--
> 1 |3
> > SELECT collection_sum(l), collection_avg(l) FROM t;
> system.collection_sum(l) | system.collection_avg(l)
> --+--
> 6 |2
> {code}
> Note that this type of aggregation is different from the kind of aggregation
> provided by {{min}}, {{max}}, {{sum}} and {{avg}}, which aggregate entire
> collections across rows. Here we only aggregate the items of a collection row
> per row.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18060) Add aggregation scalar functions on collections
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637276#comment-17637276
]
Berenguer Blasi commented on CASSANDRA-18060:
-
I saw the new opened ticket for the test failure great. I guess the 0/NaN
matter should go in the ML as it could be seen as a bug or may not :shrug: And
for the casting of collections I new ticket would be nice, maybe with a
different syntax, but that's food that new ticket.
Regarding this one so far and pending [~b.le...@gmail.com]'s comments +1 from
me.
> Add aggregation scalar functions on collections
> ---
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) | system.collection_max(l)
> --+--
> 1 |3
> > SELECT collection_sum(l), collection_avg(l) FROM t;
> system.collection_sum(l) | system.collection_avg(l)
> --+--
> 6 |2
> {code}
> Note that this type of aggregation is different from the kind of aggregation
> provided by {{min}}, {{max}}, {{sum}} and {{avg}}, which aggregate entire
> collections across rows. Here we only aggregate the items of a collection row
> per row.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r58190 - /dev/cassandra/4.1-rc1/ /release/cassandra/4.1-rc1/
Author: mck Date: Tue Nov 22 14:02:01 2022 New Revision: 58190 Log: Apache Cassandra 4.1-rc1 release Added: release/cassandra/4.1-rc1/ - copied from r58189, dev/cassandra/4.1-rc1/ Removed: dev/cassandra/4.1-rc1/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 4.1-rc1-tentative deleted (was d6822c45ae)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to tag 4.1-rc1-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git *** WARNING: tag 4.1-rc1-tentative was deleted! *** was d6822c45ae Prepare debian changelog for 4.1-rc1 The revisions that were on this tag are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] annotated tag cassandra-4.1-rc1 created (now c4dcf65786)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to annotated tag cassandra-4.1-rc1 in repository https://gitbox.apache.org/repos/asf/cassandra.git at c4dcf65786 (tag) tagging d6822c45ae3d476bc2ff674cedf7d4107b8ca2d0 (commit) replaces cassandra-4.1-beta1 by Mick Semb Wever on Tue Nov 22 14:59:13 2022 +0100 - Log - Apache Cassandra 4.1-rc1 release --- No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18044) Make CommitLogReplayer replay all tables in a keyspace when only keyspace is specified in cassandra.replayList property
[ https://issues.apache.org/jira/browse/CASSANDRA-18044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637268#comment-17637268 ] Branimir Lambov commented on CASSANDRA-18044: - +1, the code looks good to me. > Make CommitLogReplayer replay all tables in a keyspace when only keyspace is > specified in cassandra.replayList property > --- > > Key: CASSANDRA-18044 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18044 > Project: Cassandra > Issue Type: Improvement > Components: Local/Commit Log >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > CommitLogReplayer reacts on a property "cassandra.replayList" (1) which > replays only some tables if needed upon commit log replay. > However, imagine you have a keyspace of 50 tables and other keyspace of 20 > tables and you want to replay only all tables of the first keyspace. > Currently, an operator has to enumerate all 50 tables which is not desirable > and it is error prone. > I suggest to change the logic in such a way that if there is only keyspace > listed, we would retrieve all its tables dynamically in runtime and replayed > only these. > The solution would be receptive to both keyspace.table as well as only > "keyspace" format. > Valid examples of such property: > ks1,ks2,ks3.tb1 // it will retrieve all tables of ks1 and ks2 and appends > ks3.tb1 > ks1.tb1,ks2.tb2 > ks1,ks2,ks3 // it will retrieve tables of all these keyspaces > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L379-L387] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18060) Add aggregation scalar functions on collections
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637255#comment-17637255
]
Andres de la Peña commented on CASSANDRA-18060:
---
Thanks for the review.
The test failure [can be reproduced on
trunk|https://app.circleci.com/pipelines/github/adelapena/cassandra/2511/workflows/7aba8baa-0a6d-404a-b08b-c6a8078caca3/jobs/24706/tests]
with the multiplexer. Just opened CASSANDRA-18065 for it.
I' have added the suggested JavaDoc and documentation for the already existing
{{sum}} and {{avg}} functions, and for the new {{collection_sum}} and
{{{}collection_avg{}}}.
Regarding followup tickets, I can add one for {{avg}} returning {{NaN}} instead
of zero, but I don't know if it's too late for that since the current behaviour
has been around for ages.
As for overflows and truncated decimals, we'll definitively need a followup
ticket. The {{sum}} and {{avg}} functions can walk around this by using type
casting, for example:
{code:java}
CREATE TABLE t (k int PRIMARY KEY, v int);
SELECT sum(cast(v AS varint)) FROM t;
SELECT avg(cast(v AS float)) FROM t;
{code}
However, we don't have such type of casting for collections, so we could have a
followup ticket for adding that feature, so we can do something like:
{code:java}
CREATE TABLE t (k int PRIMARY KEY, v list);
SELECT collection_sum(cast(v AS list)) FROM t;
SELECT collection_avg(cast(v AS lsit)) FROM t;
{code}
CC [~blerer]
> Add aggregation scalar functions on collections
> ---
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) | system.collection_max(l)
> --+--
> 1 |3
> > SELECT collection_sum(l), collection_avg(l) FROM t;
> system.collection_sum(l) | system.collection_avg(l)
> --+--
> 6 |2
> {code}
> Note that this type of aggregation is different from the kind of aggregation
> provided by {{min}}, {{max}}, {{sum}} and {{avg}}, which aggregate entire
> collections across rows. Here we only aggregate the items of a collection row
> per row.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18060) Add aggregation scalar functions on collections
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637255#comment-17637255
]
Andres de la Peña edited comment on CASSANDRA-18060 at 11/22/22 1:22 PM:
-
Thanks for the review.
The test failure [can be reproduced on
trunk|https://app.circleci.com/pipelines/github/adelapena/cassandra/2511/workflows/7aba8baa-0a6d-404a-b08b-c6a8078caca3/jobs/24706/tests]
with the multiplexer. Just opened CASSANDRA-18065 for it.
I have added the suggested JavaDoc and documentation for the already existing
{{sum}} and {{avg}} functions, and for the new {{collection_sum}} and
{{{}collection_avg{}}}.
Regarding followup tickets, I can add one for {{avg}} returning {{NaN}} instead
of zero, but I don't know if it's too late for that since the current behaviour
has been around for ages.
As for overflows and truncated decimals, we'll definitively need a followup
ticket. The {{sum}} and {{avg}} functions can walk around this by using type
casting, for example:
{code:java}
CREATE TABLE t (k int PRIMARY KEY, v int);
SELECT sum(cast(v AS varint)) FROM t;
SELECT avg(cast(v AS float)) FROM t;
{code}
However, we don't have such type of casting for collections, so we could have a
followup ticket for adding that feature, so we can do something like:
{code:java}
CREATE TABLE t (k int PRIMARY KEY, v list);
SELECT collection_sum(cast(v AS list)) FROM t;
SELECT collection_avg(cast(v AS lsit)) FROM t;
{code}
CC [~blerer]
was (Author: adelapena):
Thanks for the review.
The test failure [can be reproduced on
trunk|https://app.circleci.com/pipelines/github/adelapena/cassandra/2511/workflows/7aba8baa-0a6d-404a-b08b-c6a8078caca3/jobs/24706/tests]
with the multiplexer. Just opened CASSANDRA-18065 for it.
I' have added the suggested JavaDoc and documentation for the already existing
{{sum}} and {{avg}} functions, and for the new {{collection_sum}} and
{{{}collection_avg{}}}.
Regarding followup tickets, I can add one for {{avg}} returning {{NaN}} instead
of zero, but I don't know if it's too late for that since the current behaviour
has been around for ages.
As for overflows and truncated decimals, we'll definitively need a followup
ticket. The {{sum}} and {{avg}} functions can walk around this by using type
casting, for example:
{code:java}
CREATE TABLE t (k int PRIMARY KEY, v int);
SELECT sum(cast(v AS varint)) FROM t;
SELECT avg(cast(v AS float)) FROM t;
{code}
However, we don't have such type of casting for collections, so we could have a
followup ticket for adding that feature, so we can do something like:
{code:java}
CREATE TABLE t (k int PRIMARY KEY, v list);
SELECT collection_sum(cast(v AS list)) FROM t;
SELECT collection_avg(cast(v AS lsit)) FROM t;
{code}
CC [~blerer]
> Add aggregation scalar functions on collections
> ---
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) | system.collection_max(l)
> --+--
> 1 |3
> > SELECT collection_sum(l), collection_avg(l) FROM t;
> system.collection_sum(l) | system.collection_avg(l)
> --+--
> 6 |2
> {code}
> Note that this type of aggregation is different from the kind of aggregation
> provided by {{min}}, {{max}}, {{sum}} and {{avg}}, which aggregate entire
> collections across rows. Here we only aggregate the items of a
[jira] [Updated] (CASSANDRA-18065) Flaky test org.apache.cassandra.tools.TopPartitionsTest#testStartAndStopScheduledSampling
[
https://issues.apache.org/jira/browse/CASSANDRA-18065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18065:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
> Flaky test
> org.apache.cassandra.tools.TopPartitionsTest#testStartAndStopScheduledSampling
> -
>
> Key: CASSANDRA-18065
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18065
> Project: Cassandra
> Issue Type: Bug
>Reporter: Andres de la Peña
>Priority: Normal
>
> The test
> {{org.apache.cassandra.tools.TopPartitionsTest#testStartAndStopScheduledSampling}}
> is fails intermittently on trunk with CircleCI:
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/92f054d7-9386-498f-9ba4-330181cd4782/jobs/24692
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/2511/workflows/7aba8baa-0a6d-404a-b08b-c6a8078caca3/jobs/24706/tests
> The failure looks like:
> {code}
> junit.framework.AssertionFailedError: Scheduled sampled tasks should be
> removed expected:<[]> but was:<[*.*]>
> at
> org.apache.cassandra.tools.TopPartitionsTest.testStartAndStopScheduledSampling(TopPartitionsTest.java:116)
> {code}
> I haven't seen this failure on Butler/Jenkins yet, but it can be reproduced
> with the CircleCI multiplexer:
> {code}
> .circleci/generate.sh -m \
> -e REPEATED_UTESTS_COUNT=2000 \
> -e REPEATED_UTESTS=org.apache.cassandra.tools.TopPartitionsTest
> {code}
> It seems to fail 11 times on 2000 runs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18065) Flaky test org.apache.cassandra.tools.TopPartitionsTest#testStartAndStopScheduledSampling
Andres de la Peña created CASSANDRA-18065:
-
Summary: Flaky test
org.apache.cassandra.tools.TopPartitionsTest#testStartAndStopScheduledSampling
Key: CASSANDRA-18065
URL: https://issues.apache.org/jira/browse/CASSANDRA-18065
Project: Cassandra
Issue Type: Bug
Reporter: Andres de la Peña
The test
{{org.apache.cassandra.tools.TopPartitionsTest#testStartAndStopScheduledSampling}}
is fails intermittently on trunk with CircleCI:
*
https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/92f054d7-9386-498f-9ba4-330181cd4782/jobs/24692
*
https://app.circleci.com/pipelines/github/adelapena/cassandra/2511/workflows/7aba8baa-0a6d-404a-b08b-c6a8078caca3/jobs/24706/tests
The failure looks like:
{code}
junit.framework.AssertionFailedError: Scheduled sampled tasks should be removed
expected:<[]> but was:<[*.*]>
at
org.apache.cassandra.tools.TopPartitionsTest.testStartAndStopScheduledSampling(TopPartitionsTest.java:116)
{code}
I haven't seen this failure on Butler/Jenkins yet, but it can be reproduced
with the CircleCI multiplexer:
{code}
.circleci/generate.sh -m \
-e REPEATED_UTESTS_COUNT=2000 \
-e REPEATED_UTESTS=org.apache.cassandra.tools.TopPartitionsTest
{code}
It seems to fail 11 times on 2000 runs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18044) Make CommitLogReplayer replay all tables in a keyspace when only keyspace is specified in cassandra.replayList property
[ https://issues.apache.org/jira/browse/CASSANDRA-18044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637230#comment-17637230 ] Stefan Miklosovic commented on CASSANDRA-18044: --- Thanks [~blambov] for the review. I have changed the logging a little bit and I added one more combination of these properties for tests pr: https://github.com/apache/cassandra/pull/2020/files j11 pre-commit https://app.circleci.com/pipelines/github/instaclustr/cassandra/1599/workflows/fdca736a-2327-4f73-b1b5-99bd5398ca06 j8 pre-commit https://app.circleci.com/pipelines/github/instaclustr/cassandra/1599/workflows/d8f218bf-0b3b-4fdb-8f7c-4133804d0bec > Make CommitLogReplayer replay all tables in a keyspace when only keyspace is > specified in cassandra.replayList property > --- > > Key: CASSANDRA-18044 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18044 > Project: Cassandra > Issue Type: Improvement > Components: Local/Commit Log >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > CommitLogReplayer reacts on a property "cassandra.replayList" (1) which > replays only some tables if needed upon commit log replay. > However, imagine you have a keyspace of 50 tables and other keyspace of 20 > tables and you want to replay only all tables of the first keyspace. > Currently, an operator has to enumerate all 50 tables which is not desirable > and it is error prone. > I suggest to change the logic in such a way that if there is only keyspace > listed, we would retrieve all its tables dynamically in runtime and replayed > only these. > The solution would be receptive to both keyspace.table as well as only > "keyspace" format. > Valid examples of such property: > ks1,ks2,ks3.tb1 // it will retrieve all tables of ks1 and ks2 and appends > ks3.tb1 > ks1.tb1,ks2.tb2 > ks1,ks2,ks3 // it will retrieve tables of all these keyspaces > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L379-L387] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637154#comment-17637154 ] Stefan Miklosovic commented on CASSANDRA-18042: --- Thanks [~bschoeni] _It is not recommended to disable ..._ I do not think this is the right way to put it. It is strategy as any other. It just has some consequences to keep in mind. It is as if we do not want people to use TWCS with ttl = 0. That is not completely true, they can definitely use such configuration combination. There is just some not-so-obvious caveat attached we try to point out here. > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18064:
--
Change Category: Semantic
Complexity: Normal
Component/s: Documentation/Website
Fix Version/s: NA
Reviewers: Michael Semb Wever
Status: Open (was: Triage Needed)
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...{quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
