[jira] [Commented] (CASSANDRA-18102) Add a virtual table to list snapshots

[maxwellguo (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697764#comment-17697764
 ] 

maxwellguo commented on CASSANDRA-18102:


java8 and java11 precommit are all green 
||Heading 1||Heading 2||
|pr for trunk|[trunk|https://github.com/apache/cassandra/pull/2117]|
|java8|[java8|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/415/workflows/e86c7bec-5c94-4ea8-91e9-1b2f00e04e49]|
|java11|[java11|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/415/workflows/3a2906c5-d2d0-4a77-8c02-324b04fee26b]|


> Add a virtual table to list snapshots
> -
>
> Key: CASSANDRA-18102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18102
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Virtual Tables, Local/Snapshots
>Reporter: Paulo Motta
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 5.0
>
>  Time Spent: 7h 50m
>  Remaining Estimate: 0h
>
> It should be possible to query a node's snapshots via virtual tables.
> The table should expose the same fields/columns as the 
> [TableSnapshot|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/snapshot/TableSnapshot.java]
>  class.
> Something along these lines:
> {noformat}
> cqlsh> SELECT * FROM system_views.snapshots;
>  
> tag | keyspace_name | table_name |  table_id | is_ephemeral | created_at | 
> expires_at | directories
> +---++---+--+---++
> 1670460346841 | system | compaction_info | 
> 123e4567-e89b-12d3-a456-426614174000 | false | 2022-12-08T00:45:47.108Z | 
> null | 
> {'/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/snapshots/1670460346841'}
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-18294) die disk failure policy will not kill jvm as documented

[Stefan Miklosovic (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697744#comment-17697744
 ] 

Stefan Miklosovic commented on CASSANDRA-18294:
---

I believe that can be addressed upon merge.

> die disk failure policy will not kill jvm as documented
> ---
>
> Key: CASSANDRA-18294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18294
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x, 4.0.x, 4.1.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After Cassandra has successfully starts up with disk_failure_policy die, when 
> encounter a file system error, Cassandra server will only throw exception 
> instead of shut down gossip and client transport and kill JVM. Document: 
> [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#disk_failure_policy]
>  
> The reason for this is the default FS error handler is not handing policy die 
> correctly. Instead of shutting down gossip and native transport, it throws an 
> error.
>  
> The JVMStabilityInspectorTest is passing because the error handler is not set 
> so no exception is thrown.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra-website] branch asf-staging updated (2495ba422 -> 571cd5ec3)

[git-site-role]

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 2495ba422 generate docs for c4206294
 new 571cd5ec3 generate docs for c4206294

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   (2495ba422)
\
 N -- N -- N   refs/heads/asf-staging (571cd5ec3)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 content/search-index.js |   2 +-
 site-ui/build/ui-bundle.zip | Bin 4796442 -> 4796442 bytes
 2 files changed, 1 insertion(+), 1 deletion(-)


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics

[Brad Schoening (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brad Schoening updated CASSANDRA-18305:
---
Description: 
Nodetool compactionstats reports only on active compactions, if nothing is 
active, you see only:
{quote}$nodetool compactionstats

pending tasks: 0
{quote}
but in the MBean Compaction/TotalCompactionsCompleted there are recent 
statistic in events/second for:
 * Count
 * FifteenMinueRate
 * FiveMinueRate
 * MeanRate
 * OneMinuteRate

1) It would be useful to see in addition:
{quote}pending tasks: 0

compactions completed: 20

    1 minute rate:    0/second

   5 minute rate:    2.3/second

  15 minute rate:   4.6/second
{quote}
2) Since compaction_throughput_mb_per_sec is a throttling parameter in 
cassandra.yaml (default 64 MBps), it would be nice to show the actual 
compaction throughput and be able to observe if you're close to the limit.  
I.e., 
{quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
{quote}
3) for completness, compactionstats should list the number of concurrent 
compactors configured
{quote}concurrent compactions permitted: 2
{quote}

  was:
Nodetool compactionstats reports only on active compactions, if nothing is 
active, you see only:
{quote}$nodetool compactionstats

pending tasks: 0
{quote}
but in the MBean Compaction/TotalCompactionsCompleted there are recent 
statistic in events/second for:
 * Count
 * FifteenMinueRate
 * FiveMinueRate
 * MeanRate
 * OneMinuteRate

1) It would be useful to see in addition:
{quote}pending tasks: 0

compactions completed: 20

    1 minute rate:    0/second

   5 minute rate:    2.3/second

  15 minute rate:   4.6/second
{quote}
2) Since compaction_throughput_mb_per_sec is a throttling parameter in 
cassandra.yaml (default 64 MBps), it would be nice to show the actual 
compaction throughput and be able to observe if you're close to the limit.  
I.e., 
{quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
{quote}
3) for completness, compactionstats should list the number of concurrent 
compactors configured

compaction throughput 13.2 MBps / 16 MBps (82.5%)


> Enhance nodetool compactionstats with existing MBean metrics
> 
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Nodetool compactionstats reports only on active compactions, if nothing is 
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent 
> statistic in events/second for:
>  * Count
>  * FifteenMinueRate
>  * FiveMinueRate
>  * MeanRate
>  * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
>     1 minute rate:    0/second
>    5 minute rate:    2.3/second
>   15 minute rate:   4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in 
> cassandra.yaml (default 64 MBps), it would be nice to show the actual 
> compaction throughput and be able to observe if you're close to the limit.  
> I.e., 
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent 
> compactors configured
> {quote}concurrent compactions permitted: 2
> {quote}



--
This message was sent by Atlassian Jira
(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-18305) Enhance nodetool compactionstats with existing MBean metrics

[Brad Schoening (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brad Schoening updated CASSANDRA-18305:
---
Description: 
Nodetool compactionstats reports only on active compactions, if nothing is 
active, you see only:
{quote}$nodetool compactionstats

pending tasks: 0
{quote}
but in the MBean Compaction/TotalCompactionsCompleted there are recent 
statistic in events/second for:
 * Count
 * FifteenMinueRate
 * FiveMinueRate
 * MeanRate
 * OneMinuteRate

1) It would be useful to see in addition:
{quote}pending tasks: 0

compactions completed: 20

    1 minute rate:    0/second

   5 minute rate:    2.3/second

  15 minute rate:   4.6/second
{quote}
2) Since compaction_throughput_mb_per_sec is a throttling parameter in 
cassandra.yaml (default 64 MBps), it would be nice to show the actual 
compaction throughput and be able to observe if you're close to the limit.  
I.e., 
{quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
{quote}
3) for completness, compactionstats should list the number of concurrent 
compactors configured

compaction throughput 13.2 MBps / 16 MBps (82.5%)

  was:
Nodetool compactionstats reports only on active compactions, if nothing is 
active, you see only:
{quote}$nodetool compactionstats

pending tasks: 0
{quote}
but in the MBean Compaction/TotalCompactionsCompleted there are recent 
statistic in events/second for:
 * Count
 * FifteenMinueRate
 * FiveMinueRate
 * MeanRate
 * OneMinuteRate

It would be useful to see in addition:
{quote}pending tasks: 0

compactions completed: 20

    1 minute rate:    0/second

   5 minute rate:    2.3/second

  15 minute rate:   4.6/second
{quote}
Also, since compaction_throughput_mb_per_sec is a throttling parameter in 
cassandra.yaml (default 64 MBps), it would be nice to show the actual 
compaction throughput and be able to observe if you're close to the limit.  
I.e., 
{quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
{quote}


> Enhance nodetool compactionstats with existing MBean metrics
> 
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Nodetool compactionstats reports only on active compactions, if nothing is 
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent 
> statistic in events/second for:
>  * Count
>  * FifteenMinueRate
>  * FiveMinueRate
>  * MeanRate
>  * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
>     1 minute rate:    0/second
>    5 minute rate:    2.3/second
>   15 minute rate:   4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in 
> cassandra.yaml (default 64 MBps), it would be nice to show the actual 
> compaction throughput and be able to observe if you're close to the limit.  
> I.e., 
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent 
> compactors configured
> compaction throughput 13.2 MBps / 16 MBps (82.5%)



--
This message was sent by Atlassian Jira
(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-18305) Enhance nodetool compactionstats with existing MBean metrics

[Brad Schoening (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brad Schoening updated CASSANDRA-18305:
---
Description: 
Nodetool compactionstats reports only on active compactions, if nothing is 
active, you see only:
{quote}$nodetool compactionstats

pending tasks: 0
{quote}
but in the MBean Compaction/TotalCompactionsCompleted there are recent 
statistic in events/second for:
 * Count
 * FifteenMinueRate
 * FiveMinueRate
 * MeanRate
 * OneMinuteRate

It would be useful to see in addition:
{quote}pending tasks: 0

compactions completed: 20

    1 minute rate:    0/second

   5 minute rate:    2.3/second

  15 minute rate:   4.6/second
{quote}
Also, since compaction_throughput_mb_per_sec is a throttling parameter in 
cassandra.yaml (default 64 MBps), it would be nice to show the actual 
compaction throughput and be able to observe if you're close to the limit.  
I.e., 
{quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
{quote}

  was:
Nodetool compactionstats reports only on active compactions, if nothing is 
active, you see only:
{quote}$nodetool compactionstats

pending tasks: 0
{quote}
but in the MBean Compaction/TotalCompactionsCompleted there are recent 
statistic in events/second for:
 * Count
 * FifteenMinueRate
 * FiveMinueRate
 * MeanRate
 * OneMinuteRate

It would be useful to see in addition:
{quote}pending tasks: 0

compactions completed: 20

    1 minute rate:    0/second

   5 minute rate:    2.3/second

  15 minute rate:   4.6/second
{quote}
Also, since compaction_throughput_mb_per_sec is a throttling parameter in 
cassandra.yaml, it would be nice to show the actual compaction throughput and 
be able to observe if you're close to the limit.  I.e., 
{quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
{quote}


> Enhance nodetool compactionstats with existing MBean metrics
> 
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Nodetool compactionstats reports only on active compactions, if nothing is 
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent 
> statistic in events/second for:
>  * Count
>  * FifteenMinueRate
>  * FiveMinueRate
>  * MeanRate
>  * OneMinuteRate
> It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
>     1 minute rate:    0/second
>    5 minute rate:    2.3/second
>   15 minute rate:   4.6/second
> {quote}
> Also, since compaction_throughput_mb_per_sec is a throttling parameter in 
> cassandra.yaml (default 64 MBps), it would be nice to show the actual 
> compaction throughput and be able to observe if you're close to the limit.  
> I.e., 
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Re: [jira] [Updated] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics

[guo Maxwell]

Had a similar need early and have been trying to solve it. Looking forward
to this patch.

Brad Schoening (Jira) 于2023年3月8日 周三下午12:15写道：

>
>  [
> https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Brad Schoening updated CASSANDRA-18305:
> ---
> Description:
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
>
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
>  * Count
>  * FifteenMinueRate
>  * FiveMinueRate
>  * MeanRate
>  * OneMinuteRate
>
> It would be useful to see in addition:
> {quote}pending tasks: 0
>
> compactions completed: 20
>
> 1 minute rate:0/second
>
>5 minute rate:2.3/second
>
>   15 minute rate:   4.6/second
> {quote}
> Also, since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml, it would be nice to show the actual compaction throughput
> and be able to observe if you're close to the limit.  I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
>
>   was:
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
>
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
>  * Count
>  * FifteenMinueRate
>  * FiveMinueRate
>  * MeanRate
>  * OneMinuteRate
>
> It would be useful to see in addition:
> {quote}pending tasks: 0
>
> compactions completed: 20
>
> 1 minute rate:0/second
>
>5 minute rate:2.3/second
>
>   15 minute rate:   4.6/second
> {quote}
> Also, since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml, it would be nice to report the actual compaction throughput
> and be able to observe if you're close to the limit.  I.e.,
>
>   compaction throughput 13.2 MBps / 16 MBps (82.5%)
>
>
> > Enhance nodetool compactionstats with existing MBean metrics
> > 
> >
> > Key: CASSANDRA-18305
> > URL:
> https://issues.apache.org/jira/browse/CASSANDRA-18305
> > Project: Cassandra
> >  Issue Type: Improvement
> >  Components: Tool/nodetool
> >Reporter: Brad Schoening
> >Assignee: Stefan Miklosovic
> >Priority: Normal
> >
> > Nodetool compactionstats reports only on active compactions, if nothing
> is active, you see only:
> > {quote}$nodetool compactionstats
> > pending tasks: 0
> > {quote}
> > but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> >  * Count
> >  * FifteenMinueRate
> >  * FiveMinueRate
> >  * MeanRate
> >  * OneMinuteRate
> > It would be useful to see in addition:
> > {quote}pending tasks: 0
> > compactions completed: 20
> > 1 minute rate:0/second
> >5 minute rate:2.3/second
> >   15 minute rate:   4.6/second
> > {quote}
> > Also, since compaction_throughput_mb_per_sec is a throttling parameter
> in cassandra.yaml, it would be nice to show the actual compaction
> throughput and be able to observe if you're close to the limit.  I.e.,
> > {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> > {quote}
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.20.10#820010)
>
> -
> To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: commits-h...@cassandra.apache.org
>
> --
you are the apple of my eye !

[jira] [Updated] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics

[Brad Schoening (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brad Schoening updated CASSANDRA-18305:
---
Description: 
Nodetool compactionstats reports only on active compactions, if nothing is 
active, you see only:
{quote}$nodetool compactionstats

pending tasks: 0
{quote}
but in the MBean Compaction/TotalCompactionsCompleted there are recent 
statistic in events/second for:
 * Count
 * FifteenMinueRate
 * FiveMinueRate
 * MeanRate
 * OneMinuteRate

It would be useful to see in addition:
{quote}pending tasks: 0

compactions completed: 20

    1 minute rate:    0/second

   5 minute rate:    2.3/second

  15 minute rate:   4.6/second
{quote}
Also, since compaction_throughput_mb_per_sec is a throttling parameter in 
cassandra.yaml, it would be nice to show the actual compaction throughput and 
be able to observe if you're close to the limit.  I.e., 
{quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
{quote}

  was:
Nodetool compactionstats reports only on active compactions, if nothing is 
active, you see only:
{quote}$nodetool compactionstats

pending tasks: 0
{quote}
but in the MBean Compaction/TotalCompactionsCompleted there are recent 
statistic in events/second for:
 * Count
 * FifteenMinueRate
 * FiveMinueRate
 * MeanRate
 * OneMinuteRate

It would be useful to see in addition:
{quote}pending tasks: 0

compactions completed: 20

    1 minute rate:    0/second

   5 minute rate:    2.3/second

  15 minute rate:   4.6/second
{quote}
Also, since compaction_throughput_mb_per_sec is a throttling parameter in 
cassandra.yaml, it would be nice to report the actual compaction throughput and 
be able to observe if you're close to the limit.  I.e., 

  compaction throughput 13.2 MBps / 16 MBps (82.5%)


> Enhance nodetool compactionstats with existing MBean metrics
> 
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Nodetool compactionstats reports only on active compactions, if nothing is 
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent 
> statistic in events/second for:
>  * Count
>  * FifteenMinueRate
>  * FiveMinueRate
>  * MeanRate
>  * OneMinuteRate
> It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
>     1 minute rate:    0/second
>    5 minute rate:    2.3/second
>   15 minute rate:   4.6/second
> {quote}
> Also, since compaction_throughput_mb_per_sec is a throttling parameter in 
> cassandra.yaml, it would be nice to show the actual compaction throughput and 
> be able to observe if you're close to the limit.  I.e., 
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}



--
This message was sent by Atlassian Jira
(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-18305) Enhance nodetool compactionstats with existing MBean metrics

[Brad Schoening (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brad Schoening updated CASSANDRA-18305:
---
Description: 
Nodetool compactionstats reports only on active compactions, if nothing is 
active, you see only:
{quote}$nodetool compactionstats

pending tasks: 0
{quote}
but in the MBean Compaction/TotalCompactionsCompleted there are recent 
statistic in events/second for:
 * Count
 * FifteenMinueRate
 * FiveMinueRate
 * MeanRate
 * OneMinuteRate

It would be useful to see in addition:
{quote}pending tasks: 0

compactions completed: 20

    1 minute rate:    0/second

   5 minute rate:    2.3/second

  15 minute rate:   4.6/second
{quote}
Also, since compaction_throughput_mb_per_sec is a throttling parameter in 
cassandra.yaml, it would be nice to report the actual compaction throughput and 
be able to observe if you're close to the limit.  I.e., 

  compaction throughput 13.2 MBps / 16 MBps (82.5%)

  was:
Nodetool compactionstats reports only on active compactions, if nothing is 
active, you see only:
{quote}$nodetool compactionstats

pending tasks: 0
{quote}
but in the MBean Compaction/TotalCompactionsCompleted there are recent 
statistic in events/second for:
 * Count
 * FifteenMinueRate
 * FiveMinueRate
 * MeanRate
 * OneMinuteRate

It would be useful to see in addition:
{quote}pending tasks: 0

compactions completed: 20

    1 minute rate:    0/second

   5 minute rate:    2.3/second

  15 minute rate:   4.6/second
{quote}


> Enhance nodetool compactionstats with existing MBean metrics
> 
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Nodetool compactionstats reports only on active compactions, if nothing is 
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent 
> statistic in events/second for:
>  * Count
>  * FifteenMinueRate
>  * FiveMinueRate
>  * MeanRate
>  * OneMinuteRate
> It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
>     1 minute rate:    0/second
>    5 minute rate:    2.3/second
>   15 minute rate:   4.6/second
> {quote}
> Also, since compaction_throughput_mb_per_sec is a throttling parameter in 
> cassandra.yaml, it would be nice to report the actual compaction throughput 
> and be able to observe if you're close to the limit.  I.e., 
>   compaction throughput 13.2 MBps / 16 MBps (82.5%)



--
This message was sent by Atlassian Jira
(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-18294) die disk failure policy will not kill jvm as documented

[maxwellguo (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697712#comment-17697712
 ] 

maxwellguo commented on CASSANDRA-18294:


[~smiklosovic]can you help to take a look agagin ?

> die disk failure policy will not kill jvm as documented
> ---
>
> Key: CASSANDRA-18294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18294
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x, 4.0.x, 4.1.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After Cassandra has successfully starts up with disk_failure_policy die, when 
> encounter a file system error, Cassandra server will only throw exception 
> instead of shut down gossip and client transport and kill JVM. Document: 
> [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#disk_failure_policy]
>  
> The reason for this is the default FS error handler is not handing policy die 
> correctly. Instead of shutting down gossip and native transport, it throws an 
> error.
>  
> The JVMStabilityInspectorTest is passing because the error handler is not set 
> so no exception is thrown.



--
This message was sent by Atlassian Jira
(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-18294) die disk failure policy will not kill jvm as documented

[Runtian Liu (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697711#comment-17697711
 ] 

Runtian Liu commented on CASSANDRA-18294:
-

updated

> die disk failure policy will not kill jvm as documented
> ---
>
> Key: CASSANDRA-18294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18294
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x, 4.0.x, 4.1.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After Cassandra has successfully starts up with disk_failure_policy die, when 
> encounter a file system error, Cassandra server will only throw exception 
> instead of shut down gossip and client transport and kill JVM. Document: 
> [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#disk_failure_policy]
>  
> The reason for this is the default FS error handler is not handing policy die 
> correctly. Instead of shutting down gossip and native transport, it throws an 
> error.
>  
> The JVMStabilityInspectorTest is passing because the error handler is not set 
> so no exception is thrown.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra-website] branch asf-staging updated (13dbfee3a -> 2495ba422)

[git-site-role]

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 13dbfee3a generate docs for c4206294
 new 2495ba422 generate docs for c4206294

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   (13dbfee3a)
\
 N -- N -- N   refs/heads/asf-staging (2495ba422)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 site-ui/build/ui-bundle.zip | Bin 4796442 -> 4796442 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-17698) sstabledump errors when dumping data from index

[maxwellguo (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697706#comment-17697706
 ] 

maxwellguo commented on CASSANDRA-17698:


It seems  CASSANDRA-17973 have also been closed, so this patch can be checkin 
now ? 

[~blambov][~adelapena]:D

> sstabledump errors when dumping data from index
> ---
>
> Key: CASSANDRA-17698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17698
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/sstable
>Reporter: Stefan Miklosovic
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 5.x
>
>  Time Spent: 12h 40m
>  Remaining Estimate: 0h
>
> {code:java}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> cqlsh> exit
> ./bin/nodetool flush
> ./tools/bin/sstabledump 
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
>  
> [
>   {
>     "partition" : {
>       "key" : [ "Joe" ],
>       "position" : 0
>     },
>     "rows" : [
>       {
>         "type" : "row",
>         "position" : 17,
>         "clustering" : [ ] } ] } ]Exception in thread "main" 
> java.lang.UnsupportedOperationException
>         at 
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
>         at 
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
>         at 
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
>         at 
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
>         at 
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
>         at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
>         at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
>         at java.util.Iterator.forEachRemaining(Iterator.java:116)
>         at 
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>         at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
>         at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
>         at 
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
>         at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
>         at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>         at 
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
>         at 
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
>         at 
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {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] [Comment Edited] (CASSANDRA-18294) die disk failure policy will not kill jvm as documented

[maxwellguo (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697704#comment-17697704
 ] 

maxwellguo edited comment on CASSANDRA-18294 at 3/8/23 3:02 AM:


"private FSError throwFSError(){ " [~curlylrt]


was (Author: maxwellguo):
"private FSError throwFSError(){ "

> die disk failure policy will not kill jvm as documented
> ---
>
> Key: CASSANDRA-18294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18294
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x, 4.0.x, 4.1.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After Cassandra has successfully starts up with disk_failure_policy die, when 
> encounter a file system error, Cassandra server will only throw exception 
> instead of shut down gossip and client transport and kill JVM. Document: 
> [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#disk_failure_policy]
>  
> The reason for this is the default FS error handler is not handing policy die 
> correctly. Instead of shutting down gossip and native transport, it throws an 
> error.
>  
> The JVMStabilityInspectorTest is passing because the error handler is not set 
> so no exception is thrown.



--
This message was sent by Atlassian Jira
(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-18294) die disk failure policy will not kill jvm as documented

[maxwellguo (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697704#comment-17697704
 ] 

maxwellguo commented on CASSANDRA-18294:


"private FSError throwFSError(){ "

> die disk failure policy will not kill jvm as documented
> ---
>
> Key: CASSANDRA-18294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18294
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x, 4.0.x, 4.1.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After Cassandra has successfully starts up with disk_failure_policy die, when 
> encounter a file system error, Cassandra server will only throw exception 
> instead of shut down gossip and client transport and kill JVM. Document: 
> [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#disk_failure_policy]
>  
> The reason for this is the default FS error handler is not handing policy die 
> correctly. Instead of shutting down gossip and native transport, it throws an 
> error.
>  
> The JVMStabilityInspectorTest is passing because the error handler is not set 
> so no exception is thrown.



--
This message was sent by Atlassian Jira
(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-18294) die disk failure policy will not kill jvm as documented

[Runtian Liu (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697696#comment-17697696
 ] 

Runtian Liu commented on CASSANDRA-18294:
-

which one?

> die disk failure policy will not kill jvm as documented
> ---
>
> Key: CASSANDRA-18294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18294
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x, 4.0.x, 4.1.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After Cassandra has successfully starts up with disk_failure_policy die, when 
> encounter a file system error, Cassandra server will only throw exception 
> instead of shut down gossip and client transport and kill JVM. Document: 
> [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#disk_failure_policy]
>  
> The reason for this is the default FS error handler is not handing policy die 
> correctly. Instead of shutting down gossip and native transport, it throws an 
> error.
>  
> The JVMStabilityInspectorTest is passing because the error handler is not set 
> so no exception is thrown.



--
This message was sent by Atlassian Jira
(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-18294) die disk failure policy will not kill jvm as documented

[maxwellguo (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697684#comment-17697684
 ] 

maxwellguo commented on CASSANDRA-18294:


there is one left 

> die disk failure policy will not kill jvm as documented
> ---
>
> Key: CASSANDRA-18294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18294
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x, 4.0.x, 4.1.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After Cassandra has successfully starts up with disk_failure_policy die, when 
> encounter a file system error, Cassandra server will only throw exception 
> instead of shut down gossip and client transport and kill JVM. Document: 
> [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#disk_failure_policy]
>  
> The reason for this is the default FS error handler is not handing policy die 
> correctly. Instead of shutting down gossip and native transport, it throws an 
> error.
>  
> The JVMStabilityInspectorTest is passing because the error handler is not set 
> so no exception is thrown.



--
This message was sent by Atlassian Jira
(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-18294) die disk failure policy will not kill jvm as documented

[Runtian Liu (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697681#comment-17697681
 ] 

Runtian Liu commented on CASSANDRA-18294:
-

Updated the format.

> die disk failure policy will not kill jvm as documented
> ---
>
> Key: CASSANDRA-18294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18294
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x, 4.0.x, 4.1.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After Cassandra has successfully starts up with disk_failure_policy die, when 
> encounter a file system error, Cassandra server will only throw exception 
> instead of shut down gossip and client transport and kill JVM. Document: 
> [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#disk_failure_policy]
>  
> The reason for this is the default FS error handler is not handing policy die 
> correctly. Instead of shutting down gossip and native transport, it throws an 
> error.
>  
> The JVMStabilityInspectorTest is passing because the error handler is not set 
> so no exception is thrown.



--
This message was sent by Atlassian Jira
(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-18296) tablehistograms add filter for data table and system table

[maxwellguo (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697677#comment-17697677
 ] 

maxwellguo commented on CASSANDRA-18296:


ok, thanks [~brandon.williams], I think I will ask on ML for consensus.

>  tablehistograms add filter for data table and system table
> ---
>
> Key: CASSANDRA-18296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18296
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: maxwellguo
>Assignee: maxwellguo
>Priority: Normal
>
> Add some options for nodetool tablehistograms to filter the output 
> of System tables and data tables.
> As we know if we nodetool tablehistograms all tables will be output ,but 
> system table 's number are too much.
> Add options to filter only output data tables or system tables, together with 
> the already exist ks.tb lists, the output options are just fine.
> It seems that tablestats got the -i option that can ignore keyspace, just add 
> this first, and then to see wether this can meet our needs



--
This message was sent by Atlassian Jira
(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-18294) die disk failure policy will not kill jvm as documented

[maxwellguo (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

maxwellguo updated CASSANDRA-18294:
---
Reviewers: Brandon Williams, maxwellguo, Stefan Miklosovic

> die disk failure policy will not kill jvm as documented
> ---
>
> Key: CASSANDRA-18294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18294
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x, 4.0.x, 4.1.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After Cassandra has successfully starts up with disk_failure_policy die, when 
> encounter a file system error, Cassandra server will only throw exception 
> instead of shut down gossip and client transport and kill JVM. Document: 
> [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#disk_failure_policy]
>  
> The reason for this is the default FS error handler is not handing policy die 
> correctly. Instead of shutting down gossip and native transport, it throws an 
> error.
>  
> The JVMStabilityInspectorTest is passing because the error handler is not set 
> so no exception is thrown.



--
This message was sent by Atlassian Jira
(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-18294) die disk failure policy will not kill jvm as documented

[maxwellguo (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697675#comment-17697675
 ] 

maxwellguo commented on CASSANDRA-18294:


I am + 1 on this patch , but there are some very small problems about code 
format.
such as : some constructor should start a new line with '{', I have already 
pointed out , [~curlylrt]can you help to take a look at them ? thanks.

> die disk failure policy will not kill jvm as documented
> ---
>
> Key: CASSANDRA-18294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18294
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x, 4.0.x, 4.1.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After Cassandra has successfully starts up with disk_failure_policy die, when 
> encounter a file system error, Cassandra server will only throw exception 
> instead of shut down gossip and client transport and kill JVM. Document: 
> [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#disk_failure_policy]
>  
> The reason for this is the default FS error handler is not handing policy die 
> correctly. Instead of shutting down gossip and native transport, it throws an 
> error.
>  
> The JVMStabilityInspectorTest is passing because the error handler is not set 
> so no exception is thrown.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra-website] branch asf-staging updated (62913562a -> 13dbfee3a)

[git-site-role]

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 62913562a generate docs for c4206294
 new 13dbfee3a generate docs for c4206294

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   (62913562a)
\
 N -- N -- N   refs/heads/asf-staging (13dbfee3a)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 site-ui/build/ui-bundle.zip | Bin 4796442 -> 4796442 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics

[Brad Schoening (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brad Schoening updated CASSANDRA-18305:
---
Description: 
Nodetool compactionstats reports only on active compactions, if nothing is 
active, you see only:
{quote}$nodetool compactionstats

pending tasks: 0
{quote}
but in the MBean Compaction/TotalCompactionsCompleted there are recent 
statistic in events/second for:
 * Count
 * FifteenMinueRate
 * FiveMinueRate
 * MeanRate
 * OneMinuteRate

It would be useful to see in addition:
{quote}pending tasks: 0

compactions completed: 20

    1 minute rate:    0/second

   5 minute rate:    2.3/second

  15 minute rate:   4.6/second
{quote}

  was:
Nodetool compactionstats reports only on active compactions, if nothing is 
active, you see only:
{quote}$nodetool tablestats

pending tasks: 0
{quote}
but in the MBean Compaction/TotalCompactionsCompleted there are recent 
statistic in events/second for:
 * Count
 * FifteenMinueRate
 * FiveMinueRate
 * MeanRate
 * OneMinuteRate

It would be useful to see in addition:
{quote}pending tasks: 0

compactions completed: 20

    1 minute rate:    0/second

   5 minute rate:    2.3/second

  15 minute rate:   4.6/second
{quote}


> Enhance nodetool compactionstats with existing MBean metrics
> 
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Nodetool compactionstats reports only on active compactions, if nothing is 
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent 
> statistic in events/second for:
>  * Count
>  * FifteenMinueRate
>  * FiveMinueRate
>  * MeanRate
>  * OneMinuteRate
> It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
>     1 minute rate:    0/second
>    5 minute rate:    2.3/second
>   15 minute rate:   4.6/second
> {quote}



--
This message was sent by Atlassian Jira
(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-18305) Enhance nodetool compactionstats with existing MBean metrics

[Stefan Miklosovic (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic reassigned CASSANDRA-18305:
-

Assignee: Stefan Miklosovic

> Enhance nodetool compactionstats with existing MBean metrics
> 
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Nodetool compactionstats reports only on active compactions, if nothing is 
> active, you see only:
> {quote}$nodetool tablestats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent 
> statistic in events/second for:
>  * Count
>  * FifteenMinueRate
>  * FiveMinueRate
>  * MeanRate
>  * OneMinuteRate
> It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
>     1 minute rate:    0/second
>    5 minute rate:    2.3/second
>   15 minute rate:   4.6/second
> {quote}



--
This message was sent by Atlassian Jira
(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-18268) Log completed status with cleanup and garbagecollect operations

[Stefan Miklosovic (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-18268:
--
Authors: Milan Krisko, Stefan Miklosovic  (was: Milan Krisko)
  Fix Version/s: 5.0
Source Control Link: 
https://github.com/apache/cassandra/commit/180f0f0b5b47a48c1a7d88927223cc52871cc801
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Log completed status with cleanup and garbagecollect operations
> ---
>
> Key: CASSANDRA-18268
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18268
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability/Logging
>Reporter: Kan Maung
>Assignee: Milan Krisko
>Priority: Normal
> Fix For: 5.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Whenever a cleanup or garbagecollect operation is issued from nodetool, there 
> is no log statuses for the start and end of the operation at the node level 
> although statuses on individual sstables are captured. Start can be inferred, 
> but it is difficult to know when the operation has completed because there is 
> no log message.
>  
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:353 - 
> Starting Remove deleted data for keyspace1.sstable1
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 - 
> Finished Remove deleted data for keyspace1.sstable1 successfully
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:353 - 
> Starting Remove deleted data for keyspace1.sstable2
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:364 - No 
> sstables to GARBAGE_COLLECT for keyspace1.sstable2
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 - 
> Finished Remove deleted data for keyspace1.sstable2 successfully
>  
> This improvement proposes adding additional for start and end statuses log 
> messages for the above operation at the node level. I.e.,
>  
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 – 
> Starting GARBAGE_COLLECT
> ….
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 – 
> Completed GARBAGE_COLLECT



--
This message was sent by Atlassian Jira
(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-18268) Log completed status with cleanup and garbagecollect operations

[Stefan Miklosovic (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-18268:
--
Reviewers: Brad Schoening, Brandon Williams, Kan Maung  (was: Brandon 
Williams, Kan Maung, Stefan Miklosovic)

> Log completed status with cleanup and garbagecollect operations
> ---
>
> Key: CASSANDRA-18268
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18268
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability/Logging
>Reporter: Kan Maung
>Assignee: Milan Krisko
>Priority: Normal
> Fix For: 5.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Whenever a cleanup or garbagecollect operation is issued from nodetool, there 
> is no log statuses for the start and end of the operation at the node level 
> although statuses on individual sstables are captured. Start can be inferred, 
> but it is difficult to know when the operation has completed because there is 
> no log message.
>  
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:353 - 
> Starting Remove deleted data for keyspace1.sstable1
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 - 
> Finished Remove deleted data for keyspace1.sstable1 successfully
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:353 - 
> Starting Remove deleted data for keyspace1.sstable2
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:364 - No 
> sstables to GARBAGE_COLLECT for keyspace1.sstable2
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 - 
> Finished Remove deleted data for keyspace1.sstable2 successfully
>  
> This improvement proposes adding additional for start and end statuses log 
> messages for the above operation at the node level. I.e.,
>  
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 – 
> Starting GARBAGE_COLLECT
> ….
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 – 
> Completed GARBAGE_COLLECT



--
This message was sent by Atlassian Jira
(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-18268) Add more logging around CompactionManager operations

[Stefan Miklosovic (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-18268:
--
Summary: Add more logging around CompactionManager operations  (was: Log 
completed status with cleanup and garbagecollect operations)

> Add more logging around CompactionManager operations
> 
>
> Key: CASSANDRA-18268
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18268
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability/Logging
>Reporter: Kan Maung
>Assignee: Milan Krisko
>Priority: Normal
> Fix For: 5.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Whenever a cleanup or garbagecollect operation is issued from nodetool, there 
> is no log statuses for the start and end of the operation at the node level 
> although statuses on individual sstables are captured. Start can be inferred, 
> but it is difficult to know when the operation has completed because there is 
> no log message.
>  
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:353 - 
> Starting Remove deleted data for keyspace1.sstable1
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 - 
> Finished Remove deleted data for keyspace1.sstable1 successfully
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:353 - 
> Starting Remove deleted data for keyspace1.sstable2
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:364 - No 
> sstables to GARBAGE_COLLECT for keyspace1.sstable2
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 - 
> Finished Remove deleted data for keyspace1.sstable2 successfully
>  
> This improvement proposes adding additional for start and end statuses log 
> messages for the above operation at the node level. I.e.,
>  
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 – 
> Starting GARBAGE_COLLECT
> ….
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 – 
> Completed GARBAGE_COLLECT



--
This message was sent by Atlassian Jira
(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-18306) Post 4.x Clean up

[Ekaterina Dimitrova (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697623#comment-17697623
 ] 

Ekaterina Dimitrova edited comment on CASSANDRA-18306 at 3/7/23 8:56 PM:
-

Another point of view is that they will be under breaking changes in NEWS.txt 
but that one tends to be forgotten to be timely updated so having also ticket 
label etc might help us actually catch ourselves before the release that we 
missed some of those in NEWS.txt


was (Author: e.dimitrova):
Another point of view is that they will be under breaking changes in NEWS.txt 
but that one tends to be forgotten to be timely updated so having also label 
etc might help us actually catch ourselves before the release that we missed 
some of those in NEWS.txt

> Post 4.x Clean up
> -
>
> Key: CASSANDRA-18306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18306
> Project: Cassandra
>  Issue Type: Task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> Trunk being now 5.0 means we no longer recommend users, nor test ourselves, 
> upgrades from version 3.11 or earlier.
> There is a lot that can be cleaned up, especially in the test code, around 
> earlier versions (including older sstable formats and MessagingService 
> versions). Stuff that was deprecated before 4.0 can also be removed. A number 
> of separate tickets already exist for the latter.
> What this ticket is willing to remove will be checked with dev@



--
This message was sent by Atlassian Jira
(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-18268) Log completed status with cleanup and garbagecollect operations

[Stefan Miklosovic (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-18268:
--
Reviewers: Brandon Williams, Kan Maung, Stefan Miklosovic  (was: Brandon 
Williams, Stefan Miklosovic)
   Status: Review In Progress  (was: Patch Available)

> Log completed status with cleanup and garbagecollect operations
> ---
>
> Key: CASSANDRA-18268
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18268
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability/Logging
>Reporter: Kan Maung
>Assignee: Milan Krisko
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Whenever a cleanup or garbagecollect operation is issued from nodetool, there 
> is no log statuses for the start and end of the operation at the node level 
> although statuses on individual sstables are captured. Start can be inferred, 
> but it is difficult to know when the operation has completed because there is 
> no log message.
>  
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:353 - 
> Starting Remove deleted data for keyspace1.sstable1
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 - 
> Finished Remove deleted data for keyspace1.sstable1 successfully
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:353 - 
> Starting Remove deleted data for keyspace1.sstable2
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:364 - No 
> sstables to GARBAGE_COLLECT for keyspace1.sstable2
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 - 
> Finished Remove deleted data for keyspace1.sstable2 successfully
>  
> This improvement proposes adding additional for start and end statuses log 
> messages for the above operation at the node level. I.e.,
>  
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 – 
> Starting GARBAGE_COLLECT
> ….
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 – 
> Completed GARBAGE_COLLECT



--
This message was sent by Atlassian Jira
(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-18268) Log completed status with cleanup and garbagecollect operations

[Stefan Miklosovic (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-18268:
--
Status: Ready to Commit  (was: Review In Progress)

> Log completed status with cleanup and garbagecollect operations
> ---
>
> Key: CASSANDRA-18268
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18268
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability/Logging
>Reporter: Kan Maung
>Assignee: Milan Krisko
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Whenever a cleanup or garbagecollect operation is issued from nodetool, there 
> is no log statuses for the start and end of the operation at the node level 
> although statuses on individual sstables are captured. Start can be inferred, 
> but it is difficult to know when the operation has completed because there is 
> no log message.
>  
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:353 - 
> Starting Remove deleted data for keyspace1.sstable1
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 - 
> Finished Remove deleted data for keyspace1.sstable1 successfully
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:353 - 
> Starting Remove deleted data for keyspace1.sstable2
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:364 - No 
> sstables to GARBAGE_COLLECT for keyspace1.sstable2
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 - 
> Finished Remove deleted data for keyspace1.sstable2 successfully
>  
> This improvement proposes adding additional for start and end statuses log 
> messages for the above operation at the node level. I.e.,
>  
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 – 
> Starting GARBAGE_COLLECT
> ….
> [INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 – 
> Completed GARBAGE_COLLECT



--
This message was sent by Atlassian Jira
(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-18306) Post 4.x Clean up

[Ekaterina Dimitrova (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697623#comment-17697623
 ] 

Ekaterina Dimitrova edited comment on CASSANDRA-18306 at 3/7/23 8:56 PM:
-

Another point of view is that they will be under breaking changes in NEWS.txt 
but that one tends to be forgotten to be timely updated so having also label 
etc might help us actually catch ourselves before the release that we missed 
some of those in NEWS.txt


was (Author: e.dimitrova):
Another point of view is that they will be under breaking changes in NEWS.txt 
but that one tends to be forgotten so having also label etc might help us 
actually catch ourselves before the release that we missed some of those in 
NEWS.txt

> Post 4.x Clean up
> -
>
> Key: CASSANDRA-18306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18306
> Project: Cassandra
>  Issue Type: Task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> Trunk being now 5.0 means we no longer recommend users, nor test ourselves, 
> upgrades from version 3.11 or earlier.
> There is a lot that can be cleaned up, especially in the test code, around 
> earlier versions (including older sstable formats and MessagingService 
> versions). Stuff that was deprecated before 4.0 can also be removed. A number 
> of separate tickets already exist for the latter.
> What this ticket is willing to remove will be checked with dev@



--
This message was sent by Atlassian 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 (0bed1967fd -> 180f0f0b5b)

[smiklosovic]

This is an automated email from the ASF dual-hosted git repository.

smiklosovic pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git


from 0bed1967fd Merge branch 'cassandra-4.1' into trunk
 add 180f0f0b5b Add more logging around CompactionManager operations

No new revisions were added by this update.

Summary of changes:
 CHANGES.txt|  1 +
 .../cassandra/db/compaction/CompactionManager.java | 20 +++-
 .../apache/cassandra/service/StorageService.java   | 38 ++
 3 files changed, 38 insertions(+), 21 deletions(-)


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-18306) Post 4.x Clean up

[Ekaterina Dimitrova (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697623#comment-17697623
 ] 

Ekaterina Dimitrova commented on CASSANDRA-18306:
-

Another point of view is that they will be under breaking changes in NEWS.txt 
but that one tends to be forgotten so having also label etc might help us 
actually catch ourselves before the release that we missed some of those in 
NEWS.txt

> Post 4.x Clean up
> -
>
> Key: CASSANDRA-18306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18306
> Project: Cassandra
>  Issue Type: Task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> Trunk being now 5.0 means we no longer recommend users, nor test ourselves, 
> upgrades from version 3.11 or earlier.
> There is a lot that can be cleaned up, especially in the test code, around 
> earlier versions (including older sstable formats and MessagingService 
> versions). Stuff that was deprecated before 4.0 can also be removed. A number 
> of separate tickets already exist for the latter.
> What this ticket is willing to remove will be checked with dev@



--
This message was sent by Atlassian Jira
(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-18306) Post 4.x Clean up

[Ekaterina Dimitrova (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697622#comment-17697622
 ] 

Ekaterina Dimitrova edited comment on CASSANDRA-18306 at 3/7/23 8:54 PM:
-

I am wondering, do we want some kind of umbrella ticket or epic or just label 
so we can have all those summarized at one place, even if different people are 
opening/working/reviewing those? Does it make sense and make it more clear for 
people?


was (Author: e.dimitrova):
I am wondering, do we want some kind of umbrella ticket or epic so we can have 
all those summarized at one place, even if different people are 
opening/working/reviewing those? Does it make sense and make it more clear for 
people?

> Post 4.x Clean up
> -
>
> Key: CASSANDRA-18306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18306
> Project: Cassandra
>  Issue Type: Task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> Trunk being now 5.0 means we no longer recommend users, nor test ourselves, 
> upgrades from version 3.11 or earlier.
> There is a lot that can be cleaned up, especially in the test code, around 
> earlier versions (including older sstable formats and MessagingService 
> versions). Stuff that was deprecated before 4.0 can also be removed. A number 
> of separate tickets already exist for the latter.
> What this ticket is willing to remove will be checked with dev@



--
This message was sent by Atlassian Jira
(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-18306) Post 4.x Clean up

[Ekaterina Dimitrova (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697622#comment-17697622
 ] 

Ekaterina Dimitrova edited comment on CASSANDRA-18306 at 3/7/23 8:54 PM:
-

I am wondering, do we want some kind of umbrella ticket or epic so we can have 
all those summarized at one place, even if different people are 
opening/working/reviewing those? Does it make sense and make it more clear for 
people?


was (Author: e.dimitrova):
I am wondering, do we want some kind of umbrella ticket or epic so we can have 
all those at one place, even if different people are opening/working/reviewing 
those? Does it make sense and make it more clear for people?

> Post 4.x Clean up
> -
>
> Key: CASSANDRA-18306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18306
> Project: Cassandra
>  Issue Type: Task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> Trunk being now 5.0 means we no longer recommend users, nor test ourselves, 
> upgrades from version 3.11 or earlier.
> There is a lot that can be cleaned up, especially in the test code, around 
> earlier versions (including older sstable formats and MessagingService 
> versions). Stuff that was deprecated before 4.0 can also be removed. A number 
> of separate tickets already exist for the latter.
> What this ticket is willing to remove will be checked with dev@



--
This message was sent by Atlassian Jira
(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-18306) Post 4.x Clean up

[Ekaterina Dimitrova (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ekaterina Dimitrova updated CASSANDRA-18306:

Description: 
Trunk being now 5.0 means we no longer recommend users, nor test ourselves, 
upgrades from version 3.11 or earlier.

There is a lot that can be cleaned up, especially in the test code, around 
earlier versions (including older sstable formats and MessagingService 
versions). Stuff that was deprecated before 4.0 can also be removed. A number 
of separate tickets already exist for the latter.

What this ticket is willing to remove will be checked with dev@

  was:
Trunk being now 5.0 means we longer recommend users, nor test ourselves, 
upgrades from version 3.11 or earlier. 

There is a lot that can be cleaned up, especially in the test code, around 
earlier versions (including older sstable formats and MessagingService 
versions). Stuff that was deprecated before 4.0 can also be removed. A number 
of separate tickets already exist for the latter.

What this ticket is willing to remove will be checked with dev@


> Post 4.x Clean up
> -
>
> Key: CASSANDRA-18306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18306
> Project: Cassandra
>  Issue Type: Task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> Trunk being now 5.0 means we no longer recommend users, nor test ourselves, 
> upgrades from version 3.11 or earlier.
> There is a lot that can be cleaned up, especially in the test code, around 
> earlier versions (including older sstable formats and MessagingService 
> versions). Stuff that was deprecated before 4.0 can also be removed. A number 
> of separate tickets already exist for the latter.
> What this ticket is willing to remove will be checked with dev@



--
This message was sent by Atlassian Jira
(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-18306) Post 4.x Clean up

[Ekaterina Dimitrova (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697622#comment-17697622
 ] 

Ekaterina Dimitrova commented on CASSANDRA-18306:
-

I am wondering, do we want some kind of umbrella ticket or epic so we can have 
all those at one place, even if different people are opening/working/reviewing 
those? Does it make sense and make it more clear for people?

> Post 4.x Clean up
> -
>
> Key: CASSANDRA-18306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18306
> Project: Cassandra
>  Issue Type: Task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> Trunk being now 5.0 means we longer recommend users, nor test ourselves, 
> upgrades from version 3.11 or earlier. 
> There is a lot that can be cleaned up, especially in the test code, around 
> earlier versions (including older sstable formats and MessagingService 
> versions). Stuff that was deprecated before 4.0 can also be removed. A number 
> of separate tickets already exist for the latter.
> What this ticket is willing to remove will be checked with dev@



--
This message was sent by Atlassian Jira
(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-18306) Post 4.x Clean up

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-18306:
---
Fix Version/s: 5.x

> Post 4.x Clean up
> -
>
> Key: CASSANDRA-18306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18306
> Project: Cassandra
>  Issue Type: Task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> Trunk being now 5.0 means we longer recommend users, nor test ourselves, 
> upgrades from version 3.11 or earlier. 
> There is a lot that can be cleaned up, especially in the test code, around 
> earlier versions (including older sstable formats and MessagingService 
> versions). Stuff that was deprecated before 4.0 can also be removed. A number 
> of separate tickets already exist for the latter.
> What this ticket is willing to remove will be checked with dev@



--
This message was sent by Atlassian Jira
(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-18306) Post 4.x Clean up

[Michael Semb Wever (Jira)]

Michael Semb Wever created CASSANDRA-18306:
--

 Summary: Post 4.x Clean up
 Key: CASSANDRA-18306
 URL: https://issues.apache.org/jira/browse/CASSANDRA-18306
 Project: Cassandra
  Issue Type: Task
Reporter: Michael Semb Wever
Assignee: Michael Semb Wever


Trunk being now 5.0 means we longer recommend users, nor test ourselves, 
upgrades from version 3.11 or earlier. 

There is a lot that can be cleaned up, especially in the test code, around 
earlier versions (including older sstable formats and MessagingService 
versions). Stuff that was deprecated before 4.0 can also be removed. A number 
of separate tickets already exist for the latter.

What this ticket is willing to remove will be checked with dev@



--
This message was sent by Atlassian Jira
(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-18305) Enhance nodetool compactionstats with existing MBean metrics

[Brad Schoening (Jira)]

Brad Schoening created CASSANDRA-18305:
--

 Summary: Enhance nodetool compactionstats with existing MBean 
metrics
 Key: CASSANDRA-18305
 URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
 Project: Cassandra
  Issue Type: Improvement
  Components: Tool/nodetool
Reporter: Brad Schoening


Nodetool compactionstats reports only on active compactions, if nothing is 
active, you see only:
{quote}$nodetool tablestats

pending tasks: 0
{quote}
but in the MBean Compaction/TotalCompactionsCompleted there are recent 
statistic in events/second for:
 * Count
 * FifteenMinueRate
 * FiveMinueRate
 * MeanRate
 * OneMinuteRate

It would be useful to see in addition:
{quote}pending tasks: 0

compactions completed: 20

    1 minute rate:    0/second

   5 minute rate:    2.3/second

  15 minute rate:   4.6/second
{quote}



--
This message was sent by Atlassian Jira
(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-18249) Docker image for releases

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-18249:
---
Fix Version/s: 3.0.x
   3.11.x
   4.0.x
   4.1.x
   5.x

> Docker image for releases
> -
>
> Key: CASSANDRA-18249
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18249
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Berenguer Blasi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> The release process is currently driven bu this 
> [doc|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/release_process.adoc]
>  mainly.
> Some of the requirements are a Debian based distro and a number of packages. 
> As recently discovered this could be a problem, Ubuntu 20.04 LTS doesn't have 
> createrepo available i.e.
> To avoid such problems, add repeatability, have a controlled env where 
> releases are cut, enable more people to cut them, etc [~mck] suggested 
> creating a docker image to that purpose probably based off 
> [this|https://github.com/apache/cassandra-builds/blob/trunk/docker/bullseye-image.docker]



--
This message was sent by Atlassian Jira
(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-18284) Create 2023 Google Season of Documentation proposal and related blog post

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-18284:
---
Fix Version/s: 5.x

> Create 2023 Google Season of Documentation proposal and related blog post
> -
>
> Key: CASSANDRA-18284
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18284
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Lorina Poland
>Assignee: Lorina Poland
>Priority: Normal
> Fix For: 5.x
>
>
> Create a Google Season of Documentation proposal and related blog post.
>  * Apply for Open Collective account.
>  * Apply for GSoD grant. Requires writing blog post for URL for application.
>  * FYI - ticket will be close once GSoD application is submitted.
>  ** If grant is successful, modify blog post to advertise for tech writer 
> applicants.
>  ** Select tech writers.



--
This message was sent by Atlassian Jira
(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-16906) DOC - Formulae in Evaluating DM page does not display correctly

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-16906:
---
Fix Version/s: 5.x

> DOC - Formulae in Evaluating DM page does not display correctly
> ---
>
> Key: CASSANDRA-16906
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16906
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation
>Reporter: Takuya inagaki
>Assignee: Lorina Poland
>Priority: Normal
>  Labels: doc
> Fix For: 5.x
>
> Attachments: スクリーンショット 2021-08-31 18.03.57.png
>
>
> In latest document, all of formulas does not display correctly.
> please refer to the following 
> [document|https://cassandra.apache.org/doc/latest/cassandra/data_modeling/data_modeling_refining.html]
>  and attached image.
>  
> h3. Environment
> browser: chrome 92.0.4515.159
> os: macOS Big Sur 11.5.2
>  
> h3. Slack 
> [https://the-asf.slack.com/archives/CJZLTM05A/p1630400708095100]
> https://the-asf.slack.com/archives/CJZLTM05A/p1630400951095900



--
This message was sent by Atlassian Jira
(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-18071) Allow to use user-defined functions (UDF) as masking functions

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-18071:
---
Fix Version/s: 5.x

> Allow to use user-defined functions (UDF) as masking functions
> --
>
> Key: CASSANDRA-18071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18071
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Allow to attach user-defined functions (UDF) to tables so they can be used as 
> masking functions, as defined by 
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
>  This will be similar to the native data masking functions introduced by 
> CASSANDRA-17941 and attached to tables by CASSANDRA-18068.



--
This message was sent by Atlassian Jira
(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-18069) Add a new UNMASK permission

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-18069:
---
Fix Version/s: 5.x

> Add a new UNMASK permission
> ---
>
> Key: CASSANDRA-18069
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18069
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
>  Time Spent: 4h 50m
>  Remaining Estimate: 0h
>
> Add a new UNMASK permission allowing users with that permission to see the 
> data masked by the masking functions attached to columns introduced by 
> CASSANDRA-18068, as defined by 
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
> It would look like:
> {code}
> > CREATE TABLE patients (
>   id timeuuid PRIMARY KEY,
>   name text MASKED WITH default(),
>   birth date MASKED WITH default()
>   );
>  
> > INSERT INTO patients(id, name, birth) VALUES (now(), 'alice', '1982-12-21');
>  
> > CREATE USER unprivileged_user WITH PASSWORD 'xyz';
> > CREATE USER privileged_user WITH PASSWORD 'zyx';
>  
> > GRANT SELECT ON TABLE patients TO unprivileged_user;
> > GRANT SELECT ON TABLE patients TO privileged_user;
> > GRANT UNMASK ON TABLE patients TO privileged_user;
>  
> > LOGIN unprivileged_user
>  
> > SELECT name, birth FROM patients WHERE 
> > id=db2b372f-f91b-4537-b46b-c478f8330c29;
>  
>  name| birth
> -+
>  ale | 1900-01-01 
>  
> > LOGIN privileged_user
> > SELECT name, birth FROM patients WHERE 
> > id=db2b372f-f91b-4537-b46b-c478f8330c29;
>  
>  name  | birth
> ---+
>  alice | 1982-12-21
> {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-18070) Add a new SELECT_MASKED permission

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-18070:
---
Fix Version/s: 5.x

> Add a new SELECT_MASKED permission
> --
>
> Key: CASSANDRA-18070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18070
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Add a table-level SELECT_MASKED permission allowing certain users to query 
> but not see the unmasked columns introduced by CASSANDRA-18068, assuming that 
> they also have the SELECT permission on the table, as defined by 
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
>  
> It would look like:
> {code}
> > CREATE USER unprivileged_user WITH PASSWORD 'xyz';
> > CREATE USER privileged_user WITH PASSWORD 'zyx';
>  
> > GRANT SELECT ON ALL TABLE patients TO unprivileged_user;
> > GRANT SELECT ON ALL TABLE patients TO privileged_user;
> > GRANT SELECT_MASKED ON ALL TABLE patients TO privileged_user;
>  
> > LOGIN unprivileged_user
> > SELECT name, birth FROM patients WHERE name='alice' ALLOW FILTERING;
>  
> Unauthorized: Error from server: code=2100 [Unauthorized] message="User has 
> no UNMASK nor SELECT_UNMASK permission on "
>  
> > LOGIN privileged_user
> > SELECT name, birth FROM patients WHERE name='alice' ALLOW FILTERING;
>  
>  name| birth
> -+
>  ale | 1900-01-01
> {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-18302) Fix AIOOBE and improve validation messages for transaction statements

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-18302:
---
Fix Version/s: 5.x

> Fix AIOOBE and improve validation messages for transaction statements
> -
>
> Key: CASSANDRA-18302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18302
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown 
> from asCql method when validation transaction statement. In addition, asCql 
> does not return precisely the query user entered so the whole error message 
> can be misleading.



--
This message was sent by Atlassian Jira
(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-18294) die disk failure policy will not kill jvm as documented

[Brandon Williams (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697617#comment-17697617
 ] 

Brandon Williams commented on CASSANDRA-18294:
--

||Branch||CI||
|[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18294-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/894/workflows/2afa7943-477d-426c-9f0f-48a861845e0d]|
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18294-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/896/workflows/51b2f936-6b00-4d89-a284-b21b250e2ef1]|
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18294-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/892/workflows/e8e34bbb-e2e0-4074-9eb4-6a24e7c43b79],
 
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/892/workflows/73210bd7-1a92-43ca-bf83-548716ecc90a]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18294-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/895/workflows/89afae54-8308-41f0-b45f-5464d61486fe],
 
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/895/workflows/801d5316-5b14-4522-8b91-b6189493827b]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18294-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/893/workflows/f04714f6-746f-4065-a9e3-4804c1722f21],
 
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/893/workflows/0d8342e2-390b-40d0-8274-2e04846659e7]|


> die disk failure policy will not kill jvm as documented
> ---
>
> Key: CASSANDRA-18294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18294
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x, 4.0.x, 4.1.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After Cassandra has successfully starts up with disk_failure_policy die, when 
> encounter a file system error, Cassandra server will only throw exception 
> instead of shut down gossip and client transport and kill JVM. Document: 
> [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#disk_failure_policy]
>  
> The reason for this is the default FS error handler is not handing policy die 
> correctly. Instead of shutting down gossip and native transport, it throws an 
> error.
>  
> The JVMStabilityInspectorTest is passing because the error handler is not set 
> so no exception is thrown.



--
This message was sent by Atlassian Jira
(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-18294) die disk failure policy will not kill jvm as documented

[Runtian Liu (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697608#comment-17697608
 ] 

Runtian Liu commented on CASSANDRA-18294:
-

3.0 PR: https://github.com/apache/cassandra/pull/2189

3.11 PR: [https://github.com/apache/cassandra/pull/2200]

4.0 PR: [https://github.com/apache/cassandra/pull/2201]

4.1 PR: https://github.com/apache/cassandra/pull/2202

trunk PR: https://github.com/apache/cassandra/pull/2203

> die disk failure policy will not kill jvm as documented
> ---
>
> Key: CASSANDRA-18294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18294
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x, 4.0.x, 4.1.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After Cassandra has successfully starts up with disk_failure_policy die, when 
> encounter a file system error, Cassandra server will only throw exception 
> instead of shut down gossip and client transport and kill JVM. Document: 
> [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#disk_failure_policy]
>  
> The reason for this is the default FS error handler is not handing policy die 
> correctly. Instead of shutting down gossip and native transport, it throws an 
> error.
>  
> The JVMStabilityInspectorTest is passing because the error handler is not set 
> so no exception is thrown.



--
This message was sent by Atlassian Jira
(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-18125) Improve memtable allocator accounting when updating AtomicBTreePartition

[Jon Meredith (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jon Meredith updated CASSANDRA-18125:
-
  Fix Version/s: 4.0.9
 4.1.1
 5.0
 (was: 5.x)
 (was: 4.0.x)
 (was: 4.1.x)
  Since Version: 4.0.5
Source Control Link: 
https://github.com/apache/cassandra/commit/40f9ca60f103783aa481bc9a91b92fd55b4ea625
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Improve memtable allocator accounting when updating AtomicBTreePartition
> 
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Memtable
>Reporter: Nicolas Henneaux
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.9, 4.1.1, 5.0
>
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the 
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon 
> uncaughtException - Exception in thread 
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
>   at 
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
>   at 
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
>   at 
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
>   at 
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
>   at 
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
>   at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> {code} 
> {code}
> $ nodetool info
> ID : 
> Gossip active  : true
> Native Transport active: true
> Load   : 204.67 GiB
> Generation No  : 1670343179
> Uptime (seconds)   : 1110514
> Heap Memory (MB)   : 7218.07 / 24576.00
> Off Heap Memory (MB)   : 784.06
> Data Center: par
> Rack   : e1
> Exceptions : 1
> Key Cache  : entries 802712, size 100 MiB, capacity 100 MiB, 
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period 
> in seconds
> Row Cache  : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache  : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired   : 2.3272298419424144E-5%
> Token  : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build 
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS, 
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] 01/01: Merge branch 'cassandra-4.0' into cassandra-4.1

[jonmeredith]

This is an automated email from the ASF dual-hosted git repository.

jonmeredith pushed a commit to branch cassandra-4.1
in repository https://gitbox.apache.org/repos/asf/cassandra.git

commit 6adcff8f30f445ddd7f0aeb60d72c5a15430aefe
Merge: 426829cf57 40f9ca60f1
Author: Jon Meredith 
AuthorDate: Tue Mar 7 10:28:41 2023 -0700

Merge branch 'cassandra-4.0' into cassandra-4.1

 CHANGES.txt|   1 +
 .../db/memtable/AbstractAllocatorMemtable.java |  13 +-
 .../db/partitions/AtomicBTreePartition.java|  13 +-
 .../org/apache/cassandra/db/rows/ArrayCell.java|   2 +-
 .../org/apache/cassandra/db/rows/BTreeRow.java |   7 +-
 .../org/apache/cassandra/db/rows/BufferCell.java   |   2 +-
 .../org/apache/cassandra/db/rows/ColumnData.java   |  51 ++-
 .../cassandra/db/rows/ComplexColumnData.java   |   4 +-
 .../org/apache/cassandra/db/rows/NativeCell.java   |  19 +-
 src/java/org/apache/cassandra/db/rows/Row.java |   8 +
 .../org/apache/cassandra/utils/btree/BTree.java|  17 +-
 .../cassandra/utils/memory/MemtablePool.java   |   2 +-
 ...AtomicBTreePartitionMemtableAccountingTest.java | 421 +
 13 files changed, 525 insertions(+), 35 deletions(-)

diff --cc CHANGES.txt
index 1ca7c2f89a,f2064c098e..7c66dda361
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,13 -1,11 +1,14 @@@
 -4.0.9
 +4.1.1
 + * Fix copying of JAR of a trigger to temporary file (CASSANDRA-18264)
 + * Fix possible NoSuchFileException when removing a snapshot (CASSANDRA-18211)
 + * PaxosPrepare may add instances to the Electorate that are not in gossip 
(CASSANDRA-18194)
 + * Fix PAXOS2_COMMIT_AND_PREPARE_RSP serialisation AssertionError 
(CASSANDRA-18164)
 + * Streaming progress virtual table lock contention can trigger 
TCP_USER_TIMEOUT and fail streaming (CASSANDRA-18110)
 + * Fix perpetual load of denylist on read in cases where denylist can never 
be loaded (CASSANDRA-18116)
 +Merged from 4.0:
+  * Improve memtable allocator accounting when updating AtomicBTreePartition 
(CASSANDRA-18125)
   * Update zstd-jni to version 1.5.4-1 (CASSANDRA-18259)
   * Split and order IDEA workspace template VM_PARAMETERS (CASSANDRA-18242)
 -Merged from 3.11:
 -Merged from 3.0:
 -
 -4.0.8
   * Log warning message on aggregation queries without key or on multiple keys 
(CASSANDRA-18219)
   * Fix the output of FQL dump tool to properly separate entries 
(CASSANDRA-18215)
   * Add cache type information for maximum memory usage warning message 
(CASSANDRA-18184)
diff --cc 
src/java/org/apache/cassandra/db/memtable/AbstractAllocatorMemtable.java
index 227cc6dcc2,00..ae1251646e
mode 100644,00..100644
--- a/src/java/org/apache/cassandra/db/memtable/AbstractAllocatorMemtable.java
+++ b/src/java/org/apache/cassandra/db/memtable/AbstractAllocatorMemtable.java
@@@ -1,306 -1,0 +1,317 @@@
 +/*
 + * Licensed to the Apache Software Foundation (ASF) under one
 + * or more contributor license agreements.  See the NOTICE file
 + * distributed with this work for additional information
 + * regarding copyright ownership.  The ASF licenses this file
 + * to you under the Apache License, Version 2.0 (the
 + * "License"); you may not use this file except in compliance
 + * with the License.  You may obtain a copy of the License at
 + *
 + * http://www.apache.org/licenses/LICENSE-2.0
 + *
 + * Unless required by applicable law or agreed to in writing, software
 + * distributed under the License is distributed on an "AS IS" BASIS,
 + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 + * See the License for the specific language governing permissions and
 + * limitations under the License.
 + */
 +
 +package org.apache.cassandra.db.memtable;
 +
 +import java.util.concurrent.TimeUnit;
 +import java.util.concurrent.atomic.AtomicReference;
 +
++import com.google.common.annotations.VisibleForTesting;
 +import org.slf4j.Logger;
 +import org.slf4j.LoggerFactory;
 +
 +import org.apache.cassandra.concurrent.ImmediateExecutor;
 +import org.apache.cassandra.concurrent.ScheduledExecutors;
++import org.apache.cassandra.config.Config;
 +import org.apache.cassandra.config.DatabaseDescriptor;
 +import org.apache.cassandra.db.ClusteringComparator;
 +import org.apache.cassandra.db.ColumnFamilyStore;
 +import org.apache.cassandra.db.commitlog.CommitLogPosition;
 +import org.apache.cassandra.schema.TableMetadataRef;
 +import org.apache.cassandra.utils.Clock;
 +import org.apache.cassandra.utils.FBUtilities;
 +import org.apache.cassandra.utils.WrappedRunnable;
 +import org.apache.cassandra.utils.concurrent.AsyncPromise;
 +import org.apache.cassandra.utils.concurrent.Future;
 +import org.apache.cassandra.utils.concurrent.OpOrder;
 +import org.apache.cassandra.utils.concurrent.Promise;
 +import org.apache.cassandra.utils.memory.HeapPool;
 +import org.apache.cassandra.utils.memory.MemtableAllocator;
 +import org.apache.cassandra.utils.memory.MemtableCleaner;
 +import 

[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk

[jonmeredith]

This is an automated email from the ASF dual-hosted git repository.

jonmeredith pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git

commit 0bed1967fdd1caeb2bbc38645c2a0cb7e728725c
Merge: 7ca806c60a 6adcff8f30
Author: Jon Meredith 
AuthorDate: Tue Mar 7 10:41:05 2023 -0700

Merge branch 'cassandra-4.1' into trunk

 CHANGES.txt|   1 +
 .../db/memtable/AbstractAllocatorMemtable.java |  12 +-
 .../db/partitions/AtomicBTreePartition.java|  19 -
 .../db/partitions/BTreePartitionUpdater.java   |  14 +-
 .../org/apache/cassandra/db/rows/ArrayCell.java|   2 +-
 .../org/apache/cassandra/db/rows/BufferCell.java   |   2 +-
 .../org/apache/cassandra/db/rows/ColumnData.java   |  51 ++-
 .../cassandra/db/rows/ComplexColumnData.java   |   4 +-
 .../org/apache/cassandra/db/rows/NativeCell.java   |  19 +-
 .../org/apache/cassandra/utils/btree/BTree.java|  17 +-
 .../cassandra/utils/memory/MemtablePool.java   |   2 +-
 ...AtomicBTreePartitionMemtableAccountingTest.java | 421 +
 12 files changed, 511 insertions(+), 53 deletions(-)

diff --cc 
src/java/org/apache/cassandra/db/memtable/AbstractAllocatorMemtable.java
index c39b561a16,ae1251646e..8526dace39
--- a/src/java/org/apache/cassandra/db/memtable/AbstractAllocatorMemtable.java
+++ b/src/java/org/apache/cassandra/db/memtable/AbstractAllocatorMemtable.java
@@@ -73,9 -67,9 +74,10 @@@ public abstract class AbstractAllocator
  
  private final long creationNano = Clock.Global.nanoTime();
  
 -private static MemtablePool createMemtableAllocatorPool()
 +@VisibleForTesting
 +static MemtablePool createMemtableAllocatorPool()
  {
+ Config.MemtableAllocationType allocationType = 
DatabaseDescriptor.getMemtableAllocationType();
  long heapLimit = DatabaseDescriptor.getMemtableHeapSpaceInMiB() << 20;
  long offHeapLimit = DatabaseDescriptor.getMemtableOffheapSpaceInMiB() 
<< 20;
  float memtableCleanupThreshold = 
DatabaseDescriptor.getMemtableCleanupThreshold();
diff --cc src/java/org/apache/cassandra/db/partitions/AtomicBTreePartition.java
index 6cbb985f51,986e70774f..c9035befbd
--- a/src/java/org/apache/cassandra/db/partitions/AtomicBTreePartition.java
+++ b/src/java/org/apache/cassandra/db/partitions/AtomicBTreePartition.java
@@@ -18,8 -18,10 +18,7 @@@
  package org.apache.cassandra.db.partitions;
  
  import java.nio.ByteBuffer;
 -import java.util.ArrayList;
  import java.util.Iterator;
 -import java.util.List;
--import java.util.NavigableSet;
  import java.util.concurrent.atomic.AtomicIntegerFieldUpdater;
  import java.util.concurrent.atomic.AtomicReferenceFieldUpdater;
  
@@@ -217,26 -231,26 +216,8 @@@ public final class AtomicBTreePartitio
  return allocator.ensureOnHeap().applyToRow(super.lastRow());
  }
  
- @Override
- public UnfilteredRowIterator unfilteredIterator(ColumnFilter selection, 
Slices slices, boolean reversed)
- {
- return 
allocator.ensureOnHeap().applyToPartition(super.unfilteredIterator(selection, 
slices, reversed));
- }
- 
- @Override
- public UnfilteredRowIterator unfilteredIterator(ColumnFilter selection, 
NavigableSet> clusteringsInQueryOrder, boolean reversed)
- {
- return 
allocator.ensureOnHeap().applyToPartition(super.unfilteredIterator(selection, 
clusteringsInQueryOrder, reversed));
- }
- 
- @Override
- public UnfilteredRowIterator unfilteredIterator()
- {
- return 
allocator.ensureOnHeap().applyToPartition(super.unfilteredIterator());
- }
- 
  @Override
 -public UnfilteredRowIterator unfilteredIterator(ColumnFilter selection, 
Slices slices, boolean reversed)
 -{
 -return 
allocator.ensureOnHeap().applyToPartition(super.unfilteredIterator(selection, 
slices, reversed));
 -}
 -
 -@Override
 -public UnfilteredRowIterator unfilteredIterator(ColumnFilter selection, 
NavigableSet> clusteringsInQueryOrder, boolean reversed)
 -{
 -return 
allocator.ensureOnHeap().applyToPartition(super.unfilteredIterator(selection, 
clusteringsInQueryOrder, reversed));
 -}
 -
 -@Override
 -public UnfilteredRowIterator unfilteredIterator()
 -{
 -return 
allocator.ensureOnHeap().applyToPartition(super.unfilteredIterator());
 -}
 -
 -@Override
 -public UnfilteredRowIterator unfilteredIterator(Holder current, 
ColumnFilter selection, Slices slices, boolean reversed)
 +public UnfilteredRowIterator unfilteredIterator(BTreePartitionData 
current, ColumnFilter selection, Slices slices, boolean reversed)
  {
  return 
allocator.ensureOnHeap().applyToPartition(super.unfilteredIterator(current, 
selection, slices, reversed));
  }
diff --cc src/java/org/apache/cassandra/db/partitions/BTreePartitionUpdater.java
index 7c09ae81f7,00..023019242d
mode 100644,00..100644
--- 

[cassandra] branch trunk updated (7ca806c60a -> 0bed1967fd)

[jonmeredith]

This is an automated email from the ASF dual-hosted git repository.

jonmeredith pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git


from 7ca806c60a Change trunk from 4.2 to 5.0
 new 40f9ca60f1 Improve memtable allocator accounting when updating 
AtomicBTreePartition
 new 6adcff8f30 Merge branch 'cassandra-4.0' into cassandra-4.1
 new 0bed1967fd Merge branch 'cassandra-4.1' into trunk

The 3 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 CHANGES.txt|   1 +
 .../db/memtable/AbstractAllocatorMemtable.java |  12 +-
 .../db/partitions/AtomicBTreePartition.java|  19 -
 .../db/partitions/BTreePartitionUpdater.java   |  14 +-
 .../org/apache/cassandra/db/rows/ArrayCell.java|   2 +-
 .../org/apache/cassandra/db/rows/BufferCell.java   |   2 +-
 .../org/apache/cassandra/db/rows/ColumnData.java   |  51 ++-
 .../cassandra/db/rows/ComplexColumnData.java   |   4 +-
 .../org/apache/cassandra/db/rows/NativeCell.java   |  19 +-
 .../org/apache/cassandra/utils/btree/BTree.java|  17 +-
 .../cassandra/utils/memory/MemtablePool.java   |   2 +-
 ...AtomicBTreePartitionMemtableAccountingTest.java | 421 +
 12 files changed, 511 insertions(+), 53 deletions(-)
 create mode 100644 
test/unit/org/apache/cassandra/db/partitions/AtomicBTreePartitionMemtableAccountingTest.java


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] branch cassandra-4.0 updated: Improve memtable allocator accounting when updating AtomicBTreePartition

[jonmeredith]

This is an automated email from the ASF dual-hosted git repository.

jonmeredith pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/cassandra-4.0 by this push:
 new 40f9ca60f1 Improve memtable allocator accounting when updating 
AtomicBTreePartition
40f9ca60f1 is described below

commit 40f9ca60f103783aa481bc9a91b92fd55b4ea625
Author: Benedict Elliott Smith 
AuthorDate: Wed Mar 1 19:08:20 2023 -0700

Improve memtable allocator accounting when updating AtomicBTreePartition

patch by Benedict Elliott Smith; reviewed by Benjamin Lerer, Jon Meredith 
for CASSANDRA-18125
---
 CHANGES.txt|   1 +
 src/java/org/apache/cassandra/db/Memtable.java |  16 +-
 .../db/partitions/AtomicBTreePartition.java|  13 +-
 .../org/apache/cassandra/db/rows/ArrayCell.java|   2 +-
 .../org/apache/cassandra/db/rows/BTreeRow.java |   7 +-
 .../org/apache/cassandra/db/rows/BufferCell.java   |   2 +-
 .../org/apache/cassandra/db/rows/ColumnData.java   |  49 ++-
 .../cassandra/db/rows/ComplexColumnData.java   |   2 +-
 .../org/apache/cassandra/db/rows/NativeCell.java   |  18 +-
 src/java/org/apache/cassandra/db/rows/Row.java |   8 +
 .../org/apache/cassandra/utils/btree/BTree.java|  15 +-
 .../cassandra/utils/memory/MemtablePool.java   |   2 +-
 ...AtomicBTreePartitionMemtableAccountingTest.java | 422 +
 13 files changed, 522 insertions(+), 35 deletions(-)

diff --git a/CHANGES.txt b/CHANGES.txt
index 6dd05a34a1..f2064c098e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0.9
+ * Improve memtable allocator accounting when updating AtomicBTreePartition 
(CASSANDRA-18125)
  * Update zstd-jni to version 1.5.4-1 (CASSANDRA-18259)
  * Split and order IDEA workspace template VM_PARAMETERS (CASSANDRA-18242)
 Merged from 3.11:
diff --git a/src/java/org/apache/cassandra/db/Memtable.java 
b/src/java/org/apache/cassandra/db/Memtable.java
index c6eb68ea57..b74ac5f63c 100644
--- a/src/java/org/apache/cassandra/db/Memtable.java
+++ b/src/java/org/apache/cassandra/db/Memtable.java
@@ -37,6 +37,7 @@ import com.google.common.base.Throwables;
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
 
+import org.apache.cassandra.config.Config;
 import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.db.commitlog.CommitLog;
 import org.apache.cassandra.db.commitlog.CommitLogPosition;
@@ -80,16 +81,25 @@ public class Memtable implements Comparable
 {
 private static final Logger logger = 
LoggerFactory.getLogger(Memtable.class);
 
-public static final MemtablePool MEMORY_POOL = 
createMemtableAllocatorPool();
+public static final MemtablePool MEMORY_POOL = 
createMemtableAllocatorPoolInternal();
 public static final long NO_MIN_TIMESTAMP = -1;
 
-private static MemtablePool createMemtableAllocatorPool()
+private static MemtablePool createMemtableAllocatorPoolInternal()
 {
+Config.MemtableAllocationType allocationType = 
DatabaseDescriptor.getMemtableAllocationType();
 long heapLimit = DatabaseDescriptor.getMemtableHeapSpaceInMb() << 20;
 long offHeapLimit = DatabaseDescriptor.getMemtableOffheapSpaceInMb() 
<< 20;
 final float cleaningThreshold = 
DatabaseDescriptor.getMemtableCleanupThreshold();
 final MemtableCleaner cleaner = 
ColumnFamilyStore::flushLargestMemtable;
-switch (DatabaseDescriptor.getMemtableAllocationType())
+return createMemtableAllocatorPoolInternal(allocationType, heapLimit, 
offHeapLimit, cleaningThreshold, cleaner);
+}
+
+@VisibleForTesting
+public static MemtablePool 
createMemtableAllocatorPoolInternal(Config.MemtableAllocationType 
allocationType,
+   long 
heapLimit, long offHeapLimit,
+   float 
cleaningThreshold, MemtableCleaner cleaner)
+{
+switch (allocationType)
 {
 case unslabbed_heap_buffers:
 return new HeapPool(heapLimit, cleaningThreshold, cleaner);
diff --git 
a/src/java/org/apache/cassandra/db/partitions/AtomicBTreePartition.java 
b/src/java/org/apache/cassandra/db/partitions/AtomicBTreePartition.java
index 1c0ad60cc6..7b275d0fca 100644
--- a/src/java/org/apache/cassandra/db/partitions/AtomicBTreePartition.java
+++ b/src/java/org/apache/cassandra/db/partitions/AtomicBTreePartition.java
@@ -375,7 +375,7 @@ public final class AtomicBTreePartition extends 
AbstractBTreePartition
 indexer.onInserted(insert);
 
 this.dataSize += data.dataSize();
-onAllocatedOnHeap(data.unsharedHeapSizeExcludingData());
+this.heapSize += data.unsharedHeapSizeExcludingData();
 if (inserted == null)
 inserted = new 

[cassandra] branch cassandra-4.1 updated (426829cf57 -> 6adcff8f30)

[jonmeredith]

This is an automated email from the ASF dual-hosted git repository.

jonmeredith pushed a change to branch cassandra-4.1
in repository https://gitbox.apache.org/repos/asf/cassandra.git


from 426829cf57 Merge branch 'cassandra-4.0' into cassandra-4.1
 new 40f9ca60f1 Improve memtable allocator accounting when updating 
AtomicBTreePartition
 new 6adcff8f30 Merge branch 'cassandra-4.0' into cassandra-4.1

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:
 CHANGES.txt|   1 +
 .../db/memtable/AbstractAllocatorMemtable.java |  13 +-
 .../db/partitions/AtomicBTreePartition.java|  13 +-
 .../org/apache/cassandra/db/rows/ArrayCell.java|   2 +-
 .../org/apache/cassandra/db/rows/BTreeRow.java |   7 +-
 .../org/apache/cassandra/db/rows/BufferCell.java   |   2 +-
 .../org/apache/cassandra/db/rows/ColumnData.java   |  51 ++-
 .../cassandra/db/rows/ComplexColumnData.java   |   4 +-
 .../org/apache/cassandra/db/rows/NativeCell.java   |  19 +-
 src/java/org/apache/cassandra/db/rows/Row.java |   8 +
 .../org/apache/cassandra/utils/btree/BTree.java|  17 +-
 .../cassandra/utils/memory/MemtablePool.java   |   2 +-
 ...AtomicBTreePartitionMemtableAccountingTest.java | 421 +
 13 files changed, 525 insertions(+), 35 deletions(-)
 create mode 100644 
test/unit/org/apache/cassandra/db/partitions/AtomicBTreePartitionMemtableAccountingTest.java


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-18299) Add support for prepared statements for accord transactions

[Caleb Rackliffe (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697549#comment-17697549
 ] 

Caleb Rackliffe commented on CASSANDRA-18299:
-

+1

> Add support for prepared statements for accord transactions
> ---
>
> Key: CASSANDRA-18299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18299
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Accord
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 5.x
>
>  Time Spent: 5h 50m
>  Remaining Estimate: 0h
>
> When you try to prepare an accord transaction we get a NullPointerException 
> in method 
> org.apache.cassandra.cql3.statements.QualifiedStatement#isFullyQualified. 
> This is due to TransactionStatement extending but not overriding all the 
> methods (and setting name to null).



--
This message was sent by Atlassian Jira
(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-18304) hinted_handoff_enabled=false is not honored

[Paulo Motta (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697501#comment-17697501
 ] 

Paulo Motta commented on CASSANDRA-18304:
-

Thanks! 4.1 build seems to be fine, trunk skipped some tests.. rebased and 
resubmitted but still queued

> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on 
> timeout from 
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
>  to 
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
>  but it no longer checks if {{CallbackInfo.shouldHint}} which checks for 
> {{StorageProxy.shouldHint}} which ultimately checks if 
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail 
> intermittently.



--
This message was sent by Atlassian Jira
(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-18294) die disk failure policy will not kill jvm as documented

[Brandon Williams (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697499#comment-17697499
 ] 

Brandon Williams commented on CASSANDRA-18294:
--

I see, and think it makes sense to be explicit with 'die' too.  I think we're 
ready for PRs for the other branches.

> die disk failure policy will not kill jvm as documented
> ---
>
> Key: CASSANDRA-18294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18294
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x, 4.0.x, 4.1.x
>
>
> After Cassandra has successfully starts up with disk_failure_policy die, when 
> encounter a file system error, Cassandra server will only throw exception 
> instead of shut down gossip and client transport and kill JVM. Document: 
> [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#disk_failure_policy]
>  
> The reason for this is the default FS error handler is not handing policy die 
> correctly. Instead of shutting down gossip and native transport, it throws an 
> error.
>  
> The JVMStabilityInspectorTest is passing because the error handler is not set 
> so no exception is thrown.



--
This message was sent by Atlassian Jira
(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-18304) hinted_handoff_enabled=false is not honored

[Aleksey Yeschenko (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697497#comment-17697497
 ] 

Aleksey Yeschenko commented on CASSANDRA-18304:
---

Sure, let me see.

> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on 
> timeout from 
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
>  to 
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
>  but it no longer checks if {{CallbackInfo.shouldHint}} which checks for 
> {{StorageProxy.shouldHint}} which ultimately checks if 
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail 
> intermittently.



--
This message was sent by Atlassian Jira
(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-18294) die disk failure policy will not kill jvm as documented

[Stefan Miklosovic (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697494#comment-17697494
 ] 

Stefan Miklosovic commented on CASSANDRA-18294:
---

[~brandon.williams] as [~maxwellguo] mentioned here (1) it seems we are OK 
already?

added "die" is there so we would not throw IllegalStateException as it would 
reach "default" in these switches which this ticket solves.

(1) https://github.com/apache/cassandra/pull/2189/files#r1122779198

> die disk failure policy will not kill jvm as documented
> ---
>
> Key: CASSANDRA-18294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18294
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x, 4.0.x, 4.1.x
>
>
> After Cassandra has successfully starts up with disk_failure_policy die, when 
> encounter a file system error, Cassandra server will only throw exception 
> instead of shut down gossip and client transport and kill JVM. Document: 
> [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#disk_failure_policy]
>  
> The reason for this is the default FS error handler is not handing policy die 
> correctly. Instead of shutting down gossip and native transport, it throws an 
> error.
>  
> The JVMStabilityInspectorTest is passing because the error handler is not set 
> so no exception is thrown.



--
This message was sent by Atlassian Jira
(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-18296) tablehistograms add filter for data table and system table

[Brandon Williams (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697488#comment-17697488
 ] 

Brandon Williams commented on CASSANDRA-18296:
--

I see, so that breaks compatibility with how it was done previously, and this 
is a user facing tool, so it is probably best to seek (lazy) consensus on the 
ML.  I don't forsee any problem with it though.

>  tablehistograms add filter for data table and system table
> ---
>
> Key: CASSANDRA-18296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18296
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: maxwellguo
>Assignee: maxwellguo
>Priority: Normal
>
> Add some options for nodetool tablehistograms to filter the output 
> of System tables and data tables.
> As we know if we nodetool tablehistograms all tables will be output ,but 
> system table 's number are too much.
> Add options to filter only output data tables or system tables, together with 
> the already exist ks.tb lists, the output options are just fine.
> It seems that tablestats got the -i option that can ignore keyspace, just add 
> this first, and then to see wether this can meet our needs



--
This message was sent by Atlassian Jira
(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-17971) Opcodes.ASM7 to be updated when JDK17 support is added for Cassandra

[Michael Semb Wever (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-17971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697484#comment-17697484
 ] 

Michael Semb Wever commented on CASSANDRA-17971:


rebased, same links as above.

> Opcodes.ASM7 to be updated when JDK17 support is added for Cassandra
> 
>
> Key: CASSANDRA-17971
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17971
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, Dependencies, Feature/UDF
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> In CASSANDRA-17873 we updated the ASM opcode inconsistencies for JDK11, we 
> need to revise it again before we switch fro jdk8&11 to jdk11&17



--
This message was sent by Atlassian Jira
(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-18304) hinted_handoff_enabled=false is not honored

[Paulo Motta (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697176#comment-17697176
 ] 

Paulo Motta edited comment on CASSANDRA-18304 at 3/7/23 3:22 PM:
-

Added dtest to reproduce issue.

Fix is to filter endpoints on with {{StorageProxy::shouldHint}} on 
{{{}StorageProxy.submitHint{}}}, not sure if this has any unintended 
consequences.

Can you take a look [~benedict] [~aleksey] ?
 * [4.1 PR|https://github.com/apache/cassandra/pull/2196]
 * [trunk PR|https://github.com/apache/cassandra/pull/2197]

 * 4.1 CI: 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2327/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2327/pipeline]
 * trunk CI: 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2333/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2333/pipeline]


was (Author: paulo):
Added dtest to reproduce issue.

Fix is to filter endpoints on with {{StorageProxy::shouldHint}} on 
{{{}StorageProxy.submitHint{}}}, not sure if this has any unintended 
consequences.

Can you take a look [~benedict] [~aleksey] ?
 * [4.1 PR|https://github.com/apache/cassandra/pull/2196]
 * [trunk PR|https://github.com/apache/cassandra/pull/2197]

 * 4.1 CI: 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2327/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2327/pipeline]
 * trunk CI: 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2328/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2328/pipeline]

> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on 
> timeout from 
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
>  to 
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
>  but it no longer checks if {{CallbackInfo.shouldHint}} which checks for 
> {{StorageProxy.shouldHint}} which ultimately checks if 
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail 
> intermittently.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra-website] branch asf-staging updated (bbac01da4 -> 62913562a)

[git-site-role]

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 bbac01da4 generate docs for c4206294
 new 62913562a generate docs for c4206294

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   (bbac01da4)
\
 N -- N -- N   refs/heads/asf-staging (62913562a)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 content/search-index.js |   2 +-
 site-ui/build/ui-bundle.zip | Bin 4796442 -> 4796442 bytes
 2 files changed, 1 insertion(+), 1 deletion(-)


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy

[Michael Semb Wever (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697473#comment-17697473
 ] 

Michael Semb Wever commented on CASSANDRA-18106:


bq. Do we need anything else on this ticket for CCM?

No, it's good for me.

> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.x
>
> Attachments: Screenshot 2023-03-03 at 09.24.50.png
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was 
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need 
> to revise how we detect JDK versions in CCM and whether it is correct. To the 
> best of my knowledge there are certain tests in the repo around that and they 
> pass so my guess is we need to revise just the strategy and maybe document it 
> explicitly or consider if we want any changes to be applied. Also, we need to 
> be careful with breaking changes. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy

[Brandon Williams (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697453#comment-17697453
 ] 

Brandon Williams commented on CASSANDRA-18106:
--

Do we need anything else on this ticket for CCM?  I think it would make sense 
to get this committed sooner than later so that we don't have to float my CCM 
dependency to do further testing for j17.

> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.x
>
> Attachments: Screenshot 2023-03-03 at 09.24.50.png
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was 
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need 
> to revise how we detect JDK versions in CCM and whether it is correct. To the 
> best of my knowledge there are certain tests in the repo around that and they 
> pass so my guess is we need to revise just the strategy and maybe document it 
> explicitly or consider if we want any changes to be applied. Also, we need to 
> be careful with breaking changes. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression

[Claude Warren (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697448#comment-17697448
 ] 

Claude Warren commented on CASSANDRA-12937:
---

Created pull request: https://github.com/apache/cassandra/pull/2199

> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
>  Labels: AdventCalendar2021, lhf
>
> In many situations the choice of compression for sstables is more relevant to 
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable 
> compression that new tables will inherit (instead of the defaults found in 
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly 
> compression (btrfs, zfs) or specific disk configurations or even specific C* 
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying 
> the field required for defining the default compression parameters. In 
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for 
> the default compression. This field should be initialized in 
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where 
> {{CompressionParams.DEFAULT}} was used the code should call 
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some 
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test 
> that the table schema use the new default when a new table is created (see 
> CreateTest for some example).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Assigned] (CASSANDRA-12937) Default setting (yaml) for SSTable compression

[Claude Warren (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claude Warren reassigned CASSANDRA-12937:
-

Assignee: Claude Warren

> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
>  Labels: AdventCalendar2021, lhf
>
> In many situations the choice of compression for sstables is more relevant to 
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable 
> compression that new tables will inherit (instead of the defaults found in 
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly 
> compression (btrfs, zfs) or specific disk configurations or even specific C* 
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying 
> the field required for defining the default compression parameters. In 
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for 
> the default compression. This field should be initialized in 
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where 
> {{CompressionParams.DEFAULT}} was used the code should call 
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some 
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test 
> that the table schema use the new default when a new table is created (see 
> CreateTest for some example).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-18125) Improve memtable allocator accounting when updating AtomicBTreePartition

[Benjamin Lerer (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697428#comment-17697428
 ] 

Benjamin Lerer commented on CASSANDRA-18125:


The patches looks good to me. Thanks [~jonmeredith], [~benedict].

> Improve memtable allocator accounting when updating AtomicBTreePartition
> 
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Memtable
>Reporter: Nicolas Henneaux
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the 
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon 
> uncaughtException - Exception in thread 
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
>   at 
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
>   at 
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
>   at 
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
>   at 
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
>   at 
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
>   at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> {code} 
> {code}
> $ nodetool info
> ID : 
> Gossip active  : true
> Native Transport active: true
> Load   : 204.67 GiB
> Generation No  : 1670343179
> Uptime (seconds)   : 1110514
> Heap Memory (MB)   : 7218.07 / 24576.00
> Off Heap Memory (MB)   : 784.06
> Data Center: par
> Rack   : e1
> Exceptions : 1
> Key Cache  : entries 802712, size 100 MiB, capacity 100 MiB, 
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period 
> in seconds
> Row Cache  : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache  : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired   : 2.3272298419424144E-5%
> Token  : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build 
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS, 
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {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-18125) Improve memtable allocator accounting when updating AtomicBTreePartition

[Benjamin Lerer (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Lerer updated CASSANDRA-18125:
---
Status: Ready to Commit  (was: Review In Progress)

> Improve memtable allocator accounting when updating AtomicBTreePartition
> 
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Memtable
>Reporter: Nicolas Henneaux
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the 
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon 
> uncaughtException - Exception in thread 
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
>   at 
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
>   at 
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
>   at 
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
>   at 
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
>   at 
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
>   at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> {code} 
> {code}
> $ nodetool info
> ID : 
> Gossip active  : true
> Native Transport active: true
> Load   : 204.67 GiB
> Generation No  : 1670343179
> Uptime (seconds)   : 1110514
> Heap Memory (MB)   : 7218.07 / 24576.00
> Off Heap Memory (MB)   : 784.06
> Data Center: par
> Rack   : e1
> Exceptions : 1
> Key Cache  : entries 802712, size 100 MiB, capacity 100 MiB, 
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period 
> in seconds
> Row Cache  : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache  : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired   : 2.3272298419424144E-5%
> Token  : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build 
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS, 
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {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-17973) Change trunk 4.2 to 5.0

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17973:
---
Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

> Change trunk 4.2 to 5.0
> ---
>
> Key: CASSANDRA-17973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17973
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.0
>
>
> 1. Bump trunk's version 
> {code}
> git switch trunk
> # increment version to 5.0
> edit build.xml debian/changelog CHANGES.txt NEWS.txt README.asc
> {code}
> 2. Update jvm-dtest supported upgrade paths
>  - 
> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L85-L96
>  
> 3. Update `4.2` to jira versions
> Change `4.2` to `5.0`
> Change `4.x` to `5.x`
> 4. Update docker images to include cassandra-5.0
> (Docker images also need to be deployed)
> 5. Add pipeline to ci-cassandra
> https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51
> 6. Add dtest version and upgrade paths
>  - 
> https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py
>  - https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374
>  - 
> https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L41
> 7. Update how_to_commit documentation
> https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra-website] branch asf-staging updated (4d53fdb57 -> bbac01da4)

[git-site-role]

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 4d53fdb57 generate docs for ba88b347
 add c4206294f Update how_to_commit.adoc for current branches (4.0, 4.1, 
trunk)
 new bbac01da4 generate docs for c4206294

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   (4d53fdb57)
\
 N -- N -- N   refs/heads/asf-staging (bbac01da4)

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/_/development/how_to_commit.html   | 118 ++---
 content/_/development/index.html   | 118 ++---
 content/search-index.js|   2 +-
 .../ROOT/pages/development/how_to_commit.adoc  |  80 ++
 site-ui/build/ui-bundle.zip| Bin 4796442 -> 4796442 
bytes
 5 files changed, 91 insertions(+), 227 deletions(-)


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-17232) org.apache.cassandra.db.commitlog.GroupCommitLogTest tests failing on trunk

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17232:
---
Fix Version/s: 5.0

> org.apache.cassandra.db.commitlog.GroupCommitLogTest tests failing on trunk
> ---
>
> Key: CASSANDRA-17232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17232
> Project: Cassandra
>  Issue Type: Bug
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1-beta1, 5.0, 4.x
>
>
> I saw 
> [here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1344/testReport/junit/org.apache.cassandra.db.commitlog/GroupCommitLogTest/replayWithDiscard_3_/]
>  and 
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/881/testReport/junit/org.apache.cassandra.db.commitlog/GroupCommitLogTest/replayWithDiscard_3__compression_3/]
>  the same assertion failure:
>  
> {code:java}
> org.apache.cassandra.db.commitlog.GroupCommitLogTest.replayWithDiscard[3]
> Error Message
> expected:<204> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<204> but was:<0> at 
> org.apache.cassandra.db.commitlog.CommitLogTest.replayWithDiscard(CommitLogTest.java:883)
> {code}
>  
> Then I find that there are many other tests from GroupCommitLogTest failing 
> with No such file found.
> Example:
> https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1344/



--
This message was sent by Atlassian Jira
(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-17583) Fix flaky test - org.apache.cassandra.distributed.test.MessageForwardingTest.mutationsForwardedToAllReplicasTest

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17583:
---
Fix Version/s: 5.0

> Fix flaky test - 
> org.apache.cassandra.distributed.test.MessageForwardingTest.mutationsForwardedToAllReplicasTest
> 
>
> Key: CASSANDRA-17583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17583
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Brandon Williams
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 3.0.28, 3.11.14, 4.0.5, 4.1-beta1, 5.0, 4.x
>
>
> h3. Error Message
> /127.0.0.3 appending to commitlog traces expected:<100> but was:<98>
> h3. Stacktrace
> {noformat}
> junit.framework.AssertionFailedError: /127.0.0.3 appending to commitlog 
> traces expected:<100> but was:<98> at 
> org.apache.cassandra.distributed.test.MessageForwardingTest.lambda$mutationsForwardedToAllReplicasTest$8(MessageForwardingTest.java:92)
>  at java.base/java.util.HashMap.forEach(HashMap.java:1336) at 
> org.apache.cassandra.distributed.test.MessageForwardingTest.mutationsForwardedToAllReplicasTest(MessageForwardingTest.java:91)
>  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)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-17969) Keep sstable level when streaming for decommission and move

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17969:
---
Fix Version/s: 5.0

> Keep sstable level when streaming for decommission and move
> ---
>
> Key: CASSANDRA-17969
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17969
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Consistency/Streaming
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.0, 4.x
>
>
> We currently keep the sstable level when streaming for bootstrap and rebuild, 
> we should do the same for decommission and move



--
This message was sent by Atlassian Jira
(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-17422) Test Failure: org.apache.cassandra.net.OutboundMessageQueueTest.testRemove-cdc

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17422:
---
Fix Version/s: 5.0

> Test Failure: org.apache.cassandra.net.OutboundMessageQueueTest.testRemove-cdc
> --
>
> Key: CASSANDRA-17422
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17422
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.6, 4.1-beta1, 5.0, 4.x
>
> Attachments: CASSANDRA-17422.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Branch: 4.0
> https://ci-cassandra.apache.org/job/Cassandra-4.0/350/testReport/org.apache.cassandra.net/OutboundMessageQueueTest/testRemove_cdc/
> {code}
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.net.OutboundMessageQueueTest.testRemove(OutboundMessageQueueTest.java:91)
>   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)
> {code}
> Failure: 1 of 3



--
This message was sent by Atlassian Jira
(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-17729) Raise test timeouts

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17729:
---
Fix Version/s: 5.0

> Raise test timeouts
> ---
>
> Key: CASSANDRA-17729
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17729
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1-beta1, 5.0, 4.x
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We have seen for some time now junits timeout frequently on jenkins. This is 
> probably down to it being a very loaded env. On circle we don't observe that 
> behavior probably bc it's not so loaded.
> The question is whether it is time to raise timeouts as they might be hiding 
> legit failures. As en experiment I raised timeouts in a branch and ran 
> jenkins against it. What I see is that the last 4.1 run had 14 failures out 
> of which 12 were timeouts. Increasing timeouts reveals what looks to be 9 
> legit failures where 2 are timeouts that probably need to be investigated.



--
This message was sent by Atlassian Jira
(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-17636) Test Failure: org.apache.cassandra.distributed.upgrade.MixedModeFrom3ReplicationTest.testSimpleStrategy

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17636:
---
Fix Version/s: 5.0

> Test Failure: 
> org.apache.cassandra.distributed.upgrade.MixedModeFrom3ReplicationTest.testSimpleStrategy
> ---
>
> Key: CASSANDRA-17636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17636
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Andres de la Peña
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.1-beta1, 4.1.x, 5.0, 4.x
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> The upgrade in-JVM dtest 
> {{org.apache.cassandra.distributed.upgrade.MixedModeFrom3ReplicationTest.testSimpleStrategy}}
>  is flaky on 4.1 and trunk.
> Jenkins failure:
> https://ci-cassandra.apache.org/job/Cassandra-4.1/21/testReport/org.apache.cassandra.distributed.upgrade/MixedModeFrom3UnloggedBatchTest/testSimpleStrategy/
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1149/testReport/org.apache.cassandra.distributed.upgrade/MixedModeFrom3ReplicationTest/testSimpleStrategy_2/
> Circle failure:
> https://app.circleci.com/pipelines/github/adelapena/cassandra/1564/workflows/e8dbd50a-d574-4ef8-a741-795a93cd3e85/jobs/16725
> Error Message:
> {code}
> Uncaught exceptions were thrown during test
> {code}
> Stacktrace:
> {code}
> org.apache.cassandra.distributed.shared.ShutdownException: Uncaught 
> exceptions were thrown during test
>   at 
> org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:1056)
>   at 
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1042)
>   at 
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:239)
>   at 
> org.apache.cassandra.distributed.upgrade.MixedModeBatchTestBase.testSimpleStrategy(MixedModeBatchTestBase.java:78)
>   at 
> org.apache.cassandra.distributed.upgrade.MixedModeBatchTestBase.testSimpleStrategy(MixedModeBatchTestBase.java:48)
>   at 
> org.apache.cassandra.distributed.upgrade.MixedModeFrom3UnloggedBatchTest.testSimpleStrategy(MixedModeFrom3UnloggedBatchTest.java:36)
>   Suppressed: java.lang.RuntimeException: java.lang.AssertionError
>   at 
> org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
>   at 
> org.apache.cassandra.distributed.impl.Instance.lambda$null$6(Instance.java:495)
>   at 
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:124)
>   at 
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:120)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.lang.Thread.run(Thread.java:748)
>   Caused by: java.lang.AssertionError
>   at 
> org.apache.cassandra.locator.TokenMetadata.firstTokenIndex(TokenMetadata.java:1171)
>   at 
> org.apache.cassandra.locator.TokenMetadata.firstToken(TokenMetadata.java:1185)
>   at 
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:95)
>   at 
> org.apache.cassandra.locator.AbstractReplicationStrategy.getLocalReplicaFor(AbstractReplicationStrategy.java:111)
>   at 
> org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:108)
>   at 
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:50)
>   at 
> org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
>   at 
> org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
>   Suppressed: java.lang.RuntimeException: java.lang.AssertionError
>   at 
> org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
>   at 
> org.apache.cassandra.distributed.impl.Instance.lambda$null$6(Instance.java:495)
>   at 
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:124)
>   at 
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:120)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.lang.Thread.run(Thread.java:748)
>   Caused by: java.lang.AssertionError
>   at 
> org.apache.cassandra.locator.TokenMetadata.firstTokenIndex(TokenMetadata.java:1171)
>   at 
> org.apache.cassandra.locator.TokenMetadata.firstToken(TokenMetadata.java:1185)
>   at 
> 

[jira] [Updated] (CASSANDRA-16679) HintedHandoffAddRemoveNodesTest is failing

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-16679:
---
Fix Version/s: 5.0

> HintedHandoffAddRemoveNodesTest is failing
> --
>
> Key: CASSANDRA-16679
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16679
> Project: Cassandra
>  Issue Type: Bug
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta1, 5.0, 4.x
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.distributed.test/HintedHandoffAddRemoveNodesTest/shouldStreamHintsDuringDecommission/
> Java 8
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/888e47fb-e432-47f2-97df-c34a0d33753a/jobs/4104]
>  
> and Java 11
>  
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/ce0f0690-e488-4b5b-ab82-ce92a2f336d8/jobs/4105]



--
This message was sent by Atlassian Jira
(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-17740) BulkLoader tool initializes schema unnecessarily via streaming

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17740:
---
Fix Version/s: 5.0

> BulkLoader tool initializes schema unnecessarily via streaming
> --
>
> Key: CASSANDRA-17740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17740
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/bulk load
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1-beta1, 5.0, 4.x
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Changes to streaming setup code for CASSANDRA-17663 mean that {{BulkLoader}} 
> initializes the schema/system keyspace, which is not what we want in a tool. 
> Initialization is due to a call to {{SystemKeyspace.getPreferredIP}} from the 
> {{BulkLoader}} when it starts to transmit the SSTables from the bulk loader 
> to the Cassandra instance.
> {noformat}
> getPreferredIP:1063, SystemKeyspace (org.apache.cassandra.db)
> sendMessage:213, StreamingMultiplexedChannel 
> (org.apache.cassandra.streaming.async)
> sendControlMessage:191, StreamingMultiplexedChannel 
> (org.apache.cassandra.streaming.async)
> sendControlMessage:1033, StreamSession (org.apache.cassandra.streaming)
> startStreamingFiles:1257, StreamSession (org.apache.cassandra.streaming)
> prepareSynAck:802, StreamSession (org.apache.cassandra.streaming)
> messageReceived:622, StreamSession (org.apache.cassandra.streaming)
> run:76, StreamDeserializingTask (org.apache.cassandra.streaming)
> run:30, FastThreadLocalRunnable (io.netty.util.concurrent)
> run:748, Thread (java.lang)
> {noformat}
> The existing {{BulkLoaderTest}} fails to detect this as it doesn't actually 
> connect to anything so does not initialize streaming.
> Affects 4.1 and trunk, and may affect 4.0, although the 4.0 patch for 
> CASSANDRA-17663 is different than 4.1+, and may require different mitigation.



--
This message was sent by Atlassian Jira
(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-17804) AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically on missing stdout contents

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17804:
---
Fix Version/s: 5.0

> AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically 
> on missing stdout contents
> ---
>
> Key: CASSANDRA-17804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17804
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Snapshots
>Reporter: Caleb Rackliffe
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1-beta1, 5.0, 4.x
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> See 
> [https://app.circleci.com/pipelines/github/maedhroz/cassandra/487/workflows/0ad42210-2979-4c5d-a4e8-d8cedf9285a7/jobs/4686/tests#failed-test-0]
>  
> My guess is that in some resource constrained environment, even the first 
> {{nodeool listsnapshots}} invocation doesn’t have “dropped” in the stdout. In 
> other words, we skip to the state of the world the last assertion in the test 
> is checking.



--
This message was sent by Atlassian Jira
(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-17144) Fix test TestHintedHandoff#test_hintedhandoff_window

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17144:
---
Fix Version/s: 5.0

> Fix test TestHintedHandoff#test_hintedhandoff_window
> 
>
> Key: CASSANDRA-17144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17144
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1-beta1, 4.1.x, 5.0, 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This test fails from time to time (see butler 
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/hintedhandoff_test/TestHintedHandoff/test_hintedhandoff_window)
> Example: 
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1101/workflows/7afb1c7e-8330-4ac6-963d-d7864282f2f3/jobs/7877
> {code}
> # Ensure second and third datasets are not present
> for x in range(100, 300):
> >   query_c1c2(session, x, ConsistencyLevel.ONE, 
> > tolerate_missing=True, must_be_missing=True)
> hintedhandoff_test.py:264: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> tools/data.py:44: in query_c1c2
> assertions.assert_length_equal(rows, 0)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> object_with_length = [Row(c1='value1', c2='value2')], expected_length = 0
> def assert_length_equal(object_with_length, expected_length):
> """
> Assert an object has a specific length.
> @param object_with_length The object whose length will be checked
> @param expected_length The expected length of the object
> 
> Examples:
> assert_length_equal(res, nb_counter)
> """
> assert len(object_with_length) == expected_length, \
> "Expected {} to have length {}, but instead is of length {}"\
> >   .format(object_with_length, expected_length, 
> > len(object_with_length))
> E   AssertionError: Expected [Row(c1='value1', c2='value2')] to have 
> length 0, but instead is of length 1
> tools/assertions.py:269: AssertionError
> {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-17747) flaky dtest-upgrade.upgrade_tests.compatibility_flag_test.TestCompatibilityFlag.test__compatibility_flag_on_3014

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17747:
---
Fix Version/s: 5.0

> flaky 
> dtest-upgrade.upgrade_tests.compatibility_flag_test.TestCompatibilityFlag.test__compatibility_flag_on_3014
> 
>
> Key: CASSANDRA-17747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17747
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1-beta1, 5.0, 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I noticed while working on other ticket the following failure
> {noformat}
> Regression
> dtest-upgrade.upgrade_tests.compatibility_flag_test.TestCompatibilityFlag.test__compatibility_flag_on_3014
>  (from Cassandra dtests)
> Failing for the past 1 build (Since
> #1822 )
> Took 29 sec.
> Error Message
> AssertionError: Expected 
> {'0eff4047039accb22e83e048f45faaf497f7dbeeb9b7b263ee57e80115c15f20': ['1', 
> '2', '3'], 
> '4e4f0c52c483f4ebca82d4784c569a2e88cc89d417b1106d3166d8dade6a6dc5': ['2', 
> '3', '4'], 
> 'a5d7d00fe13de614673feb05b0f423da60659f481a4248a8f86a63f4ad82da1c': ['3', 
> '4', '5'], 
> '3a177d1a82c9b49287f02e567526347993d756c84ed6a2d4571b901b17a21e72': ['4', 
> '5', '6'], 
> '8aa7cf7ad64690bd705336b8d5b430b27193b0d163e26c4c427550e6ca54': ['5', 
> '6', '7']} from SELECT * FROM test.test, but got 
> {'3a177d1a82c9b49287f02e567526347993d756c84ed6a2d4571b901b17a21e72': ['4', 
> '5', '6'], 
> 'a5d7d00fe13de614673feb05b0f423da60659f481a4248a8f86a63f4ad82da1c': ['3', 
> '4', '5'], 
> '4e4f0c52c483f4ebca82d4784c569a2e88cc89d417b1106d3166d8dade6a6dc5': ['2', 
> '3', '4'], 
> '0eff4047039accb22e83e048f45faaf497f7dbeeb9b7b263ee57e80115c15f20': ['1', 
> '2', '3']}
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-16092) Add Index Group Interface for Storage Attached Index

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-16092:
---
Fix Version/s: 5.0

> Add Index Group Interface for Storage Attached Index
> 
>
> Key: CASSANDRA-16092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16092
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Feature/SASI
>Reporter: Zhao Yang
>Assignee: Zhao Yang
>Priority: Normal
> Fix For: 5.0, 4.x
>
>
> [Index 
> group|https://github.com/datastax/cassandra/blob/storage_attached_index/src/java/org/apache/cassandra/index/Index.java#L634]
>  interface allows:
> * indexes on the same table to receive centralized lifecycle events called 
> secondary index groups. Sharing of data between multiple column indexes on 
> the same table allows SAI disk usage to realise significant space savings 
> over other index implementations.
> * index-group to analyze user query and provide a query plan that leverages 
> all available indexes within the group.



--
This message was sent by Atlassian Jira
(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-17809) Flaky DescribeStatementTest

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17809:
---
Fix Version/s: 5.0

> Flaky DescribeStatementTest
> ---
>
> Key: CASSANDRA-17809
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17809
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.6, 4.1-beta1, 5.0, 4.x
>
>
> Jenkins is showing DescribeStatementTest falking:
> {noformat}
> Regression
> org.apache.cassandra.cql3.statements.DescribeStatementTest.testDescribeFunctionAndAggregate
> Failing for the past 1 build (Since
> #127 )
> Took 0.94 sec.
> Failed 1 times in the last 28 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Invalid value for row 0 column 2 (name of type varchar), expected 
> <'function_07()'> (13 bytes) but got <'function_06(tuple, 
> list>>, tuple>, text>)'> (94 
> bytes) (using protocol version 5/v5)
> Stacktrace
> junit.framework.AssertionFailedError: Invalid value for row 0 column 2 (name 
> of type varchar), expected <'function_07()'> (13 bytes) but got 
> <'function_06(tuple, list>>, 
> tuple>, text>)'> (94 bytes) (using protocol version 
> 5/v5)
>   at 
> org.apache.cassandra.cql3.CQLTester.assertRowsNet(CQLTester.java:1405)
>   at 
> org.apache.cassandra.cql3.CQLTester.assertRowsNet(CQLTester.java:1365)
>   at 
> org.apache.cassandra.cql3.statements.DescribeStatementTest.testDescribeFunctionAndAggregate(DescribeStatementTest.java:132)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15241) Virtual table to expose current running queries

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-15241:
---
Fix Version/s: 5.0

> Virtual table to expose current running queries
> ---
>
> Key: CASSANDRA-15241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15241
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0, 4.x
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> Expose current running queries and their duration.
> {code}cqlsh> select * from system_views.queries;
>  thread_id| duration_micros | task
> --+-+-
>  Native-Transport-Requests-17 |6325 |  QUERY 
> select * from system_views.queries; [pageSize = 100]
>   Native-Transport-Requests-4 |   14681 | EXECUTE 
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
>   Native-Transport-Requests-6 |   14678 | EXECUTE 
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
>  ReadStage-10 |   16535 | 
>SELECT * FROM basic.wide1 LIMIT 5000
>  ReadStage-13 |   16535 | 
>SELECT * FROM basic.wide1 LIMIT 5000
>  ReadStage-14 |   16535 | 
>SELECT * FROM basic.wide1 LIMIT 5000
>  ReadStage-19 |   11861 | 
>SELECT * FROM basic.wide1 LIMIT 5000
>  ReadStage-20 |   11861 | 
>SELECT * FROM basic.wide1 LIMIT 5000
>  ReadStage-22 |7279 | 
>SELECT * FROM basic.wide1 LIMIT 5000
>  ReadStage-23 |4716 | 
>SELECT * FROM basic.wide1 LIMIT 5000
>   ReadStage-5 |   16535 | 
>SELECT * FROM basic.wide1 LIMIT 5000
>   ReadStage-7 |   16535 | 
>SELECT * FROM basic.wide1 LIMIT 5000
>   ReadStage-8 |   16535 | 
>SELECT * FROM basic.wide1 LIMIT 5000{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-18046) A few large DTests failing on trunk after CASSANDRA-17679

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-18046:
---
Fix Version/s: 5.0

> A few large DTests failing on trunk after  CASSANDRA-17679
> --
>
> Key: CASSANDRA-18046
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18046
> Project: Cassandra
>  Issue Type: Bug
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 5.0, 4.x
>
>
> While testing CASSANDRA-18001 I noticed that a few large DTests are failing 
> after CASSANDRA-17679. 
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2129/workflows/885a9ac1-cf12-4fe2-8e27-431af0cd7417/jobs/16691/tests#failed-test-3]
> [TestMaterializedViews.test_add_dc_after_mv_network_replication 
> (large)|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/materialized_views_test/TestMaterializedViews/test_add_dc_after_mv_network_replication]
> [TestMaterializedViews.test_add_dc_after_mv_network_replication 
> (large-novnode)|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/materialized_views_test/TestMaterializedViews/test_add_dc_after_mv_network_replication]
> [TestReplaceAddress.test_resume_failed_replace 
> (large)|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/replace_address_test/TestReplaceAddress/test_resume_failed_replace]
> [TestReplaceAddress.test_resume_failed_replace 
> (large-novnode)|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/replace_address_test/TestReplaceAddress/test_resume_failed_replace]
> From test_add_dc_after_mv_network_replication:
> {code:java}
> test teardown failure Unexpected error found in node logs (see stdout for 
> full details). Errors: [[node4] 'ERROR [RMI TCP Connection(2)-127.0.0.1] 
> 2022-11-14 18:17:12,075 RangeStreamer.java:716 - Discovered existing 
> bootstrap data and cassandra.reset_bootstrap_progress is not configured; 
> aborting bootstrap. Please clean up local files manually and try again or set 
> cassandra.reset_bootstrap_progress=true to ignore. Found: 
> [FetchReplica{local=Full(/127.0.0.4:7000,(-948011243982554585,-529333561071865027]),
>  remote=Full(/127.0.0.1:7000,(-948011243982554585,-529333561071865027])}, 
> FetchReplica{local=Full(/127.0.0.4:7000,(-1913296136443343226,-1608706368519466684]),
>  remote=Full(/127.0.0.1:7000,(-1913296136443343226,-1608706368519466684])}, 
> FetchReplica{local=Full(/127.0.0.4:7000,(-4645079874475487012,-4478384472891273586]),
>  remote=Full(/127.0.0.1:7000,(-4645079874475487012,-4478384472891273586])}, 
> FetchReplica{local=Full(/127.0.0.4:7000,(-8099177469676285022,-7854326460977230843]),
>  remote=Full(/127.0.0.1:7000,(-8099177469676285022,-7854326460977230843])}, 
> FetchReplica{local=Full(/127.0.0.4:7000,(4622442467519845550,4890578535898204379]),
>  remote=Full(/127.0.0.1:7000,(4622442467519845550,4890578535898204379])}, 
> FetchReplica{local=Full(/127.0.0.4:7000,(7380640855742145045,7647358289237905583]),
>  remote=Full(/127.0.0.1:7000,(7380640855742145045,7647358289237905583])}, 
> FetchReplica{local=Full(/127.0.0.4:7000,(-3745211865398425909,-3420377942455939864]),
>  remote=Full(/127.0.0.1:7000,(-3745211865398425909,-3420377942455939864])}, 
> FetchReplica{local=Full(/127.0.0.4:7000,(220943679196459793,240311054740010215]),
>  remote=Full(/127.0.0.1:7000,(220943679196459793,240311054740010215])}, 
> FetchReplica{local=Full(/127.0.0.4:7000,(-9089536355394438553,-8950368361212169132]),
>  remote=Full(/127.0.0.1:7000,(-9089536355394438553,-8950368361212169132])}, 
> FetchReplica{local=Full(/127.0.0.4:7000,(1270067479525650881,1319683862187611873]),
>  remote=Full(/127.0.0.1:7000,(1270067479525650881,1319683862187611873])}]. 
> Fully available: [(220943679196459793,240311054740010215], 
> (714186444608726945,1270067479525650881], 
> (1270067479525650881,1319683862187611873], 
> (1681550687687262444,2205980652317166301], 
> (2205980652317166301,2563203867868203845], 
> (2989961503515581499,3271555240201161082], 
> (3271555240201161082,3530568110946739344], 
> (4622442467519845550,4890578535898204379], 
> (4890578535898204379,5120572663460637982], 
> (6233317147386468337,6523342873530347572], 
> (6523342873530347572,6739595959157681279], 
> (7380640855742145045,7647358289237905583], 
> (7647358289237905583,7717741411673795355], 
> (9105128289353134439,-9089536355394438553], 
> (-9089536355394438553,-8950368361212169132], 
> (-8612046773544495484,-8099177469676285022], 
> (-8099177469676285022,-7854326460977230843], 
> (-7272331012938171751,-6967841455392203442], 
> (-6967841455392203442,-6763029350285018583], 
> 

[jira] [Updated] (CASSANDRA-17670) Flaky CompactStorageTest

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17670:
---
Fix Version/s: 5.0

> Flaky CompactStorageTest
> 
>
> Key: CASSANDRA-17670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17670
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1.x, 5.0, 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> CompactStorageTest has been showing flaky behavior mainly due to timeouts 
> such as 
> [here|https://ci-cassandra.apache.org/job/Cassandra-4.1/43/testReport/org.apache.cassandra.cql3.validation.operations/CompactStorageTest/testAlterWithCompactNonStaticFormat/]



--
This message was sent by Atlassian Jira
(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-17625) Test Failure: dtest-offheap.auth_test.TestAuth.test_system_auth_ks_is_alterable (from Cassandra dtests)

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17625:
---
Fix Version/s: 5.0

> Test Failure: 
> dtest-offheap.auth_test.TestAuth.test_system_auth_ks_is_alterable (from 
> Cassandra dtests)
> ---
>
> Key: CASSANDRA-17625
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17625
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Josh McKenzie
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1-beta1, 4.1.x, 5.0, 4.x
>
>
> Flaked a couple times on 4.1
> {code}
> Error Message
> cassandra.DriverException: Keyspace metadata was not refreshed. See log for 
> details.
> {code}
> https://ci-cassandra.apache.org/job/Cassandra-4.1/14/testReport/dtest-offheap.auth_test/TestAuth/test_system_auth_ks_is_alterable/
> Nightlies archive if above dropped: 
> https://nightlies.apache.org/cassandra/ci-cassandra.apache.org/job/Cassandra-4.1/14/testReport/dtest-offheap.auth_test/TestAuth/test_system_auth_ks_is_alterable/



--
This message was sent by Atlassian Jira
(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

[Michael Semb Wever (Jira)]

 [ 
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: 5.0

> 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, 5.0, 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-17877) Speculative execution threshold unit mismatch

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17877:
---
Fix Version/s: 5.0

> Speculative execution threshold unit mismatch
> -
>
> Key: CASSANDRA-17877
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17877
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Coordination
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.1-beta1, 5.0, 4.x
>
>
> CASSANDRA-16760 changed the ColumnFamilyStore.coordinatorRead/WriteLatency to 
> be in microseconds rather than nanoseconds but did not change the calculation 
> for ColumnFamilyStore.sampleReadLatencyNanos/additionalWriteLatency which is 
> used as the threshold for speculative read execution / issuing additional 
> writes.
> The impact of this bug is that the threshold is 1000x smaller than intended 
> when using percentile based speculation (tables default to 99p), so 
> effectively speculation happens for ALL reads configured to speculate on a 
> percentile, including min hybrid policies that use percentiles.



--
This message was sent by Atlassian Jira
(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-17973) Change trunk 4.2 to 5.0

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17973:
---
Fix Version/s: 5.0
   (was: 5.x)

> Change trunk 4.2 to 5.0
> ---
>
> Key: CASSANDRA-17973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17973
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.0
>
>
> 1. Bump trunk's version 
> {code}
> git switch trunk
> # increment version to 5.0
> edit build.xml debian/changelog CHANGES.txt NEWS.txt README.asc
> {code}
> 2. Update jvm-dtest supported upgrade paths
>  - 
> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L85-L96
>  
> 3. Update `4.2` to jira versions
> Change `4.2` to `5.0`
> Change `4.x` to `5.x`
> 4. Update docker images to include cassandra-5.0
> (Docker images also need to be deployed)
> 5. Add pipeline to ci-cassandra
> https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51
> 6. Add dtest version and upgrade paths
>  - 
> https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py
>  - https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374
>  - 
> https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L41
> 7. Update how_to_commit documentation
> https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc



--
This message was sent by Atlassian Jira
(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-17973) Change trunk 4.2 to 5.0

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17973:
---
Source Control Link: 
https://github.com/apache/cassandra/commit/7ca806c60a3e080d740fb163c639bb76a520f6ab
 
https://github.com/apache/cassandra-dtest/commit/79602451c9efb05fd16f09249823ebe8049e01e2
 
https://github.com/apache/cassandra-website/commit/c4206294fd9ea3005c0ab669969d8

> Change trunk 4.2 to 5.0
> ---
>
> Key: CASSANDRA-17973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17973
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> 1. Bump trunk's version 
> {code}
> git switch trunk
> # increment version to 5.0
> edit build.xml debian/changelog CHANGES.txt NEWS.txt README.asc
> {code}
> 2. Update jvm-dtest supported upgrade paths
>  - 
> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L85-L96
>  
> 3. Update `4.2` to jira versions
> Change `4.2` to `5.0`
> Change `4.x` to `5.x`
> 4. Update docker images to include cassandra-5.0
> (Docker images also need to be deployed)
> 5. Add pipeline to ci-cassandra
> https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51
> 6. Add dtest version and upgrade paths
>  - 
> https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py
>  - https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374
>  - 
> https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L41
> 7. Update how_to_commit documentation
> https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc



--
This message was sent by Atlassian Jira
(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-17973) Change trunk 4.2 to 5.0

[Michael Semb Wever (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-17973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697339#comment-17697339
 ] 

Michael Semb Wever commented on CASSANDRA-17973:


Committed 
[7ca806c60a3e080d740fb163c639bb76a520f6ab|https://github.com/apache/cassandra/commit/7ca806c60a3e080d740fb163c639bb76a520f6ab],
 
[79602451c9efb05fd16f09249823ebe8049e01e2|https://github.com/apache/cassandra-dtest/commit/79602451c9efb05fd16f09249823ebe8049e01e2]
 and 
[c4206294fd9ea3005c0ab669969d87526f94bb57|https://github.com/apache/cassandra-website/commit/c4206294fd9ea3005c0ab669969d87526f94bb57].

> Change trunk 4.2 to 5.0
> ---
>
> Key: CASSANDRA-17973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17973
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> 1. Bump trunk's version 
> {code}
> git switch trunk
> # increment version to 5.0
> edit build.xml debian/changelog CHANGES.txt NEWS.txt README.asc
> {code}
> 2. Update jvm-dtest supported upgrade paths
>  - 
> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L85-L96
>  
> 3. Update `4.2` to jira versions
> Change `4.2` to `5.0`
> Change `4.x` to `5.x`
> 4. Update docker images to include cassandra-5.0
> (Docker images also need to be deployed)
> 5. Add pipeline to ci-cassandra
> https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51
> 6. Add dtest version and upgrade paths
>  - 
> https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py
>  - https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374
>  - 
> https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L41
> 7. Update how_to_commit documentation
> https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra-website] branch trunk updated: Update how_to_commit.adoc for current branches (4.0, 4.1, trunk)

[mck]

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-website.git


The following commit(s) were added to refs/heads/trunk by this push:
 new c4206294f Update how_to_commit.adoc for current branches (4.0, 4.1, 
trunk)
c4206294f is described below

commit c4206294fd9ea3005c0ab669969d87526f94bb57
Author: mck 
AuthorDate: Sat Feb 25 11:23:21 2023 +0100

Update how_to_commit.adoc for current branches (4.0, 4.1, trunk)

 patch by Mick Semb Wever; reviewed by Brandon Williams for CASSANDRA-17973
---
 .../ROOT/pages/development/how_to_commit.adoc  | 80 --
 1 file changed, 30 insertions(+), 50 deletions(-)

diff --git 
a/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc 
b/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc
index 319a4f0ec..ceb8ac243 100644
--- a/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc
+++ b/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc
@@ -10,35 +10,29 @@ If you are a committer, feel free to pick any process that 
works for you
 Here is how committing and merging will usually look for merging and
 pushing for tickets that follow the convention (if patch-based):
 
-Hypothetical CASSANDRA-12345 ticket is a cassandra-3.0 based bug fix
-that requires different code for cassandra-3.11, cassandra-4.0, and
+Hypothetical CASSANDRA-12345 ticket is a cassandra-4.0 based bug fix
+that requires different code for cassandra-4.0, cassandra-4.1, and
 trunk. Contributor Jackie supplied a patch for the root branch
-(12345-3.0.patch), and patches for the remaining branches
-(12345-3.11.patch, 12345-4.0.patch, 12345-trunk.patch).
+(12345-4.0.patch), and patches for the remaining branches
+(12345-4.1.patch, 12345-trunk.patch).
 
-On cassandra-3.0:::
-  . `+git am -3 12345-3.0.patch+` (any problem b/c of CHANGES.txt not
+On cassandra-4.0:::
+  . `+git am -3 12345-4.0.patch+` (any problem b/c of CHANGES.txt not
   merging anymore, fix it in place)
   . `+ant realclean && ant jar build-test+` (rebuild to make sure code
   compiles)
-On cassandra-3.11:::
-  . `+git merge cassandra-3.0 -s ours+`
-  . `+git apply -3 12345-3.11.patch+` (any issue with CHANGES.txt : fix
-  and [.title-ref]#git add CHANGES.txt#)
-  . `+ant realclean && ant jar build-test+` (rebuild to make sure code
-  compiles)
-  . `+git commit --amend+` (Notice this will squash the 3.11 applied
+  . `+git commit --amend+` (Notice this will squash the 4.0 applied
   patch into the forward merge commit)
-On cassandra-4.0:::
-  . `+git merge cassandra-3.11 -s ours+`
-  . `+git apply -3 12345-4.0.patch+` (any issue with CHANGES.txt : fix
+On cassandra-4.1:::
+  . `+git merge cassandra-4.0 -s ours --log+`
+  . `+git apply -3 12345-4.1.patch+` (any issue with CHANGES.txt : fix
   and [.title-ref]#git add CHANGES.txt#)
   . `+ant realclean && ant jar build-test+` (rebuild to make sure code
   compiles)
-  . `+git commit --amend+` (Notice this will squash the 4.0 applied
+  . `+git commit --amend+` (Notice this will squash the 4.1 applied
   patch into the forward merge commit)
 On trunk:::
-  . `+git merge cassandra-4.0 -s ours+`
+  . `+git merge cassandra-4.1 -s ours --log+`
   . `+git apply -3 12345-trunk.patch+` (any issue with CHANGES.txt : fix
   and [.title-ref]#git add CHANGES.txt#)
   . `+ant realclean && ant jar build-test+` (rebuild to make sure code
@@ -46,41 +40,31 @@ On trunk:::
   . `+git commit --amend+` (Notice this will squash the trunk applied
   patch into the forward merge commit)
 On any branch:::
-  . `+git push origin cassandra-3.0 cassandra-3.11 cassandra-4.0 trunk 
--atomic -n+`
+  . `+git push origin cassandra-4.0 cassandra-4.1 trunk --atomic -n+`
   (dryrun check)
-  . `+git push origin cassandra-3.0 cassandra-3.11 cassandra-4.0 trunk 
--atomic+`
+  . `+git push origin cassandra-4.0 cassandra-4.1 trunk --atomic+`
 
 == Git branch based Contribution
 
 Same scenario, but a branch-based contribution:
 
-On cassandra-3.0:::
-  . `+git cherry-pick +` (any problem b/c of
+On cassandra-4.0:::
+  . `+git cherry-pick +` (any problem b/c of
   CHANGES.txt not merging anymore, fix it in place)
   . `+ant realclean && ant jar build-test+` (rebuild to make sure code
   compiles)
-On cassandra-3.11:::
-  . `+git merge cassandra-3.0 -s ours+`
-  . `+git format-patch -1 +` (alternative to
-  format-patch and apply is [.title-ref]#cherry-pick -n#)
-  . `+git apply -3 .patch+` (any issue with
-  CHANGES.txt : fix and [.title-ref]#git add CHANGES.txt#)
-  . `+ant realclean && ant jar build-test+` (rebuild to make sure code
-  compiles)
-  . `+git commit --amend+` (Notice this will squash the 3.11 applied
-  patch into the forward merge commit)
-On cassandra-4.0:::
-  . `+git merge cassandra-3.11 -s ours+`
+On cassandra-4.1:::
+  . `+git merge cassandra-4.0 -s ours --log+`
   . `+git format-patch -1 +` (alternative 

[cassandra-dtest] branch trunk updated: Change trunk from 4.2 to 5.0

[mck]

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-dtest.git


The following commit(s) were added to refs/heads/trunk by this push:
 new 79602451 Change trunk from 4.2 to 5.0
79602451 is described below

commit 79602451c9efb05fd16f09249823ebe8049e01e2
Author: Mick Semb Wever 
AuthorDate: Sat Feb 25 11:29:37 2023 +0100

Change trunk from 4.2 to 5.0

 Use parent sha to run against 4.2-SNAPSHOT versions of trunk.

 patch by Mick Semb Wever; reviewed by Brandon Williams for CASSANDRA-17973
---
 upgrade_tests/upgrade_manifest.py  | 16 
 upgrade_tests/upgrade_through_versions_test.py |  4 ++--
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/upgrade_tests/upgrade_manifest.py 
b/upgrade_tests/upgrade_manifest.py
index b369121e..bd345d9f 100644
--- a/upgrade_tests/upgrade_manifest.py
+++ b/upgrade_tests/upgrade_manifest.py
@@ -27,8 +27,8 @@ CASSANDRA_3_0 = '3.0'
 CASSANDRA_3_11 = '3.11'
 CASSANDRA_4_0 = '4.0'
 CASSANDRA_4_1 = '4.1'
-CASSANDRA_4_2 = '4.2'
-TRUNK = CASSANDRA_4_2
+CASSANDRA_5_0 = '5.0'
+TRUNK = CASSANDRA_5_0
 
 def is_same_family_current_to_indev(origin, destination):
 """
@@ -101,8 +101,8 @@ def set_version_family():
 version_family = CASSANDRA_4_0
 elif current_version.vstring.startswith('4.1'):
 version_family = CASSANDRA_4_1
-elif current_version.vstring.startswith('4.2'):
-version_family = CASSANDRA_4_2
+elif current_version.vstring.startswith('5.0'):
+version_family = CASSANDRA_5_0
 else:
 # when this occurs, it's time to update this manifest a bit!
 raise RuntimeError("Testing upgrades from/to version %s is not 
supported. Please use a custom manifest (see upgrade_manifest.py)" % 
current_version.vstring)
@@ -182,13 +182,13 @@ indev_trunk = VersionMeta(name='indev_trunk', 
family=TRUNK, variant='indev', ver
 MANIFEST = {
 current_2_1_x: [indev_2_2_x, indev_3_0_x, indev_3_11_x],
 current_2_2_x: [indev_2_2_x, indev_3_0_x, indev_3_11_x],
-current_3_0_x: [indev_3_0_x, indev_3_11_x, indev_4_0_x, indev_4_1_x, 
indev_trunk],
-current_3_11_x: [indev_3_11_x, indev_4_0_x, indev_4_1_x, indev_trunk],
+current_3_0_x: [indev_3_0_x, indev_3_11_x, indev_4_0_x, indev_4_1_x],
+current_3_11_x: [indev_3_11_x, indev_4_0_x, indev_4_1_x],
 current_4_0_x: [indev_4_0_x, indev_4_1_x, indev_trunk],
 
 indev_2_2_x: [indev_3_0_x, indev_3_11_x],
-indev_3_0_x: [indev_3_11_x, indev_4_0_x, indev_4_1_x, indev_trunk],
-indev_3_11_x: [indev_4_0_x, indev_4_1_x, indev_trunk],
+indev_3_0_x: [indev_3_11_x, indev_4_0_x, indev_4_1_x],
+indev_3_11_x: [indev_4_0_x, indev_4_1_x],
 indev_4_0_x: [indev_4_1_x, indev_trunk],
 indev_4_1_x: [indev_trunk]
 }
diff --git a/upgrade_tests/upgrade_through_versions_test.py 
b/upgrade_tests/upgrade_through_versions_test.py
index 58fc02e3..d711a10b 100644
--- a/upgrade_tests/upgrade_through_versions_test.py
+++ b/upgrade_tests/upgrade_through_versions_test.py
@@ -24,7 +24,7 @@ from .upgrade_base import switch_jdks
 from .upgrade_manifest import (build_upgrade_pairs,
current_2_1_x, current_2_2_x, current_3_0_x,
indev_3_11_x,
-   current_3_11_x, indev_trunk, CASSANDRA_4_0, 
CASSANDRA_4_2)
+   current_3_11_x, indev_trunk, CASSANDRA_4_0, 
CASSANDRA_5_0)
 
 logger = logging.getLogger(__name__)
 
@@ -526,7 +526,7 @@ class TestUpgrade(Tester):
 logger.debug("Set new cassandra dir for %s: %s" % (node.name, 
node.get_install_dir()))
 if internode_ssl and (LooseVersion(version_meta.family) >= 
CASSANDRA_4_0):
 node.set_configuration_options({'server_encryption_options': 
{'enabled': True, 'enable_legacy_ssl_storage_port': True}})
-if LooseVersion(version_meta.family) >= CASSANDRA_4_2:
+if LooseVersion(version_meta.family) >= CASSANDRA_5_0:
 
node.set_configuration_options({'enable_scripted_user_defined_functions': 
'false'})
 
 # hacky? yes. We could probably extend ccm to allow this publicly.


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] branch trunk updated: Change trunk from 4.2 to 5.0

[mck]

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


The following commit(s) were added to refs/heads/trunk by this push:
 new 7ca806c60a Change trunk from 4.2 to 5.0
7ca806c60a is described below

commit 7ca806c60a3e080d740fb163c639bb76a520f6ab
Author: Mick Semb Wever 
AuthorDate: Sat Feb 25 11:25:35 2023 +0100

Change trunk from 4.2 to 5.0

 – update MessagingService (remove the 4.1 version that was only a 
placeholder in test code bc serialisation test files were previously 
incorrectly serialising random UUIds for TimeUUIDs)
 – update upgrade jvm-dtests
 – remove older serialization binary files we are no longer testing against

 patch by Mick Semb Wever; reviewed by Brandon Williams for CASSANDRA-17973
---
 CHANGES.txt|   2 +-
 NEWS.txt   |   2 +-
 README.asc |   2 +-
 build.xml  |   6 +-
 debian/changelog   |   2 +-
 ide/nbproject/project.xml  |   2 +-
 .../org/apache/cassandra/net/MessagingService.java |   1 -
 .../serialization/0.7/db.RangeSliceCommand.bin | Bin 777 -> 0 bytes
 test/data/serialization/0.7/db.Row.bin | Bin 495 -> 0 bytes
 test/data/serialization/0.7/db.RowMutation.bin | Bin 3266 -> 0 bytes
 .../0.7/db.SliceByNamesReadCommand.bin | Bin 367 -> 0 bytes
 .../serialization/0.7/db.SliceFromReadCommand.bin  | Bin 361 -> 0 bytes
 test/data/serialization/0.7/db.Truncation.bin  | Bin 257 -> 0 bytes
 test/data/serialization/0.7/db.WriteResponse.bin   | Bin 38 -> 0 bytes
 test/data/serialization/0.7/gms.EndpointState.bin  | Bin 73 -> 0 bytes
 test/data/serialization/0.7/gms.Gossip.bin | Bin 110 -> 0 bytes
 .../data/serialization/0.7/service.TreeRequest.bin | Bin 93 -> 0 bytes
 .../serialization/0.7/service.TreeResponse.bin | Bin 3656 -> 0 bytes
 .../serialization/0.7/streaming.PendingFile.bin| Bin 3393 -> 0 bytes
 .../serialization/0.7/streaming.StreamHeader.bin   | Bin 171405 -> 0 bytes
 .../serialization/0.7/streaming.StreamReply.bin| Bin 73 -> 0 bytes
 .../0.7/streaming.StreamRequestMessage.bin | Bin 6909 -> 0 bytes
 test/data/serialization/0.7/utils.BloomFilter.bin  | Bin 2500016 -> 0 bytes
 .../serialization/0.7/utils.EstimatedHistogram.bin | Bin 97500 -> 0 bytes
 .../serialization/0.7/utils.LegacyBloomFilter.bin  | Bin 5000170 -> 0 bytes
 .../serialization/1.0/db.RangeSliceCommand.bin | Bin 777 -> 0 bytes
 test/data/serialization/1.0/db.Row.bin | Bin 495 -> 0 bytes
 test/data/serialization/1.0/db.RowMutation.bin | Bin 3266 -> 0 bytes
 .../1.0/db.SliceByNamesReadCommand.bin | Bin 367 -> 0 bytes
 .../serialization/1.0/db.SliceFromReadCommand.bin  | Bin 361 -> 0 bytes
 test/data/serialization/1.0/db.Truncation.bin  | Bin 257 -> 0 bytes
 test/data/serialization/1.0/db.WriteResponse.bin   | Bin 38 -> 0 bytes
 .../serialization/1.0/db.migration.Keyspace1.bin   |   1 -
 .../serialization/1.0/db.migration.Keyspace2.bin   |   1 -
 .../serialization/1.0/db.migration.Keyspace3.bin   |   1 -
 .../serialization/1.0/db.migration.Keyspace4.bin   |   1 -
 .../serialization/1.0/db.migration.Keyspace5.bin   |   1 -
 test/data/serialization/1.0/gms.EndpointState.bin  | Bin 73 -> 0 bytes
 test/data/serialization/1.0/gms.Gossip.bin | Bin 110 -> 0 bytes
 .../data/serialization/1.0/service.TreeRequest.bin | Bin 121 -> 0 bytes
 .../serialization/1.0/service.TreeResponse.bin | Bin 930 -> 0 bytes
 .../serialization/1.0/streaming.PendingFile.bin| Bin 3436 -> 0 bytes
 .../serialization/1.0/streaming.StreamHeader.bin   | Bin 174421 -> 0 bytes
 .../serialization/1.0/streaming.StreamReply.bin| Bin 73 -> 0 bytes
 .../1.0/streaming.StreamRequestMessage.bin | Bin 7087 -> 0 bytes
 test/data/serialization/1.0/utils.BloomFilter.bin  | Bin 2500016 -> 0 bytes
 .../serialization/1.0/utils.EstimatedHistogram.bin | Bin 97500 -> 0 bytes
 .../serialization/1.0/utils.LegacyBloomFilter.bin  | Bin 5000170 -> 0 bytes
 .../serialization/1.2/db.RangeSliceCommand.bin | Bin 735 -> 0 bytes
 test/data/serialization/1.2/db.Row.bin | Bin 527 -> 0 bytes
 test/data/serialization/1.2/db.RowMutation.bin | Bin 3410 -> 0 bytes
 .../1.2/db.SliceByNamesReadCommand.bin | Bin 373 -> 0 bytes
 .../serialization/1.2/db.SliceFromReadCommand.bin  | Bin 409 -> 0 bytes
 test/data/serialization/1.2/db.Truncation.bin  | Bin 257 -> 0 bytes
 test/data/serialization/1.2/db.WriteResponse.bin   | Bin 38 -> 0 bytes
 test/data/serialization/1.2/gms.EndpointState.bin  | Bin 110 -> 0 bytes
 test/data/serialization/1.2/gms.Gossip.bin | Bin 158 -> 0 bytes
 .../data/serialization/1.2/service.TreeRequest.bin | Bin 121 -> 0 bytes
 

[jira] [Commented] (CASSANDRA-18302) Fix AIOOBE and improve validation messages for transaction statements

[Jacek Lewandowski (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697323#comment-17697323
 ] 

Jacek Lewandowski commented on CASSANDRA-18302:
---

https://github.com/apache/cassandra/pull/2195

> Fix AIOOBE and improve validation messages for transaction statements
> -
>
> Key: CASSANDRA-18302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18302
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown 
> from asCql method when validation transaction statement. In addition, asCql 
> does not return precisely the query user entered so the whole error message 
> can be misleading.



--
This message was sent by Atlassian Jira
(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-18302) Fix AIOOBE and improve validation messages for transaction statements

[Jacek Lewandowski (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacek Lewandowski updated CASSANDRA-18302:
--
Test and Documentation Plan: regressions
 Status: Patch Available  (was: Open)

> Fix AIOOBE and improve validation messages for transaction statements
> -
>
> Key: CASSANDRA-18302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18302
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown 
> from asCql method when validation transaction statement. In addition, asCql 
> does not return precisely the query user entered so the whole error message 
> can be misleading.



--
This message was sent by Atlassian Jira
(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-17973) Change trunk 4.2 to 5.0

[Michael Semb Wever (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17973:
---
Status: Ready to Commit  (was: Review In Progress)

> Change trunk 4.2 to 5.0
> ---
>
> Key: CASSANDRA-17973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17973
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> 1. Bump trunk's version 
> {code}
> git switch trunk
> # increment version to 5.0
> edit build.xml debian/changelog CHANGES.txt NEWS.txt README.asc
> {code}
> 2. Update jvm-dtest supported upgrade paths
>  - 
> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L85-L96
>  
> 3. Update `4.2` to jira versions
> Change `4.2` to `5.0`
> Change `4.x` to `5.x`
> 4. Update docker images to include cassandra-5.0
> (Docker images also need to be deployed)
> 5. Add pipeline to ci-cassandra
> https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51
> 6. Add dtest version and upgrade paths
>  - 
> https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py
>  - https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374
>  - 
> https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L41
> 7. Update how_to_commit documentation
> https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org