[jira] [Commented] (CASSANDRA-18603) Move checkstyle files into .build
[ https://issues.apache.org/jira/browse/CASSANDRA-18603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735996#comment-17735996 ] Berenguer Blasi commented on CASSANDRA-18603: - Right, just pushed. I always do 1 PR alone first to validate the approach. 4 eyes see more than 2. Then push the rest of the PRs not to duplicate work. > Move checkstyle files into .build > - > > Key: CASSANDRA-18603 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18603 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1.x, 5.x > > > Checkstyle files are currently in the root folder whereas the rest of similar > purposed files live under .build. Let's move them for consistency. > CC [~mck] -- This message was sent by Atlassian Jira (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-18017) Jenkins: Consider using the no-build-test flag
[
https://issues.apache.org/jira/browse/CASSANDRA-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735999#comment-17735999
]
Jacek Lewandowski commented on CASSANDRA-18017:
---
It is 0 impact only if you rely on CI only. Similarly, you could forget to try
compiling the project before pushing. If you frequently rerun stuff locally, it
is definitely not zero impact. Also, Eclipse-Warnings is currently not run
automatically, which can result in a surprise of the same kind.
It would probably be more efficient to implement running checks as a pre-push
git hook and actually run the checks against modified files only, assuming we
can somehow determine the base branch.
> Jenkins: Consider using the no-build-test flag
> --
>
> Key: CASSANDRA-18017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18017
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Maxim Muzafarov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16625 and CASSANDRA-18000 added a {{-Dno-build-test=true}} flag to
> skip the dependencies of the Ant test targets. This is useful to speed up the
> test targets if the {{build-test}} target has already been previously run,
> for example as part of {{{}ant jar{}}}.
> That was created thinking mainly on CircleCI's multiplexer, where we run the
> same test target repeatedly. Skipping the already run depended on targets can
> significantly speed up the tests. The flag however is also useful for all
> other test jobs because every parallel runner can skip the test building
> step, and we have hundreds of parallel runners. Saving around 30s on every
> runner adds up considerable savings.
> Maybe this flag can also be used for skipping test builds on Jenkins too, so
> each parallel test split can benefit from a slight boost. That could be done
> if either {{build-test}} or {{jar}} have already been run before calling the
> test target. I'm not familiarized with Jenkins config so I'm not sure whether
> it makes sense.
--
This message was sent by Atlassian Jira
(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-18017) Jenkins: Consider using the no-build-test flag
[
https://issues.apache.org/jira/browse/CASSANDRA-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736002#comment-17736002
]
Berenguer Blasi commented on CASSANDRA-18017:
-
bq. If you frequently rerun stuff locally, it is definitely not zero impact
Are we talking the same thing? Did you notice the recently merged
CASSANDRA-18588 does exactly that? it runs checkstyle only against modified
files and then it takes no time at all.
> Jenkins: Consider using the no-build-test flag
> --
>
> Key: CASSANDRA-18017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18017
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Maxim Muzafarov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16625 and CASSANDRA-18000 added a {{-Dno-build-test=true}} flag to
> skip the dependencies of the Ant test targets. This is useful to speed up the
> test targets if the {{build-test}} target has already been previously run,
> for example as part of {{{}ant jar{}}}.
> That was created thinking mainly on CircleCI's multiplexer, where we run the
> same test target repeatedly. Skipping the already run depended on targets can
> significantly speed up the tests. The flag however is also useful for all
> other test jobs because every parallel runner can skip the test building
> step, and we have hundreds of parallel runners. Saving around 30s on every
> runner adds up considerable savings.
> Maybe this flag can also be used for skipping test builds on Jenkins too, so
> each parallel test split can benefit from a slight boost. That could be done
> if either {{build-test}} or {{jar}} have already been run before calling the
> test target. I'm not familiarized with Jenkins config so I'm not sure whether
> it makes sense.
--
This message was sent by Atlassian Jira
(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-18467) Update generate-idea-files for J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736005#comment-17736005 ] Stefan Miklosovic commented on CASSANDRA-18467: --- [~e.dimitrova] can we abandon / close / reject this ticket then? > Update generate-idea-files for J17 > -- > > Key: CASSANDRA-18467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18467 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Jakub Zytka >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > There was a discussion in CASSANDRA-18258 how to update generate-idea-files. > The final agreement was to create one target to cover both Java 11 and Java > 17. > It will be good to figure out CASSANDRA-18263 and reshuffle arguments and > tasks based on what we decide to use as gc in testing for both Java 11 and > Java 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] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736006#comment-17736006
]
Stefan Miklosovic commented on CASSANDRA-18305:
---
j8 pre-commit
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2510/workflows/a5245e10-2fc8-401a-9d5d-e6d171842b13
> 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: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] [Comment Edited] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736006#comment-17736006
]
Stefan Miklosovic edited comment on CASSANDRA-18305 at 6/22/23 7:34 AM:
j8 pre-commit
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2510/workflows/a5245e10-2fc8-401a-9d5d-e6d171842b13
j11 pre-commit
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2510/workflows/b3ada529-f2d4-497b-a5de-0c7d5bdff508
was (Author: smiklosovic):
j8 pre-commit
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2510/workflows/a5245e10-2fc8-401a-9d5d-e6d171842b13
> 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: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] [Commented] (CASSANDRA-18017) Jenkins: Consider using the no-build-test flag
[
https://issues.apache.org/jira/browse/CASSANDRA-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736013#comment-17736013
]
Jacek Lewandowski commented on CASSANDRA-18017:
---
That is great! I didn't know that and thought it took around an extra minute.
But I stick with my opinion - when I run a "test" target, I want to run a test
- not a static code analysis. In particular, I want to avoid being forced to
fix all the issues to run a test. When we add a checker framework, which
enforces additional rules, it will become even more annoying.
Would running the incremental validation with the "jar" target but not with the
"test" target be a compromise?
> Jenkins: Consider using the no-build-test flag
> --
>
> Key: CASSANDRA-18017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18017
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Maxim Muzafarov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16625 and CASSANDRA-18000 added a {{-Dno-build-test=true}} flag to
> skip the dependencies of the Ant test targets. This is useful to speed up the
> test targets if the {{build-test}} target has already been previously run,
> for example as part of {{{}ant jar{}}}.
> That was created thinking mainly on CircleCI's multiplexer, where we run the
> same test target repeatedly. Skipping the already run depended on targets can
> significantly speed up the tests. The flag however is also useful for all
> other test jobs because every parallel runner can skip the test building
> step, and we have hundreds of parallel runners. Saving around 30s on every
> runner adds up considerable savings.
> Maybe this flag can also be used for skipping test builds on Jenkins too, so
> each parallel test split can benefit from a slight boost. That could be done
> if either {{build-test}} or {{jar}} have already been run before calling the
> test target. I'm not familiarized with Jenkins config so I'm not sure whether
> it makes sense.
--
This message was sent by Atlassian Jira
(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-18017) Jenkins: Consider using the no-build-test flag
[
https://issues.apache.org/jira/browse/CASSANDRA-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736017#comment-17736017
]
Berenguer Blasi commented on CASSANDRA-18017:
-
Aha, now we're understanding each other lol!
So pick your poison right? Either roll eyes A. when the CI fails 10m down the
line on some check you forgot to do (my case) or B. roll eyes when locally you
get check violations that you don't care about bc you're experimenting (your
case).
For B we already have the -Dno-checkstyle=true flag specifically to that
effect: ant test -Dno-checkstyle=true bla bla
Seems all bases are covered unless I am missing sthg. I am happy with the
current approach but let's see what others think...
> Jenkins: Consider using the no-build-test flag
> --
>
> Key: CASSANDRA-18017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18017
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Maxim Muzafarov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16625 and CASSANDRA-18000 added a {{-Dno-build-test=true}} flag to
> skip the dependencies of the Ant test targets. This is useful to speed up the
> test targets if the {{build-test}} target has already been previously run,
> for example as part of {{{}ant jar{}}}.
> That was created thinking mainly on CircleCI's multiplexer, where we run the
> same test target repeatedly. Skipping the already run depended on targets can
> significantly speed up the tests. The flag however is also useful for all
> other test jobs because every parallel runner can skip the test building
> step, and we have hundreds of parallel runners. Saving around 30s on every
> runner adds up considerable savings.
> Maybe this flag can also be used for skipping test builds on Jenkins too, so
> each parallel test split can benefit from a slight boost. That could be done
> if either {{build-test}} or {{jar}} have already been run before calling the
> test target. I'm not familiarized with Jenkins config so I'm not sure whether
> it makes sense.
--
This message was sent by Atlassian Jira
(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-18017) Jenkins: Consider using the no-build-test flag
[
https://issues.apache.org/jira/browse/CASSANDRA-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736029#comment-17736029
]
Jacek Lewandowski commented on CASSANDRA-18017:
---
If you want to have a guarantee - let's just add a pre-push hook, so that git
would run the checks
> Jenkins: Consider using the no-build-test flag
> --
>
> Key: CASSANDRA-18017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18017
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Maxim Muzafarov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16625 and CASSANDRA-18000 added a {{-Dno-build-test=true}} flag to
> skip the dependencies of the Ant test targets. This is useful to speed up the
> test targets if the {{build-test}} target has already been previously run,
> for example as part of {{{}ant jar{}}}.
> That was created thinking mainly on CircleCI's multiplexer, where we run the
> same test target repeatedly. Skipping the already run depended on targets can
> significantly speed up the tests. The flag however is also useful for all
> other test jobs because every parallel runner can skip the test building
> step, and we have hundreds of parallel runners. Saving around 30s on every
> runner adds up considerable savings.
> Maybe this flag can also be used for skipping test builds on Jenkins too, so
> each parallel test split can benefit from a slight boost. That could be done
> if either {{build-test}} or {{jar}} have already been run before calling the
> test target. I'm not familiarized with Jenkins config so I'm not sure whether
> it makes sense.
--
This message was sent by Atlassian Jira
(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-18465) Add support for multiple condition branches and results in Accord transaction
[
https://issues.apache.org/jira/browse/CASSANDRA-18465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18465:
--
Test and Documentation Plan: run regressions, new tests, manual testing if
needed
Status: Patch Available (was: In Progress)
> Add support for multiple condition branches and results in Accord transaction
> -
>
> Key: CASSANDRA-18465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18465
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> I'd like to propose adding support for multiple branches and result sets for
> Accord transactions. It could look like this:
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 'two', b.value
> UPDATE ...
> ELSE
> SELECT 'three', NULL
> END IF
> COMMIT TRANSACTION
> {code}
> The existing syntax would remain valid, when a single SELECT is defined in
> which case the conditional SELECTs would not be valid.
> SELECTs would be validated to return columns of the same type. They would be
> able to return literals as well.
> This would be make the result of the transaction more intuitive as the client
> would know explicitly if the updates where applied or not.
> The following syntax would be considered as invalid:
> 1. select defined both on the top level and in branches
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> SELECT ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 'two', b.value
> UPDATE ...
> ELSE
> SELECT 'three', NULL
> END IF
> COMMIT TRANSACTION
> {code}
> 2. select defined after update - select must be before the update to make it
> clear we select data before modification
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> UPDATE ...
> SELECT 'one', a.value
> ELSE IF condition2 THEN
> UPDATE ...
> SELECT 'two', b.value
> ELSE
> SELECT 'three', NULL
> END IF
> COMMIT TRANSACTION
> {code}
> 3. missing select - if select is defined in a single branch, it has to be
> defined in all branches:
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 'two', b.value
> UPDATE ...
> ELSE
> UPDATE ...
> END IF
> COMMIT TRANSACTION
> {code}
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> END IF
> COMMIT TRANSACTION
> {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-18465) Add support for multiple condition branches and results in Accord transaction
[
https://issues.apache.org/jira/browse/CASSANDRA-18465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18465:
--
Description:
I'd like to propose adding support for multiple branches and result sets for
Accord transactions. It could look like this:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
LET c = ...
IF condition THEN
SELECT 1, a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 2, b.value
UPDATE ...
ELSE
SELECT 3, c.value
END IF
COMMIT TRANSACTION
{code}
The existing syntax would remain valid, when a single {{SELECT}} is defined in
which case the conditional SELECTs would not be valid.
{{SELECT}}s would be validated to return columns of the same type. They would
be able to return literals as well.
This would be make the result of the transaction more intuitive as the client
would know explicitly if the updates where applied or not.
The following syntax would be considered as invalid:
1. {{SELECT}}s defined both on the top level and in branches
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
SELECT ... <
IF condition THEN
SELECT 'one', a.value <
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value <
UPDATE ...
ELSE
SELECT 'three', NULL <
END IF
COMMIT TRANSACTION
{code}
2. {{SELECT}} defined after update - select must be before the update to make
it clear that the data is read before modification
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
UPDATE ...
SELECT 'one', a.value <
ELSE IF condition2 THEN
UPDATE ...
SELECT 'two', b.value
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
3. Missing {{SELECT}} in a conditional branch - if {{SELECT}} is defined in a
any conditional branch, it has to be defined in all branches:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE <
UPDATE ...
END IF
COMMIT TRANSACTION
{code}
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
END IF < (else branch is implicit and it has
no SELECT)
COMMIT TRANSACTION
{code}
Selections in conditional branches will support only returning references - no
support for full query is planned in this ticket.
was:
I'd like to propose adding support for multiple branches and result sets for
Accord transactions. It could look like this:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
The existing syntax would remain valid, when a single SELECT is defined in
which case the conditional SELECTs would not be valid.
SELECTs would be validated to return columns of the same type. They would be
able to return literals as well.
This would be make the result of the transaction more intuitive as the client
would know explicitly if the updates where applied or not.
The following syntax would be considered as invalid:
1. select defined both on the top level and in branches
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
SELECT ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
2. select defined after update - select must be before the update to make it
clear we select data before modification
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
UPDATE ...
SELECT 'one', a.value
ELSE IF condition2 THEN
UPDATE ...
SELECT 'two', b.value
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
3. missing select - if select is defined in a single branch, it has to be
defined in all branches:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE
UPDATE ...
END IF
COMMIT TRANSACTION
{code}
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
END IF
COMMIT TRANSACTION
{code}
> Add support for multiple condition branches and results in Accord transaction
> -
>
> Key: CASSANDRA-18465
> URL: https://issues.
[jira] [Updated] (CASSANDRA-18465) Add support for multiple condition branches and results in Accord transaction
[
https://issues.apache.org/jira/browse/CASSANDRA-18465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18465:
--
Description:
I'd like to propose adding support for multiple branches and result sets for
Accord transactions. It could look like this:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
LET c = ...
IF condition THEN
SELECT 1, a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 2, b.value
UPDATE ...
ELSE
SELECT 3, c.value
END IF
COMMIT TRANSACTION
{code}
The existing syntax would remain valid, when a single SELECT is defined in
which case the conditional SELECTs would not be valid.
SELECTs would be validated to return columns of the same type. They would be
able to return literals as well.
This would be make the result of the transaction more intuitive as the client
would know explicitly if the updates where applied or not.
The following syntax would be considered as invalid:
1. SELECTs defined both on the top level and in branches
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
SELECT ... <
IF condition THEN
SELECT 'one', a.value <
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value <
UPDATE ...
ELSE
SELECT 'three', NULL <
END IF
COMMIT TRANSACTION
{code}
2. SELECT defined after update - select must be before the update to make it
clear that the data is read before modification
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
UPDATE ...
SELECT 'one', a.value <
ELSE IF condition2 THEN
UPDATE ...
SELECT 'two', b.value
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
3. Missing SELECT in a conditional branch - if SELECT is defined in a any
conditional branch, it has to be defined in all branches:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE <
UPDATE ...
END IF
COMMIT TRANSACTION
{code}
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
END IF < (else branch is implicit and it has
no SELECT)
COMMIT TRANSACTION
{code}
Selections in conditional branches will support only returning references - no
support for full query is planned in this ticket.
was:
I'd like to propose adding support for multiple branches and result sets for
Accord transactions. It could look like this:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
LET c = ...
IF condition THEN
SELECT 1, a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 2, b.value
UPDATE ...
ELSE
SELECT 3, c.value
END IF
COMMIT TRANSACTION
{code}
The existing syntax would remain valid, when a single {{SELECT}} is defined in
which case the conditional SELECTs would not be valid.
{{SELECT}}s would be validated to return columns of the same type. They would
be able to return literals as well.
This would be make the result of the transaction more intuitive as the client
would know explicitly if the updates where applied or not.
The following syntax would be considered as invalid:
1. {{SELECT}}s defined both on the top level and in branches
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
SELECT ... <
IF condition THEN
SELECT 'one', a.value <
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value <
UPDATE ...
ELSE
SELECT 'three', NULL <
END IF
COMMIT TRANSACTION
{code}
2. {{SELECT}} defined after update - select must be before the update to make
it clear that the data is read before modification
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
UPDATE ...
SELECT 'one', a.value <
ELSE IF condition2 THEN
UPDATE ...
SELECT 'two', b.value
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
3. Missing {{SELECT}} in a conditional branch - if {{SELECT}} is defined in a
any conditional branch, it has to be defined in all branches:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE <
UPDATE ...
END IF
COMMIT TRANSACTION
{code}
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
END IF <--
[cassandra-website] branch asf-staging updated (18048525 -> b9f4d19a)
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 18048525 generate docs for 8efdf127 new b9f4d19a generate docs for 8efdf127 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 (18048525) \ N -- N -- N refs/heads/asf-staging (b9f4d19a) 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 4796900 -> 4796900 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-18017) Jenkins: Consider using the no-build-test flag
[
https://issues.apache.org/jira/browse/CASSANDRA-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736063#comment-17736063
]
Maxim Muzafarov commented on CASSANDRA-18017:
-
In my humble opinion, we need to treat the checkstyle errors the same as
compile errors, any changes to the source code will require recompiling and, in
turn, running checks against it from scratch. So if the checks are a part of
the build and we do not rebuild the sources before running the tests which is a
good idea, then there is no problem, so the problem that this issue raises
makes sense to me. (btw we had the same discussion in the Apache Ignite
community a few years ago, it was a year-long discussion :-) )
So, back to the issue, I have been talking with Michael and he said that it's
better to focus on CASSANDRA-18133 rather than spending time on this issue :(
I've been doing some testing on 18133 scripts, so I hopefully it will help to
make some progress here too.
> Jenkins: Consider using the no-build-test flag
> --
>
> Key: CASSANDRA-18017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18017
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Maxim Muzafarov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16625 and CASSANDRA-18000 added a {{-Dno-build-test=true}} flag to
> skip the dependencies of the Ant test targets. This is useful to speed up the
> test targets if the {{build-test}} target has already been previously run,
> for example as part of {{{}ant jar{}}}.
> That was created thinking mainly on CircleCI's multiplexer, where we run the
> same test target repeatedly. Skipping the already run depended on targets can
> significantly speed up the tests. The flag however is also useful for all
> other test jobs because every parallel runner can skip the test building
> step, and we have hundreds of parallel runners. Saving around 30s on every
> runner adds up considerable savings.
> Maybe this flag can also be used for skipping test builds on Jenkins too, so
> each parallel test split can benefit from a slight boost. That could be done
> if either {{build-test}} or {{jar}} have already been run before calling the
> test target. I'm not familiarized with Jenkins config so I'm not sure whether
> it makes sense.
--
This message was sent by Atlassian Jira
(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-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736065#comment-17736065
]
Stefan Miklosovic commented on CASSANDRA-18305:
---
[~bschoeni]
why do you think this is important to see?
{code}
minute rate 0.00/second
5 minute rate0.01/second
15 minute rate 0.12/second
mean rate0.01/second
{code}
or as you put it in the description:
{code}
pending tasks: 0
compactions completed: 20
1 minute rate:0/second
5 minute rate:2.3/second
15 minute rate: 4.6/second
{code}
What I mean by that is that I do not see any reason to have these metrics
there, what practical information you get from this? If it was a number of how
many compactions there were in 15 minutes I might get that, but what is useful
in knowing that there was 0.12 compactions per second over 15 minutes?
> 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: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] [Commented] (CASSANDRA-18560) Incorrect IP used for gossip across DCs with prefer_local=true
[
https://issues.apache.org/jira/browse/CASSANDRA-18560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736070#comment-17736070
]
Brandon Williams commented on CASSANDRA-18560:
--
No, I think we have what we need here, but thanks.
> Incorrect IP used for gossip across DCs with prefer_local=true
> --
>
> Key: CASSANDRA-18560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18560
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brad Vernon
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> After installing a new node using 4.0.10 we experienced a situation where the
> new node attempted to connect to the private ip of a random number of nodes
> remote DCs which are only accessible via public ip for cross dc
> communications.
> The only impact was new nodes outbound connections, inbound from pre-4.0.10
> were not affected. system.peers_v2 (below) showed that the preferred_ip and
> preferred_port as null, only those in 4.0.10 nodes dc have perferred_ip
> values as expected.
> We believe the issue originated with
> https://issues.apache.org/jira/browse/CASSANDRA-16718
> Details on cluster:
> * All nodes have public IP configured as well as private IP
> * Listen/rpc addressrs are configured for private ip, broadcast is public IP
> * prefer_local=true is enabled for all nodes
> The log that showed the connection failing:
> {code:java}
> INFO [Messaging-EventLoop-3-8] 2023-06-01 00:14:21,565 NoSpamLogger.java:92
> -
> /99.81.:7000->/44.208.:7000-URGENT_MESSAGES-[no-channel]
> failed to connectio.netty.channel.ConnectTimeoutException: connection timed
> out: /10.26.5.11:7000 at
> io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe$2.run(AbstractEpollChannel.java:576){code}
> 99 and 44 instances can only access each other using public ips.
> gossipinfo output from 4.0.10 node
> {code:java}
> /44.208.
> generation:1661113358
> heartbeat:25267691
> LOAD:25267683:1.7882044268E10
> SCHEMA:24692061:e98b918d-499f-3ccc-8dbe-5af31f685bda
> DC:13:us-east-1
> RACK:15:1a
> RELEASE_VERSION:6:4.0.5
> NET_VERSION:2:12
> HOST_ID:3:9a41e668-060d-4cfe-bb1e-013f5116422d
> RPC_READY:1407:true
> INTERNAL_ADDRESS_AND_PORT:9:10.26.5.11:7000
> NATIVE_ADDRESS_AND_PORT:4:44.208.:9042
> STATUS_WITH_PORT:1393:NORMAL,-2262036356854762881
> SSTABLE_VERSIONS:7:big-nb
> TOKENS:1392: {code}
> Peers output from 4.0.10 node:
> {code:java}
>peer | peer_port | data_center | host_id
> | native_address | native_port | preferred_ip | preferred_port |
> rack | release_version | schema_version |
> tokens+---+-+--++-+--++--+-+--+---
> 44.208. | 7000 | us-east-1 |
> 9a41e668-060d-4cfe-bb1e-013f5116422d | 44.208. |9042 |
> null | null | 1a | 4.0.5 |
> e98b918d-499f-3ccc-8dbe-5af31f685bda |{'-2262036356854762881',
> '-4197710115038136897', '-7072386316096662315', '2085255826742630980',
> '249732489387853170', '4976300208126705818', '7187184456885833289',
> '8777189009399731927'} {code}
> To solve temporarily we routed outbound traffic to the private ip to public
> using iptables which resulted in successful outbound connections.
--
This message was sent by Atlassian Jira
(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-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736076#comment-17736076
]
Brandon Williams commented on CASSANDRA-18305:
--
Whatever we decided to do there, CI looks good so I'm +1. I agree that the
number of compactions in a given interval isn't super useful without more info
like their sizes, which I think tends to mean what you really want to know is
the speed, but we found that is difficult to ascertain.
> 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: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] [Comment Edited] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736076#comment-17736076
]
Brandon Williams edited comment on CASSANDRA-18305 at 6/22/23 11:10 AM:
Whatever we decide to do there, CI looks good so I'm +1. I agree that the
number of compactions in a given interval isn't super useful without more info
like their sizes, which I think tends to mean what you really want to know is
the speed, but we found that is difficult to ascertain.
was (Author: brandon.williams):
Whatever we decided to do there, CI looks good so I'm +1. I agree that the
number of compactions in a given interval isn't super useful without more info
like their sizes, which I think tends to mean what you really want to know is
the speed, but we found that is difficult to ascertain.
> 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: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736077#comment-17736077
]
Stefan Miklosovic commented on CASSANDRA-18305:
---
Thanks [~brandon.williams], I will wait for [~bschoeni] with the answer and we
might finally approach the merge. I am in favor of removing these particular
metrics but maybe Brad has some reasoning behind that.
> 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: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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-12183) compaction_history system table does not capture all historical compaction sessions
[
https://issues.apache.org/jira/browse/CASSANDRA-12183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic reassigned CASSANDRA-12183:
-
Assignee: Stefan Miklosovic
> compaction_history system table does not capture all historical compaction
> sessions
> ---
>
> Key: CASSANDRA-12183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12183
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability, Local/Compaction
>Reporter: Wei Deng
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> It appears that some compaction sessions are not recorded in
> system.compaction_history table after the compaction session successfully
> finishes.
> The following is an example (test by simply running +cassandra-stress write
> n=1+):
> {noformat}
> automaton@wdengdse50google-98425b985-3:~$ nodetool compactionstats
> pending tasks: 46
> id compaction typekeyspace
> tablecompletedtotalunit progress
>fa8a4f30-4884-11e6-b916-1dbd340a212fCompaction keyspace1
> standard1 4233184044 4774209875 bytes 88.67%
>91e30d21-4887-11e6-b916-1dbd340a212fCompaction keyspace1
> standard1836983029889773060 bytes 94.07%
> Active compaction remaining time : 0h00m35s
> automaton@wdengdse50google-98425b985-3:~$ nodetool compactionstats
> pending tasks: 47
> id compaction typekeyspace
> tablecompletedtotalunit progress
>fa8a4f30-4884-11e6-b916-1dbd340a212fCompaction keyspace1
> standard1 4353251539 4774209875 bytes 91.18%
>28359094-4888-11e6-b916-1dbd340a212fCompaction keyspace1
> standard1 49732274 4071652280 bytes 1.22%
> Active compaction remaining time : 0h04m24s
> {noformat}
> At this point you know the previous compaction session
> 91e30d21-4887-11e6-b916-1dbd340a212f finished and confirmation can be found
> from debug.log
> {noformat}
> automaton@wdengdse50google-98425b985-3:~$ grep
> 91e30d21-4887-11e6-b916-1dbd340a212f /var/log/cassandra/debug.log
> DEBUG [CompactionExecutor:4] 2016-07-12 23:22:58,674 CompactionTask.java:146
> - Compacting (91e30d21-4887-11e6-b916-1dbd340a212f)
> [/var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-290-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-279-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-281-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-280-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-284-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-283-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-287-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-292-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-286-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-289-big-Data.db:level=0,
> ]
> DEBUG [CompactionExecutor:4] 2016-07-12 23:26:56,054 CompactionTask.java:217
> - Compacted (91e30d21-4887-11e6-b916-1dbd340a212f) 10 sstables to
> [/var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-293-big,]
> to level=0. 889,773,060 bytes to 890,473,350 (~100% of original) in
> 237,365ms = 3.577703MB/s. 0 total partitions merged to 3,871,921. Partition
> merge counts were {1:3871921, }
> {noformat}
> However, if you query system.compaction_history table or run "nodetool
> compactionhistory | grep 91e30d21-4887-11e6-b916-1dbd340a212f" you will get
> nothing:
> {noformat}
> automaton@wdengdse50google-98425b985-3:~$ cqlsh -u cassandra
> Password:
> Connected to dse50 at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.0.7.1158 | DSE 5.0.0 | CQL spec 3.4.0 | Native
> protocol v4]
> Use HELP for help.
> cassandra@cqlsh> select * from system.compaction_history where
> id=91e30d21-4887-11e6-b916-1dbd340a212f;
> id | bytes_in | bytes_out | columnfamily_name | compacted_at | keyspace_name
> | rows_merged
> +--+---+---+--+---+-
> (0 rows)
> automaton@wdengdse50google-98425b985-3:~$ nodetool flush system
> automaton@wdengdse50google-98425b985-3:~$ nodetool compactionhistory | grep
> 91e30d21-4887-11e6-b916-1dbd340a212f
[jira] [Updated] (CASSANDRA-12183) compaction_history system table does not capture all historical compaction sessions
[
https://issues.apache.org/jira/browse/CASSANDRA-12183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-12183:
--
Fix Version/s: 5.x
> compaction_history system table does not capture all historical compaction
> sessions
> ---
>
> Key: CASSANDRA-12183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12183
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability, Local/Compaction
>Reporter: Wei Deng
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> It appears that some compaction sessions are not recorded in
> system.compaction_history table after the compaction session successfully
> finishes.
> The following is an example (test by simply running +cassandra-stress write
> n=1+):
> {noformat}
> automaton@wdengdse50google-98425b985-3:~$ nodetool compactionstats
> pending tasks: 46
> id compaction typekeyspace
> tablecompletedtotalunit progress
>fa8a4f30-4884-11e6-b916-1dbd340a212fCompaction keyspace1
> standard1 4233184044 4774209875 bytes 88.67%
>91e30d21-4887-11e6-b916-1dbd340a212fCompaction keyspace1
> standard1836983029889773060 bytes 94.07%
> Active compaction remaining time : 0h00m35s
> automaton@wdengdse50google-98425b985-3:~$ nodetool compactionstats
> pending tasks: 47
> id compaction typekeyspace
> tablecompletedtotalunit progress
>fa8a4f30-4884-11e6-b916-1dbd340a212fCompaction keyspace1
> standard1 4353251539 4774209875 bytes 91.18%
>28359094-4888-11e6-b916-1dbd340a212fCompaction keyspace1
> standard1 49732274 4071652280 bytes 1.22%
> Active compaction remaining time : 0h04m24s
> {noformat}
> At this point you know the previous compaction session
> 91e30d21-4887-11e6-b916-1dbd340a212f finished and confirmation can be found
> from debug.log
> {noformat}
> automaton@wdengdse50google-98425b985-3:~$ grep
> 91e30d21-4887-11e6-b916-1dbd340a212f /var/log/cassandra/debug.log
> DEBUG [CompactionExecutor:4] 2016-07-12 23:22:58,674 CompactionTask.java:146
> - Compacting (91e30d21-4887-11e6-b916-1dbd340a212f)
> [/var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-290-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-279-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-281-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-280-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-284-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-283-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-287-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-292-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-286-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-289-big-Data.db:level=0,
> ]
> DEBUG [CompactionExecutor:4] 2016-07-12 23:26:56,054 CompactionTask.java:217
> - Compacted (91e30d21-4887-11e6-b916-1dbd340a212f) 10 sstables to
> [/var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-293-big,]
> to level=0. 889,773,060 bytes to 890,473,350 (~100% of original) in
> 237,365ms = 3.577703MB/s. 0 total partitions merged to 3,871,921. Partition
> merge counts were {1:3871921, }
> {noformat}
> However, if you query system.compaction_history table or run "nodetool
> compactionhistory | grep 91e30d21-4887-11e6-b916-1dbd340a212f" you will get
> nothing:
> {noformat}
> automaton@wdengdse50google-98425b985-3:~$ cqlsh -u cassandra
> Password:
> Connected to dse50 at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.0.7.1158 | DSE 5.0.0 | CQL spec 3.4.0 | Native
> protocol v4]
> Use HELP for help.
> cassandra@cqlsh> select * from system.compaction_history where
> id=91e30d21-4887-11e6-b916-1dbd340a212f;
> id | bytes_in | bytes_out | columnfamily_name | compacted_at | keyspace_name
> | rows_merged
> +--+---+---+--+---+-
> (0 rows)
> automaton@wdengdse50google-98425b985-3:~$ nodetool flush system
> automaton@wdengdse50google-98425b985-3:~$ nodetool compactionhistory | grep
> 91e30d21-4887-11e6-b916-
[jira] [Created] (CASSANDRA-18619) nodetool compaction does not use all available compaction executors
Stefan Miklosovic created CASSANDRA-18619:
-
Summary: nodetool compaction does not use all available compaction
executors
Key: CASSANDRA-18619
URL: https://issues.apache.org/jira/browse/CASSANDRA-18619
Project: Cassandra
Issue Type: Improvement
Reporter: Stefan Miklosovic
Lets have a node with 8 cores and lets do "nodetool setconcurrentcompactors 4"
When I am doing "nodetool garbagecollect", there is a possibility to specify
number of "jobs" via -j flag. If I set it to "2", max two threads will be
compacting, if I set it to 6, it will be in practice capped to 4 as that is my
"concurrentcompactors" setting.
So far good.
However, when I set jobs to 4 and I execute garbagecollecting on two tables,
tb1 and tb2 like this:
{code}
nodetool garbagecollect -j 4 -- keyspace1 tb1 tb2
{code}
What it does is that it will start to gc first table, 4 tables at max AND THEN
it will start to gc the second table.
In other words, if tb1 has 10 tables to gc and I have 4 jobs at max, it will gc
them, but if one looks into compactionstats, she sees that as gc-ing
progresses, there might be e.g. just 2 tables left to gc so in theory there is
a slot for two additional sstables to gc-ed as well but this will not happen.
It will wait until the first table is gc-ed and then it will start to gc the
second one with 4 threds.
This might be improved so as soon as there is a free job thread to gc, next
sstable would be scheduled to be gc-ed even it is from a different cql table.
--
This message was sent by Atlassian Jira
(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-18619) nodetool garbagecollect does not use all available compaction executors
[
https://issues.apache.org/jira/browse/CASSANDRA-18619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18619:
--
Summary: nodetool garbagecollect does not use all available compaction
executors (was: nodetool compaction does not use all available compaction
executors)
> nodetool garbagecollect does not use all available compaction executors
> ---
>
> Key: CASSANDRA-18619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18619
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> Lets have a node with 8 cores and lets do "nodetool setconcurrentcompactors 4"
> When I am doing "nodetool garbagecollect", there is a possibility to specify
> number of "jobs" via -j flag. If I set it to "2", max two threads will be
> compacting, if I set it to 6, it will be in practice capped to 4 as that is
> my "concurrentcompactors" setting.
> So far good.
> However, when I set jobs to 4 and I execute garbagecollecting on two tables,
> tb1 and tb2 like this:
> {code}
> nodetool garbagecollect -j 4 -- keyspace1 tb1 tb2
> {code}
> What it does is that it will start to gc first table, 4 tables at max AND
> THEN it will start to gc the second table.
> In other words, if tb1 has 10 tables to gc and I have 4 jobs at max, it will
> gc them, but if one looks into compactionstats, she sees that as gc-ing
> progresses, there might be e.g. just 2 tables left to gc so in theory there
> is a slot for two additional sstables to gc-ed as well but this will not
> happen. It will wait until the first table is gc-ed and then it will start to
> gc the second one with 4 threds.
> This might be improved so as soon as there is a free job thread to gc, next
> sstable would be scheduled to be gc-ed even it is from a different cql table.
--
This message was sent by Atlassian Jira
(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-18619) nodetool garbagecollect does not use all available compaction executors
[
https://issues.apache.org/jira/browse/CASSANDRA-18619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18619:
--
Description:
Lets have a node with 8 cores and lets do "nodetool setconcurrentcompactors 4"
When I am doing "nodetool garbagecollect", there is a possibility to specify
number of "jobs" via -j flag. If I set it to "2", max two threads will be
compacting, if I set it to 6, it will be in practice capped to 4 as that is my
"concurrentcompactors" setting.
So far good.
However, when I set jobs to 4 and I execute garbagecollecting on two tables,
tb1 and tb2 like this:
{code:java}
nodetool garbagecollect -j 4 -- keyspace1 tb1 tb2
{code}
What it does is that it will start to gc first table, 4 tables at max AND THEN
it will start to gc the second table.
In other words, if tb1 has 10 tables to gc and I have 4 jobs at max, it will gc
them, but if one looks into compactionstats, she sees that as gc-ing
progresses, there might be e.g. just 2 tables left to gc so in theory there is
a slot for two additional sstables to gc as well but this will not happen. It
will wait until the first table is gc-ed and then it will start to gc the
second one with 4 threads.
This might be improved so as soon as there is a free job thread to gc, next
sstable would be scheduled to be gc-ed even it is from a different cql table.
was:
Lets have a node with 8 cores and lets do "nodetool setconcurrentcompactors 4"
When I am doing "nodetool garbagecollect", there is a possibility to specify
number of "jobs" via -j flag. If I set it to "2", max two threads will be
compacting, if I set it to 6, it will be in practice capped to 4 as that is my
"concurrentcompactors" setting.
So far good.
However, when I set jobs to 4 and I execute garbagecollecting on two tables,
tb1 and tb2 like this:
{code}
nodetool garbagecollect -j 4 -- keyspace1 tb1 tb2
{code}
What it does is that it will start to gc first table, 4 tables at max AND THEN
it will start to gc the second table.
In other words, if tb1 has 10 tables to gc and I have 4 jobs at max, it will gc
them, but if one looks into compactionstats, she sees that as gc-ing
progresses, there might be e.g. just 2 tables left to gc so in theory there is
a slot for two additional sstables to gc-ed as well but this will not happen.
It will wait until the first table is gc-ed and then it will start to gc the
second one with 4 threds.
This might be improved so as soon as there is a free job thread to gc, next
sstable would be scheduled to be gc-ed even it is from a different cql table.
> nodetool garbagecollect does not use all available compaction executors
> ---
>
> Key: CASSANDRA-18619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18619
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> Lets have a node with 8 cores and lets do "nodetool setconcurrentcompactors 4"
> When I am doing "nodetool garbagecollect", there is a possibility to specify
> number of "jobs" via -j flag. If I set it to "2", max two threads will be
> compacting, if I set it to 6, it will be in practice capped to 4 as that is
> my "concurrentcompactors" setting.
> So far good.
> However, when I set jobs to 4 and I execute garbagecollecting on two tables,
> tb1 and tb2 like this:
> {code:java}
> nodetool garbagecollect -j 4 -- keyspace1 tb1 tb2
> {code}
> What it does is that it will start to gc first table, 4 tables at max AND
> THEN it will start to gc the second table.
> In other words, if tb1 has 10 tables to gc and I have 4 jobs at max, it will
> gc them, but if one looks into compactionstats, she sees that as gc-ing
> progresses, there might be e.g. just 2 tables left to gc so in theory there
> is a slot for two additional sstables to gc as well but this will not happen.
> It will wait until the first table is gc-ed and then it will start to gc the
> second one with 4 threads.
> This might be improved so as soon as there is a free job thread to gc, next
> sstable would be scheduled to be gc-ed even it is from a different cql table.
--
This message was sent by Atlassian 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 (b9f4d19a -> b37b5e3d)
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 b9f4d19a generate docs for 8efdf127 new b37b5e3d generate docs for 8efdf127 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 (b9f4d19a) \ N -- N -- N refs/heads/asf-staging (b37b5e3d) 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 4796900 -> 4796900 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-12183) compaction_history system table does not capture all historical compaction sessions
[
https://issues.apache.org/jira/browse/CASSANDRA-12183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736101#comment-17736101
]
Stefan Miklosovic commented on CASSANDRA-12183:
---
These ids should be same. I dont see any reason why they should not.
> compaction_history system table does not capture all historical compaction
> sessions
> ---
>
> Key: CASSANDRA-12183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12183
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability, Local/Compaction
>Reporter: Wei Deng
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> It appears that some compaction sessions are not recorded in
> system.compaction_history table after the compaction session successfully
> finishes.
> The following is an example (test by simply running +cassandra-stress write
> n=1+):
> {noformat}
> automaton@wdengdse50google-98425b985-3:~$ nodetool compactionstats
> pending tasks: 46
> id compaction typekeyspace
> tablecompletedtotalunit progress
>fa8a4f30-4884-11e6-b916-1dbd340a212fCompaction keyspace1
> standard1 4233184044 4774209875 bytes 88.67%
>91e30d21-4887-11e6-b916-1dbd340a212fCompaction keyspace1
> standard1836983029889773060 bytes 94.07%
> Active compaction remaining time : 0h00m35s
> automaton@wdengdse50google-98425b985-3:~$ nodetool compactionstats
> pending tasks: 47
> id compaction typekeyspace
> tablecompletedtotalunit progress
>fa8a4f30-4884-11e6-b916-1dbd340a212fCompaction keyspace1
> standard1 4353251539 4774209875 bytes 91.18%
>28359094-4888-11e6-b916-1dbd340a212fCompaction keyspace1
> standard1 49732274 4071652280 bytes 1.22%
> Active compaction remaining time : 0h04m24s
> {noformat}
> At this point you know the previous compaction session
> 91e30d21-4887-11e6-b916-1dbd340a212f finished and confirmation can be found
> from debug.log
> {noformat}
> automaton@wdengdse50google-98425b985-3:~$ grep
> 91e30d21-4887-11e6-b916-1dbd340a212f /var/log/cassandra/debug.log
> DEBUG [CompactionExecutor:4] 2016-07-12 23:22:58,674 CompactionTask.java:146
> - Compacting (91e30d21-4887-11e6-b916-1dbd340a212f)
> [/var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-290-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-279-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-281-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-280-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-284-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-283-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-287-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-292-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-286-big-Data.db:level=0,
>
> /var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-289-big-Data.db:level=0,
> ]
> DEBUG [CompactionExecutor:4] 2016-07-12 23:26:56,054 CompactionTask.java:217
> - Compacted (91e30d21-4887-11e6-b916-1dbd340a212f) 10 sstables to
> [/var/lib/cassandra/data/keyspace1/standard1-9c02e9c1487c11e6b9161dbd340a212f/mb-293-big,]
> to level=0. 889,773,060 bytes to 890,473,350 (~100% of original) in
> 237,365ms = 3.577703MB/s. 0 total partitions merged to 3,871,921. Partition
> merge counts were {1:3871921, }
> {noformat}
> However, if you query system.compaction_history table or run "nodetool
> compactionhistory | grep 91e30d21-4887-11e6-b916-1dbd340a212f" you will get
> nothing:
> {noformat}
> automaton@wdengdse50google-98425b985-3:~$ cqlsh -u cassandra
> Password:
> Connected to dse50 at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.0.7.1158 | DSE 5.0.0 | CQL spec 3.4.0 | Native
> protocol v4]
> Use HELP for help.
> cassandra@cqlsh> select * from system.compaction_history where
> id=91e30d21-4887-11e6-b916-1dbd340a212f;
> id | bytes_in | bytes_out | columnfamily_name | compacted_at | keyspace_name
> | rows_merged
> +--+---+---+--+---+-
> (0 rows)
> automaton@wdengdse50google-98425b985-3:~$ nodetool flush system
>
[jira] [Commented] (CASSANDRA-18017) Jenkins: Consider using the no-build-test flag
[
https://issues.apache.org/jira/browse/CASSANDRA-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736102#comment-17736102
]
Michael Semb Wever commented on CASSANDRA-18017:
bq. It is weird that target `testclasslist` depends on running `checkstyle`. I
think that we should simply fix the `build.xml` and then we would not need to
update the Jenkins scripts.
I agree that the checks and building should be separately invoked ant tasks.
Both should be easy to do locally, and encouraged to be done before push.
I've taken this approach in 18133, with the separate build-jar.sh and
check_code.sh scripts. (Both are just simple layers onto the equivalent ant
targets.
bq. I have been talking with Michael and he said that it's better to focus on
CASSANDRA-18133
I have no objection to the simple patch of separately out the checkstyle call
in build.xml
(my objection was only to patching the jenkins/build scripts, as that requires
time-consuming testing on a custom built jenkins installation)
> Jenkins: Consider using the no-build-test flag
> --
>
> Key: CASSANDRA-18017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18017
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Maxim Muzafarov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16625 and CASSANDRA-18000 added a {{-Dno-build-test=true}} flag to
> skip the dependencies of the Ant test targets. This is useful to speed up the
> test targets if the {{build-test}} target has already been previously run,
> for example as part of {{{}ant jar{}}}.
> That was created thinking mainly on CircleCI's multiplexer, where we run the
> same test target repeatedly. Skipping the already run depended on targets can
> significantly speed up the tests. The flag however is also useful for all
> other test jobs because every parallel runner can skip the test building
> step, and we have hundreds of parallel runners. Saving around 30s on every
> runner adds up considerable savings.
> Maybe this flag can also be used for skipping test builds on Jenkins too, so
> each parallel test split can benefit from a slight boost. That could be done
> if either {{build-test}} or {{jar}} have already been run before calling the
> test target. I'm not familiarized with Jenkins config so I'm not sure whether
> it makes sense.
--
This message was sent by Atlassian Jira
(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-18017) Jenkins: Consider using the no-build-test flag
[
https://issues.apache.org/jira/browse/CASSANDRA-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736102#comment-17736102
]
Michael Semb Wever edited comment on CASSANDRA-18017 at 6/22/23 12:13 PM:
--
bq. It is weird that target `testclasslist` depends on running `checkstyle`. I
think that we should simply fix the `build.xml` and then we would not need to
update the Jenkins scripts.
I agree that the checks and building should be separately invoked ant tasks.
Both should be easy to do locally, and encouraged to be done before push.
I've taken this approach in 18133, with the separate build-jar.sh and
check-code.sh scripts. (Both are just simple layers onto the equivalent ant
targets.
bq. I have been talking with Michael and he said that it's better to focus on
CASSANDRA-18133
I have no objection to the simple patch of separately out the checkstyle call
in build.xml
(my objection was only to patching the jenkins/build scripts, as that requires
time-consuming testing on a custom built jenkins installation)
was (Author: michaelsembwever):
bq. It is weird that target `testclasslist` depends on running `checkstyle`. I
think that we should simply fix the `build.xml` and then we would not need to
update the Jenkins scripts.
I agree that the checks and building should be separately invoked ant tasks.
Both should be easy to do locally, and encouraged to be done before push.
I've taken this approach in 18133, with the separate build-jar.sh and
check_code.sh scripts. (Both are just simple layers onto the equivalent ant
targets.
bq. I have been talking with Michael and he said that it's better to focus on
CASSANDRA-18133
I have no objection to the simple patch of separately out the checkstyle call
in build.xml
(my objection was only to patching the jenkins/build scripts, as that requires
time-consuming testing on a custom built jenkins installation)
> Jenkins: Consider using the no-build-test flag
> --
>
> Key: CASSANDRA-18017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18017
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Maxim Muzafarov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16625 and CASSANDRA-18000 added a {{-Dno-build-test=true}} flag to
> skip the dependencies of the Ant test targets. This is useful to speed up the
> test targets if the {{build-test}} target has already been previously run,
> for example as part of {{{}ant jar{}}}.
> That was created thinking mainly on CircleCI's multiplexer, where we run the
> same test target repeatedly. Skipping the already run depended on targets can
> significantly speed up the tests. The flag however is also useful for all
> other test jobs because every parallel runner can skip the test building
> step, and we have hundreds of parallel runners. Saving around 30s on every
> runner adds up considerable savings.
> Maybe this flag can also be used for skipping test builds on Jenkins too, so
> each parallel test split can benefit from a slight boost. That could be done
> if either {{build-test}} or {{jar}} have already been run before calling the
> test target. I'm not familiarized with Jenkins config so I'm not sure whether
> it makes sense.
--
This message was sent by Atlassian Jira
(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-18017) Jenkins: Consider using the no-build-test flag
[
https://issues.apache.org/jira/browse/CASSANDRA-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736108#comment-17736108
]
Jacek Lewandowski commented on CASSANDRA-18017:
---
https://issues.apache.org/jira/browse/CASSANDRA-18618
> Jenkins: Consider using the no-build-test flag
> --
>
> Key: CASSANDRA-18017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18017
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Maxim Muzafarov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16625 and CASSANDRA-18000 added a {{-Dno-build-test=true}} flag to
> skip the dependencies of the Ant test targets. This is useful to speed up the
> test targets if the {{build-test}} target has already been previously run,
> for example as part of {{{}ant jar{}}}.
> That was created thinking mainly on CircleCI's multiplexer, where we run the
> same test target repeatedly. Skipping the already run depended on targets can
> significantly speed up the tests. The flag however is also useful for all
> other test jobs because every parallel runner can skip the test building
> step, and we have hundreds of parallel runners. Saving around 30s on every
> runner adds up considerable savings.
> Maybe this flag can also be used for skipping test builds on Jenkins too, so
> each parallel test split can benefit from a slight boost. That could be done
> if either {{build-test}} or {{jar}} have already been run before calling the
> test target. I'm not familiarized with Jenkins config so I'm not sure whether
> it makes sense.
--
This message was sent by Atlassian Jira
(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-18467) Update generate-idea-files for J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736109#comment-17736109 ] Michael Semb Wever commented on CASSANDRA-18467: Let's remove the `_maybe_update_idea_to_java17` related stuff that [~psy...@t-online.de] added in trunk. I think that was only oversight and not being aware of what was happening in this ticket. I remain in favour of keeping the jdk version contextual, like is the default for all other ant targets. > Update generate-idea-files for J17 > -- > > Key: CASSANDRA-18467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18467 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Jakub Zytka >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > There was a discussion in CASSANDRA-18258 how to update generate-idea-files. > The final agreement was to create one target to cover both Java 11 and Java > 17. > It will be good to figure out CASSANDRA-18263 and reshuffle arguments and > tasks based on what we decide to use as gc in testing for both Java 11 and > Java 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] [Commented] (CASSANDRA-18618) Update tasks configuration to run checks locally when requested
[ https://issues.apache.org/jira/browse/CASSANDRA-18618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736111#comment-17736111 ] Michael Semb Wever commented on CASSANDRA-18618: what about what replaces eclipse-warnings? and the dependency-check ? > Update tasks configuration to run checks locally when requested > --- > > Key: CASSANDRA-18618 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18618 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently CheckStyle and RAT are run with almost every single Ant target, > which is annoying as when developing locally. The targets should be clear - > "test" - runs the tests, "jar" - builds the project and creates jars, and > then we should have a task "check" which runs all the static analysis, that > is CheckStyle, RAT and Eclipse-Warnings (or whatever we decide to replace > Eclipse-Warnings with). > Such goal should be include in "artifacts" and we should run it instead of > "eclipse-warnings" on CircleCI. This way building, static analysis and > testings are clearly separated. -- This message was sent by Atlassian Jira (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-18467) Update generate-idea-files for J17
[
https://issues.apache.org/jira/browse/CASSANDRA-18467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736119#comment-17736119
]
Ekaterina Dimitrova commented on CASSANDRA-18467:
-
{quote}I remain in favour of keeping the jdk version contextual, like it is the
default for all other ant targets.
{quote}
Let's use this ticket to improve the profiles as suggested in this ticket. JDK
contextual and also the cleaning suggested have value.
I would not suggest we remove it, though, just rework things.
> Update generate-idea-files for J17
> --
>
> Key: CASSANDRA-18467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18467
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Jakub Zytka
>Priority: Low
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There was a discussion in CASSANDRA-18258 how to update generate-idea-files.
> The final agreement was to create one target to cover both Java 11 and Java
> 17.
> It will be good to figure out CASSANDRA-18263 and reshuffle arguments and
> tasks based on what we decide to use as gc in testing for both Java 11 and
> Java 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] [Commented] (CASSANDRA-18618) Update tasks configuration to run checks locally when requested
[ https://issues.apache.org/jira/browse/CASSANDRA-18618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736126#comment-17736126 ] Brandon Williams commented on CASSANDRA-18618: -- Removing the j8 gate on checkstyle will reintroduce the problem in CASSANDRA-18423. > Update tasks configuration to run checks locally when requested > --- > > Key: CASSANDRA-18618 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18618 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Time Spent: 40m > Remaining Estimate: 0h > > Currently CheckStyle and RAT are run with almost every single Ant target, > which is annoying as when developing locally. The targets should be clear - > "test" - runs the tests, "jar" - builds the project and creates jars, and > then we should have a task "check" which runs all the static analysis, that > is CheckStyle, RAT and Eclipse-Warnings (or whatever we decide to replace > Eclipse-Warnings with). > Such goal should be include in "artifacts" and we should run it instead of > "eclipse-warnings" on CircleCI. This way building, static analysis and > testings are clearly separated. -- This message was sent by Atlassian Jira (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-15241) Virtual table to expose current running queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736143#comment-17736143
]
Maxim Muzafarov commented on CASSANDRA-15241:
-
[~maedhroz]
Is there a chance to cherry-pick this change to the 4.1 release as the feature
itself seems to be a valuable one for the end user experience? I have checked
the comments above as to why the feature is only targeted for 5.0, and not for
4.x, and have not been able to find a good technical answer for myself.
Is there a technical problem exist or just a product vision? If both are 'no',
I can prepare a PR for 4.1.
> 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
>
> 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-16895) Build with Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16895:
Description:
This ticket is intended to group all issues found to support Java 17 in the
future.
Upgrade steps:
* [Dependencies
|https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to
be updated (not all but at least those that require an update in order to work
with Java 17)
* More encapsulated JDK internal APIs. Some of the issues might be solved with
the dependencies updates
* Currently trunk compiles if we remove the Nashorn dependency (ant script
tag, used for the test environment; UDFs) . The oracle recommendation to use
Nashorn-core won't work for the project as it is under GPL 2.0. Most probably
we will opt in for graal-sdk licensed under UPL
* All tests to be cleaned
* CI environment to be setup
*NOTE:* GC tuning, performance testing were never agreed to be part of this
ticket.
Below is a snapshot of current CI failures with JDK17, it will be updated on a
regular basis with a date of update
*June 15th 2023*
|| ||Failing Test Classes||Ticket Numbers||
| |_Python DTests_| |
|1|-test_sjk-|CASSANDRA-18343|
| |_Java Ditributed Tests_| |
|1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all
tests,
org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests,
org.apache.cassandra.distributed.test.IPMembershipTest - both tests,
org.apache.cassandra.distributed.test.MixedModeFuzzTest,
org.apache.cassandra.distributed.test.ReprepareFuzzTest,
org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304|
|7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
- all tests
org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all
tests|Both tests suffer from CASSANDRA-18180
fwiw, using the CASSANDRA-18180 branch, only the
negotiatedProtocolMustBeAcceptedProtocolTest fails in both these tests.
EDIT: We will need a ticket for this one post CASSANDRA-18180. TLSv1.1 failed
to negotiate (netty complains about certificate_unknown). Changes in JDK17
config to be checked - done
EDIT2: CASSANDRA-18540
|
|9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - 2
tests|CASSANDRA-18180|
| |_Unit Tests_| |
|1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884|
|2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992|
|3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest,
org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329|
|5,6|org.apache.cassandra.cql3.validation.entities.UFJavaTest,
org.apache.cassandra.cql3.validation.entities.UFSecurityTest|CASSANDRA-18190;
ready to commit; blocked on being ready to drop JDK8|
|7|-org.apache.cassandra.cql3.EmptyValuesTest-|CASSANDRA-18436|
|8|{-}org.apache.cassandra.transport.MessagePayloadTest{-}.jdk17-|CASSANDRA-18437|
| |_Burn tests_| |
|1|org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression|CASSANDRA-18570|
was:
This ticket is intended to group all issues found to support Java 17 in the
future.
Upgrade steps:
* [Dependencies
|https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to
be updated (not all but at least those that require an update in order to work
with Java 17)
* More encapsulated JDK internal APIs. Some of the issues might be solved with
the dependencies updates
* Currently trunk compiles if we remove the Nashorn dependency (ant script
tag, used for the test environment; UDFs) . The oracle recommendation to use
Nashorn-core won't work for the project as it is under GPL 2.0. Most probably
we will opt in for graal-sdk licensed under UPL
* All tests to be cleaned
* CI environment to be setup
*NOTE:* GC tuning, performance testing were never agreed to be part of this
ticket.
Below is a snapshot of current CI failures with JDK17, it will be updated on a
regular basis with a date of update
*June 15th 2023*
|| ||Failing Test Classes||Ticket Numbers||
| |_Python DTests_| |
|1|-test_sjk-|CASSANDRA-18343|
| |_Java Ditributed Tests_| |
|1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all
tests,
org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests,
org.apache.cassandra.distributed.test.IPMembershipTest - both tests,
org.apache.cassandra.distributed.test.MixedModeFuzzTest,
org.apache.cassandra.distributed.test.ReprepareFuzzTest,
org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304|
|7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
- all tests
org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all
tests|Both tests suffer from CASSANDRA-18180
fwiw, using the CASSANDRA-18180 branch, only the
negotiatedProtocolMustBeAcce
[jira] [Updated] (CASSANDRA-16895) Build with Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16895:
Description:
This ticket is intended to group all issues found to support Java 17 in the
future.
Upgrade steps:
* [Dependencies
|https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to
be updated (not all but at least those that require an update in order to work
with Java 17)
* More encapsulated JDK internal APIs. Some of the issues might be solved with
the dependencies updates
* Currently trunk compiles if we remove the Nashorn dependency (ant script
tag, used for the test environment; UDFs) . The oracle recommendation to use
Nashorn-core won't work for the project as it is under GPL 2.0. Most probably
we will opt in for graal-sdk licensed under UPL
* All tests to be cleaned
* CI environment to be setup
*NOTE:* GC tuning, performance testing were never agreed to be part of this
ticket.
Below is a snapshot of current CI failures with JDK17, it will be updated on a
regular basis with a date of update
*June 15th 2023*
|| ||Failing Test Classes||Ticket Numbers||
| |_Python DTests_| |
|1|-test_sjk-|CASSANDRA-18343|
| |_Java Ditributed Tests_| |
|1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all
tests,
org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests,
org.apache.cassandra.distributed.test.IPMembershipTest - both tests,
org.apache.cassandra.distributed.test.MixedModeFuzzTest,
org.apache.cassandra.distributed.test.ReprepareFuzzTest,
org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304|
|7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
- all tests
org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all
tests|Both tests suffer from CASSANDRA-18180
fwiw, using the CASSANDRA-18180 branch, only the
negotiatedProtocolMustBeAcceptedProtocolTest fails in both these tests.
EDIT: We will need a ticket for this one post CASSANDRA-18180. TLSv1.1 failed
to negotiate (netty complains about certificate_unknown). Changes in JDK17
config to be checked - done
EDIT2: CASSANDRA-18540
|
|9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - 2
tests|CASSANDRA-18180|
| |_Unit Tests_| |
|1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884|
|2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992|
|3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest,
org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329|
|5,6|-org.apache.cassandra.cql3.validation.entities.UFJavaTest,-
-org.apache.cassandra.cql3.validation.entities.UFSecurityTest-|CASSANDRA-18190;
ready to commit; blocked on being ready to drop JDK8|
|7|-org.apache.cassandra.cql3.EmptyValuesTest-|CASSANDRA-18436|
|8|{-}org.apache.cassandra.transport.MessagePayloadTest{-}.jdk17-|CASSANDRA-18437|
| |_Burn tests_| |
|1|org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression|CASSANDRA-18570|
was:
This ticket is intended to group all issues found to support Java 17 in the
future.
Upgrade steps:
* [Dependencies
|https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to
be updated (not all but at least those that require an update in order to work
with Java 17)
* More encapsulated JDK internal APIs. Some of the issues might be solved with
the dependencies updates
* Currently trunk compiles if we remove the Nashorn dependency (ant script
tag, used for the test environment; UDFs) . The oracle recommendation to use
Nashorn-core won't work for the project as it is under GPL 2.0. Most probably
we will opt in for graal-sdk licensed under UPL
* All tests to be cleaned
* CI environment to be setup
*NOTE:* GC tuning, performance testing were never agreed to be part of this
ticket.
Below is a snapshot of current CI failures with JDK17, it will be updated on a
regular basis with a date of update
*June 15th 2023*
|| ||Failing Test Classes||Ticket Numbers||
| |_Python DTests_| |
|1|-test_sjk-|CASSANDRA-18343|
| |_Java Ditributed Tests_| |
|1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all
tests,
org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests,
org.apache.cassandra.distributed.test.IPMembershipTest - both tests,
org.apache.cassandra.distributed.test.MixedModeFuzzTest,
org.apache.cassandra.distributed.test.ReprepareFuzzTest,
org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304|
|7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
- all tests
org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all
tests|Both tests suffer from CASSANDRA-18180
fwiw, using the CASSANDRA-18180 branch, only the
negotiatedProtocolMustBe
[cassandra-website] branch asf-staging updated (b37b5e3d -> 726038ff)
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 b37b5e3d generate docs for 8efdf127 new 726038ff generate docs for 8efdf127 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 (b37b5e3d) \ N -- N -- N refs/heads/asf-staging (726038ff) 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 4796900 -> 4796900 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-17254) nodetool toppartitions can fail because ByteBuffer.array() returns more bytes than would be considered valid by UTF8Serializer.validate
[
https://issues.apache.org/jira/browse/CASSANDRA-17254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17254:
-
Reviewers: Brandon Williams, Cheng Wang (was: Cheng Wang)
> nodetool toppartitions can fail because ByteBuffer.array() returns more bytes
> than would be considered valid by UTF8Serializer.validate
> ---
>
> Key: CASSANDRA-17254
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17254
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 3.0.29
>
>
> The error below is caused by the use of
> [{{ByteBuffer.array()}}|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L1628].
> Doing so not only makes the hex key potentially incorrect but causes invalid
> data to be passed to {{AbstractType.getString}} and ultimately
> {{UTF8Validator.validate}}.
> {code}
> error: String didn't validate.
> -- StackTrace --
> org.apache.cassandra.serializers.MarshalException: String didn't validate.
> at
> org.apache.cassandra.serializers.UTF8Serializer.validate(UTF8Serializer.java:35)
> at
> org.apache.cassandra.db.marshal.AbstractType.getString(AbstractType.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.finishLocalSampling(ColumnFamilyStore.java:1633)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {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-17711) Create a new node tool supporting force compaction of a partition
[
https://issues.apache.org/jira/browse/CASSANDRA-17711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17711:
-
Reviewers: Jordan West, Sumanth Pasupuleti (was: Jordan West)
> Create a new node tool supporting force compaction of a partition
> -
>
> Key: CASSANDRA-17711
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17711
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Cheng Wang
>Assignee: Cheng Wang
>Priority: Normal
> Fix For: 5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to create new tool called {*}nodetool forcecompact{*}. The syntax of the
> command is
> *nodetool forcecompact keyspace table gc_grace_seconds>.*
> One of the use cases of the tool is to handle the bad partitions which may
> contain too many tombstones. The tool will compact all the sstables
> containing the partition keys. In addition, by ignoring the
> {*}gc_grace_seconds{*}, it will help purge the tombstones faster.
--
This message was sent by Atlassian Jira
(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-18518) NullPointerException in cassandra.audit.AuditLogManager.querySuccess when querying endpoints via mgmtapi
[
https://issues.apache.org/jira/browse/CASSANDRA-18518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18518:
-
Bug Category: Parent values: Correctness(12982)Level 1 values: Transient
Incorrect Response(12987)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 4.1.x
5.x
Severity: Normal
Status: Open (was: Triage Needed)
> NullPointerException in cassandra.audit.AuditLogManager.querySuccess when
> querying endpoints via mgmtapi
> -
>
> Key: CASSANDRA-18518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18518
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vanessa Haro
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> NullPointerException in cassandra.audit.AuditLogManager.querySuccess when
> querying endpoints via mgmtapi
>
> cassandra version: 4.1.1
> cassandra.yaml:audit_logging_options:
> cassandra.yaml- enabled: true
> cassandra.yaml- logger:
> cassandra.yaml: - class_name: FileAuditLogger
>
> When querying endpoints (/api/v0/metadata/endpoints) via mgmtapi, 200 OK is
> returned. However, NPE is reported by AuditLogManager.
> {code:java}
> ERROR [epollEventLoopGroup-5-3] 2023-05-10 15:53:30,301 NoSpamLogger.java:111
> - Failed notifying listeners
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.audit.AuditLogManager.querySuccess(AuditLogManager.java:244)
> at
> org.apache.cassandra.cql3.QueryEvents.notifyQuerySuccess(QueryEvents.java:78)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:117)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:254)
> at
> org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:106)
> at
> org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:86)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollDomainSocketChannel$EpollDomainUnsafe.epollInReady(EpollDomainSocketChannel.java:138)
> at
> io
[jira] [Updated] (CASSANDRA-18504) Added support for type VECTOR
[ https://issues.apache.org/jira/browse/CASSANDRA-18504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18504: -- Status: Ready to Commit (was: Review In Progress) > Added support for type VECTOR > -- > > Key: CASSANDRA-18504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18504 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema, CQL/Syntax >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.x > > Time Spent: 20.5h > Remaining Estimate: 0h > > Based off several mailing list threads (see "[POLL] Vector type for ML”, > "[DISCUSS] New data type for vector search”, and "Adding vector search to SAI > with heirarchical navigable small world graph index”), its desirable to add a > new type “VECTOR” that has the following properties > 1) fixed length array > 2) elements may not be null > 3) flatten array (aka multi-cell = false) -- This message was sent by Atlassian Jira (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-18504) Added support for type VECTOR
[ https://issues.apache.org/jira/browse/CASSANDRA-18504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18504: -- Fix Version/s: 5.0 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/ae537abc6494564d7254a2126465522d86b44c1e Resolution: Fixed Status: Resolved (was: Ready to Commit) > Added support for type VECTOR > -- > > Key: CASSANDRA-18504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18504 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema, CQL/Syntax >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.0 > > Time Spent: 20.5h > Remaining Estimate: 0h > > Based off several mailing list threads (see "[POLL] Vector type for ML”, > "[DISCUSS] New data type for vector search”, and "Adding vector search to SAI > with heirarchical navigable small world graph index”), its desirable to add a > new type “VECTOR” that has the following properties > 1) fixed length array > 2) elements may not be null > 3) flatten array (aka multi-cell = false) -- This message was sent by Atlassian Jira (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-18599) Cassandra Analytics - Upgrade to use JUnit 5
[ https://issues.apache.org/jira/browse/CASSANDRA-18599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735922#comment-17735922 ] Yifan Cai edited comment on CASSANDRA-18599 at 6/22/23 4:22 PM: Thanks for providing the additional patch [~frankgh]! I just rebased and triggered CI at https://app.circleci.com/pipelines/github/yifan-c/cassandra-analytics?branch=CASSANDRA-18599-ci -- Update -- CI is green was (Author: yifanc): Thanks for providing the additional patch [~frankgh]! I just rebased and triggered CI at https://app.circleci.com/pipelines/github/yifan-c/cassandra-analytics?branch=CASSANDRA-18599-ci > Cassandra Analytics - Upgrade to use JUnit 5 > > > Key: CASSANDRA-18599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18599 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Doug Rohrer >Assignee: Doug Rohrer >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > For future work, we’d like to use some features only available in JUnit 5 > (TestTemplates being the immediate need). > Upgrade cassandra-analytics dependencies to JUnit 5 and fix any test issues. -- This message was sent by Atlassian Jira (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-18599) Cassandra Analytics - Upgrade to use JUnit 5
[ https://issues.apache.org/jira/browse/CASSANDRA-18599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-18599: -- Fix Version/s: NA Source Control Link: https://github.com/apache/cassandra-analytics/commit/bd0b41fb82134844a15fbb43126424d96706d08e Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as [bd0b41fb|https://github.com/apache/cassandra-analytics/commit/bd0b41fb82134844a15fbb43126424d96706d08e] > Cassandra Analytics - Upgrade to use JUnit 5 > > > Key: CASSANDRA-18599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18599 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Doug Rohrer >Assignee: Doug Rohrer >Priority: Normal > Fix For: NA > > Time Spent: 10m > Remaining Estimate: 0h > > For future work, we’d like to use some features only available in JUnit 5 > (TestTemplates being the immediate need). > Upgrade cassandra-analytics dependencies to JUnit 5 and fix any test issues. -- This message was sent by Atlassian Jira (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] (CASSANDRASC-58) Support retries in Sidecar Client when MD5 checksum is mismatched
Francisco Guerrero created CASSANDRASC-58: - Summary: Support retries in Sidecar Client when MD5 checksum is mismatched Key: CASSANDRASC-58 URL: https://issues.apache.org/jira/browse/CASSANDRASC-58 Project: Sidecar for Apache Cassandra Issue Type: Improvement Reporter: Francisco Guerrero Assignee: Francisco Guerrero In rare occasions an SSTable upload will get corrupted during upload. Bit flips are expected to occur occasionally while transmitting the SSTables from the client to the server. The current behavior of the Sidecar Client in those situations is to fail fast without any retries. We want to support Sidecar Client retries when checksum mismatch occurs during SSTable upload. -- This message was sent by Atlassian Jira (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-18107) CEP-15: Multi-Partition Transaction CQL Support (Alpha -> v1)
[
https://issues.apache.org/jira/browse/CASSANDRA-18107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736196#comment-17736196
]
Caleb Rackliffe commented on CASSANDRA-18107:
-
Removed metrics items from the description above, as those should be taken care
of in CASSANDRA-18580.
> CEP-15: Multi-Partition Transaction CQL Support (Alpha -> v1)
> -
>
> Key: CASSANDRA-18107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18107
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Semantics, CQL/Syntax
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: NA
>
>
> With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
> available in the
> [cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
> branch. There are, however, a number of features and enhancements that we
> would still like to add before we make it available to users. Here is a
> summary of those items, broadly categorized:
> *Error Messages and UX*
> - Fix the element/field names in result metadata to match the user query
> - Better error messages
> -- Append/subtracting to/from frozen list
> -- attempts to use reference in WHERE clause
> -- LET using a reserved word
> *Domain Object Cleanup*
> - Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
> rather than hard coding data conversion cases
> - Separate current current {{LET}} statement from {{SelectStatement}}, likely
> as a new {{LetStatement}} that names a {{SelectStatement}}
> - Explore unifying {{Operation}} and {{ReferenceOperation}}
> - Include non-Row items of {{FilteredPartition}} in
> {{TxnData#estimatedSizeOnHeap()}}
> - Explore possibility of making {{Bound}} serializable and using it directly
> in {{TxnCondition}}
> - Change internal representation of {{TxnDataName}} to avoid {{String}} ->
> {{ByteBuffer}} conversions
> - Have {{TxnCondition}}/{{TxnUpdate}} support {{slice()}} to full take
> advantage of partial state replication
> - Update serialization logic to reflect CASSANDRA-18099
> *Testing*
> - Figure out the original intent of placeholder tests in
> {{AccordIntegrationTest}} (ex. {{acceptInvalidationTest()}})
> - Remove hack in {{AccordConfigurationService}} (when we have Transactional
> Metadata)
> - Verify concretely that we disable Guardrails.
> - Audit the way we propagate timestamps through execution.
> *Features*
> - Full JSON support
> - Final decision of whether we should support returning the result of an
> {{IF}}/condition
> - Constant terms on the RHS of LET
> - Support for having a reference on both LHS and RHS of {{IF}} predicates
> - Support for {{CONTAINS}}, {{CONTAINS KEY}}, and {{IN}} (important for CAS
> parity)
> - Nested UDT support
> - Mixed conditional and unconditional updates (should this be post-v1?)
> - Arithmetic operations on references in {{INSERT}}/{{UPDATE}} (ex. INSERT
> INTO ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
> *Tooling*
> - Eliminate {{nodetool createepochunsafe}} once transactional metadata is
> available.
> *Documentation*
> - CQL language documentation and bump the CQL language specification version
> - JavaDoc for all new statement classes
> - Integrate {{demo.txt}} into broader documentation somewhere or remove
> *Questions*
> - How should txn statement parsing/preparation handle TTLs specified in
> updates?
> - At what level do we want to integrate tracing?
--
This message was sent by Atlassian Jira
(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-18107) CEP-15: Multi-Partition Transaction CQL Support (Alpha -> v1)
[
https://issues.apache.org/jira/browse/CASSANDRA-18107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18107:
Description:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{SelectStatement}}, likely
as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly in
{{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{TxnCondition}}/{{TxnUpdate}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{acceptInvalidationTest()}})
- Remove hack in {{AccordConfigurationService}} (when we have Transactional
Metadata)
- Verify concretely that we disable Guardrails.
- Audit the way we propagate timestamps through execution.
*Features*
- Full JSON support
- Final decision of whether we should support returning the result of an
{{IF}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{CONTAINS}}, {{CONTAINS KEY}}, and {{IN}} (important for CAS
parity)
- Nested UDT support
- Mixed conditional and unconditional updates (should this be post-v1?)
- Arithmetic operations on references in {{INSERT}}/{{UPDATE}} (ex. INSERT INTO
ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
*Tooling*
- Eliminate {{nodetool createepochunsafe}} once transactional metadata is
available.
*Documentation*
- CQL language documentation and bump the CQL language specification version
- JavaDoc for all new statement classes
- Integrate {{demo.txt}} into broader documentation somewhere or remove
*Questions*
- How should txn statement parsing/preparation handle TTLs specified in updates?
- At what level do we want to integrate tracing?
was:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{SelectStatement}}, likely
as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly in
{{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{TxnCondition}}/{{TxnUpdate}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{acceptInvalidationTest()}})
- Remove hack in {{AccordConfigurationService}} (when we have Transactional
Metadata)
- Verify concretely that we disable Guardrails.
- Audit the way we propagate timestamps through execution.
*Features*
- Full JSON support
- Final decision of whether we should support returning the result of an
{{IF}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{CONTAINS}}, {{CONTAINS KEY}}, and {{IN}} (important for CAS
parity)
[jira] [Updated] (CASSANDRASC-58) Support retries in Sidecar Client when MD5 checksum is mismatched
[ https://issues.apache.org/jira/browse/CASSANDRASC-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRASC-58: -- Change Category: Semantic Complexity: Normal Component/s: Configuration Status: Open (was: Triage Needed) > Support retries in Sidecar Client when MD5 checksum is mismatched > - > > Key: CASSANDRASC-58 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-58 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > > In rare occasions an SSTable upload will get corrupted during upload. Bit > flips are expected to occur occasionally while transmitting the SSTables from > the client to the server. The current behavior of the Sidecar Client in those > situations is to fail fast without any retries. > We want to support Sidecar Client retries when checksum mismatch occurs > during SSTable upload. -- This message was sent by Atlassian Jira (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-18467) Update generate-idea-files for J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18467: -- Reviewers: Ekaterina Dimitrova, Michael Semb Wever (was: Ekaterina Dimitrova, Michael Semb Wever, Stefan Miklosovic) > Update generate-idea-files for J17 > -- > > Key: CASSANDRA-18467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18467 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Jakub Zytka >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > There was a discussion in CASSANDRA-18258 how to update generate-idea-files. > The final agreement was to create one target to cover both Java 11 and Java > 17. > It will be good to figure out CASSANDRA-18263 and reshuffle arguments and > tasks based on what we decide to use as gc in testing for both Java 11 and > Java 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] [Updated] (CASSANDRA-18608) snappy-java vulnerability: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453
[
https://issues.apache.org/jira/browse/CASSANDRA-18608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18608:
-
Summary: snappy-java vulnerability: CVE-2023-34455, CVE-2023-34454,
CVE-2023-34453 (was: snappy-java vulnerability: CVE-2023-34455)
> snappy-java vulnerability: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453
> -
>
> Key: CASSANDRA-18608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18608
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Compression
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> Failing owasp:
> [https://nvd.nist.gov/vuln/detail/CVE-2023-34455]
> {quote}Due to use of an unchecked chunk length, an unrecoverable fatal error
> can occur in versions prior to 1.1.10.1.
> {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-18609) snappy-java vulnerability: CVE-2023-34453
[ https://issues.apache.org/jira/browse/CASSANDRA-18609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18609: - Resolution: Fixed Status: Resolved (was: Open) Going to handle these together on CASSANDRA-18608 > snappy-java vulnerability: CVE-2023-34453 > - > > Key: CASSANDRA-18609 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18609 > Project: Cassandra > Issue Type: Bug > Components: Feature/Compression >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > Failing owasp: > [https://nvd.nist.gov/vuln/detail/CVE-2023-34453] > bq. Due to unchecked multiplications, an integer overflow may occur in > versions prior to 1.1.10.1, causing a fatal error. -- This message was sent by Atlassian Jira (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-18608) snappy-java vulnerability: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453
[
https://issues.apache.org/jira/browse/CASSANDRA-18608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18608:
-
Description:
Failing owasp:
[https://nvd.nist.gov/vuln/detail/CVE-2023-34455]
{quote}Due to use of an unchecked chunk length, an unrecoverable fatal error
can occur in versions prior to 1.1.10.1.
{quote}
[https://nvd.nist.gov/vuln/detail/CVE-2023-34454]
{quote}Due to unchecked multiplications, an integer overflow may occur in
versions prior to 1.1.10.1, causing an unrecoverable fatal error.
{quote}
[https://nvd.nist.gov/vuln/detail/CVE-2023-34453]
{quote}Due to unchecked multiplications, an integer overflow may occur in
versions prior to 1.1.10.1, causing a fatal error.
{quote}
was:
Failing owasp:
[https://nvd.nist.gov/vuln/detail/CVE-2023-34455]
{quote}Due to use of an unchecked chunk length, an unrecoverable fatal error
can occur in versions prior to 1.1.10.1.
{quote}
> snappy-java vulnerability: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453
> -
>
> Key: CASSANDRA-18608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18608
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Compression
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> Failing owasp:
> [https://nvd.nist.gov/vuln/detail/CVE-2023-34455]
> {quote}Due to use of an unchecked chunk length, an unrecoverable fatal error
> can occur in versions prior to 1.1.10.1.
> {quote}
> [https://nvd.nist.gov/vuln/detail/CVE-2023-34454]
> {quote}Due to unchecked multiplications, an integer overflow may occur in
> versions prior to 1.1.10.1, causing an unrecoverable fatal error.
> {quote}
> [https://nvd.nist.gov/vuln/detail/CVE-2023-34453]
> {quote}Due to unchecked multiplications, an integer overflow may occur in
> versions prior to 1.1.10.1, causing a fatal error.
> {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] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736203#comment-17736203
]
Brad Schoening commented on CASSANDRA-18305:
[~smiklosovic] I suggested these rate metrics because they are some of the very
few JMX compaction metrics available. They're the best approximation of a trend
line we have, but I agree, they're not all that useful.
The mean rate is since the server started, and I could see comparing the
current rate to the mean could be somewhat useful.
It would be much better to have the Meter measure compaction throughput in
Mbps. Especially since that value has a throttle in the cassandra.yaml.
[~brandon.williams] why was it difficult to have compaction throughput (Mbps)
as a JMX Meter?
Normalizing the values to minutes would be good. It's per/sec only because
that's what a Dropwizard Meter measures. Given the skimpy metrics we have,
having just a) mean and b)15 minute rate reported per/minute.
> 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: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] [Commented] (CASSANDRA-15241) Virtual table to expose current running queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736204#comment-17736204
]
Caleb Rackliffe commented on CASSANDRA-15241:
-
[~mmuzaf] I don't think there was any technical reason for not including it in
4.1, but we would likely stumble into one very quickly on trying to back-port
if one did exist ;)
If you want to put together a quick PR, I can review.
> 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
>
> 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] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736213#comment-17736213
]
Stefan Miklosovic commented on CASSANDRA-18305:
---
So if I understood that correctly, you would like to see just this and we would
leave out 5m and 1m metrics?
{code:java}
15 minute rate7.2/minute (that would be 0.12/s * 60s)
mean rate 6/minute (that would be 0.01/s * 60s) {code}
I am still not completely convinced this makes sense to report but anyway
Maybe we should omit them for now and dedicate a separate ticket where we take
a look more holistically instead of introducing something which will be later
down the road hard to get rid of as we are adding to nodetool output which is
very delicate matter. We can always and something if it turns out to be
necessary.
> 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: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] [Commented] (CASSANDRA-18608) snappy-java vulnerability: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453
[
https://issues.apache.org/jira/browse/CASSANDRA-18608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736215#comment-17736215
]
Brandon Williams commented on CASSANDRA-18608:
--
Patch to suppress.
||Branch||CI||
|[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18608-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1074/workflows/2006f093-f5c6-4c00-9dd8-96afb295b36e]|
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18608-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1073/workflows/be711171-c039-47e7-9f7d-07297682372c]|
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18608-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1071/workflows/b10406d4-c0c7-412f-bddc-5298544ef811],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1071/workflows/c11a6de4-0660-4558-a5cf-1de4ee90febc]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18608-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1070/workflows/e19133de-750c-4676-83bb-a67fbcc88aa4],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1070/workflows/fce93d27-1d3a-4ebf-a27e-ec657fabc52f]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18608-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1072/workflows/f9c88208-04b6-466b-b692-4be3bff9a575],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1072/workflows/0dbd2dc5-02a3-4cc6-84a0-29ff766524ce]|
> snappy-java vulnerability: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453
> -
>
> Key: CASSANDRA-18608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18608
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Compression
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> Failing owasp:
> [https://nvd.nist.gov/vuln/detail/CVE-2023-34455]
> {quote}Due to use of an unchecked chunk length, an unrecoverable fatal error
> can occur in versions prior to 1.1.10.1.
> {quote}
> [https://nvd.nist.gov/vuln/detail/CVE-2023-34454]
> {quote}Due to unchecked multiplications, an integer overflow may occur in
> versions prior to 1.1.10.1, causing an unrecoverable fatal error.
> {quote}
> [https://nvd.nist.gov/vuln/detail/CVE-2023-34453]
> {quote}Due to unchecked multiplications, an integer overflow may occur in
> versions prior to 1.1.10.1, causing a fatal error.
> {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] [Comment Edited] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736213#comment-17736213
]
Stefan Miklosovic edited comment on CASSANDRA-18305 at 6/22/23 5:11 PM:
So if I understood that correctly, you would like to see just this and we would
leave out 5m and 1m metrics?
{code:java}
15 minute rate7.2/minute (that would be 0.12/s * 60s)
mean rate 6/minute (that would be 0.01/s * 60s) {code}
I am still not completely convinced this makes sense to report but anyway
Maybe we should omit them for now and dedicate a separate ticket where we take
a look more holistically instead of introducing something which will be later
down the road hard to get rid of as we are adding to nodetool output which is
very delicate matter. We can always add something if it turns out to be
necessary.
was (Author: smiklosovic):
So if I understood that correctly, you would like to see just this and we would
leave out 5m and 1m metrics?
{code:java}
15 minute rate7.2/minute (that would be 0.12/s * 60s)
mean rate 6/minute (that would be 0.01/s * 60s) {code}
I am still not completely convinced this makes sense to report but anyway
Maybe we should omit them for now and dedicate a separate ticket where we take
a look more holistically instead of introducing something which will be later
down the road hard to get rid of as we are adding to nodetool output which is
very delicate matter. We can always and something if it turns out to be
necessary.
> 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: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736217#comment-17736217
]
Brandon Williams commented on CASSANDRA-18305:
--
bq. why was it difficult to have compaction throughput (Mbps) as a JMX Meter?
Guava's RateLimiter doesn't expose this information which means we will have to
build the machinery to collect it, which I imagine will involve capturing
timings inside critical pieces of code.
> 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: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] [Comment Edited] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736217#comment-17736217
]
Brandon Williams edited comment on CASSANDRA-18305 at 6/22/23 5:15 PM:
---
bq. why was it difficult to have compaction throughput (Mbps) as a JMX Meter?
Guava's RateLimiter doesn't expose this information which means we will have to
build the machinery to collect it, which I imagine will involve capturing
timings inside critical pieces of code. That is probably worthy of it's own
ticket, it won't be a simple addition of already exposed metrics.
was (Author: brandon.williams):
bq. why was it difficult to have compaction throughput (Mbps) as a JMX Meter?
Guava's RateLimiter doesn't expose this information which means we will have to
build the machinery to collect it, which I imagine will involve capturing
timings inside critical pieces of code.
> 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: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] [Created] (CASSANDRA-18620) Gossip unstable with istio service meshin 4.1.2
Vanessa Haro created CASSANDRA-18620:
Summary: Gossip unstable with istio service meshin 4.1.2
Key: CASSANDRA-18620
URL: https://issues.apache.org/jira/browse/CASSANDRA-18620
Project: Cassandra
Issue Type: Bug
Components: Tool/auditlogging
Reporter: Vanessa Haro
Fix For: 4.1.x, 5.x
NullPointerException in cassandra.audit.AuditLogManager.querySuccess when
querying endpoints via mgmtapi
cassandra version: 4.1.1
cassandra.yaml:audit_logging_options:
cassandra.yaml- enabled: true
cassandra.yaml- logger:
cassandra.yaml: - class_name: FileAuditLogger
When querying endpoints (/api/v0/metadata/endpoints) via mgmtapi, 200 OK is
returned. However, NPE is reported by AuditLogManager.
{code:java}
ERROR [epollEventLoopGroup-5-3] 2023-05-10 15:53:30,301 NoSpamLogger.java:111 -
Failed notifying listeners
java.lang.NullPointerException: null
at
org.apache.cassandra.audit.AuditLogManager.querySuccess(AuditLogManager.java:244)
at
org.apache.cassandra.cql3.QueryEvents.notifyQuerySuccess(QueryEvents.java:78)
at
org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:117)
at
org.apache.cassandra.transport.Message$Request.execute(Message.java:254)
at
org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:106)
at
org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:86)
at
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at
io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
at
io.netty.channel.epoll.EpollDomainSocketChannel$EpollDomainUnsafe.epollInReady(EpollDomainSocketChannel.java:138)
at
io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h.
[jira] [Updated] (CASSANDRA-18620) Gossip unstable with istio service meshin 4.1.2
[
https://issues.apache.org/jira/browse/CASSANDRA-18620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vanessa Haro updated CASSANDRA-18620:
-
Fix Version/s: (was: 5.x)
(was: 4.1.x)
> Gossip unstable with istio service meshin 4.1.2
> ---
>
> Key: CASSANDRA-18620
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18620
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vanessa Haro
>Priority: Normal
>
> NullPointerException in cassandra.audit.AuditLogManager.querySuccess when
> querying endpoints via mgmtapi
>
> cassandra version: 4.1.1
> cassandra.yaml:audit_logging_options:
> cassandra.yaml- enabled: true
> cassandra.yaml- logger:
> cassandra.yaml: - class_name: FileAuditLogger
>
> When querying endpoints (/api/v0/metadata/endpoints) via mgmtapi, 200 OK is
> returned. However, NPE is reported by AuditLogManager.
> {code:java}
> ERROR [epollEventLoopGroup-5-3] 2023-05-10 15:53:30,301 NoSpamLogger.java:111
> - Failed notifying listeners
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.audit.AuditLogManager.querySuccess(AuditLogManager.java:244)
> at
> org.apache.cassandra.cql3.QueryEvents.notifyQuerySuccess(QueryEvents.java:78)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:117)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:254)
> at
> org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:106)
> at
> org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:86)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollDomainSocketChannel$EpollDomainUnsafe.epollInReady(EpollDomainSocketChannel.java:138)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.net
[jira] [Updated] (CASSANDRA-18620) Gossip unstable with istio service mesh in 4.1.2
[
https://issues.apache.org/jira/browse/CASSANDRA-18620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vanessa Haro updated CASSANDRA-18620:
-
Component/s: Cluster/Gossip
> Gossip unstable with istio service mesh in 4.1.2
>
>
> Key: CASSANDRA-18620
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18620
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Vanessa Haro
>Priority: Normal
>
> NullPointerException in cassandra.audit.AuditLogManager.querySuccess when
> querying endpoints via mgmtapi
>
> cassandra version: 4.1.1
> cassandra.yaml:audit_logging_options:
> cassandra.yaml- enabled: true
> cassandra.yaml- logger:
> cassandra.yaml: - class_name: FileAuditLogger
>
> When querying endpoints (/api/v0/metadata/endpoints) via mgmtapi, 200 OK is
> returned. However, NPE is reported by AuditLogManager.
> {code:java}
> ERROR [epollEventLoopGroup-5-3] 2023-05-10 15:53:30,301 NoSpamLogger.java:111
> - Failed notifying listeners
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.audit.AuditLogManager.querySuccess(AuditLogManager.java:244)
> at
> org.apache.cassandra.cql3.QueryEvents.notifyQuerySuccess(QueryEvents.java:78)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:117)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:254)
> at
> org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:106)
> at
> org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:86)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollDomainSocketChannel$EpollDomainUnsafe.epollInReady(EpollDomainSocketChannel.java:138)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunna
[jira] [Updated] (CASSANDRA-18620) Gossip unstable with istio service mesh in 4.1.2
[
https://issues.apache.org/jira/browse/CASSANDRA-18620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vanessa Haro updated CASSANDRA-18620:
-
Summary: Gossip unstable with istio service mesh in 4.1.2 (was: Gossip
unstable with istio service meshin 4.1.2)
> Gossip unstable with istio service mesh in 4.1.2
>
>
> Key: CASSANDRA-18620
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18620
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vanessa Haro
>Priority: Normal
>
> NullPointerException in cassandra.audit.AuditLogManager.querySuccess when
> querying endpoints via mgmtapi
>
> cassandra version: 4.1.1
> cassandra.yaml:audit_logging_options:
> cassandra.yaml- enabled: true
> cassandra.yaml- logger:
> cassandra.yaml: - class_name: FileAuditLogger
>
> When querying endpoints (/api/v0/metadata/endpoints) via mgmtapi, 200 OK is
> returned. However, NPE is reported by AuditLogManager.
> {code:java}
> ERROR [epollEventLoopGroup-5-3] 2023-05-10 15:53:30,301 NoSpamLogger.java:111
> - Failed notifying listeners
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.audit.AuditLogManager.querySuccess(AuditLogManager.java:244)
> at
> org.apache.cassandra.cql3.QueryEvents.notifyQuerySuccess(QueryEvents.java:78)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:117)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:254)
> at
> org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:106)
> at
> org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:86)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollDomainSocketChannel$EpollDomainUnsafe.epollInReady(EpollDomainSocketChannel.java:138)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.ru
[jira] [Updated] (CASSANDRA-18620) Gossip unstable with istio service mesh in 4.1.2
[
https://issues.apache.org/jira/browse/CASSANDRA-18620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vanessa Haro updated CASSANDRA-18620:
-
Component/s: (was: Tool/auditlogging)
> Gossip unstable with istio service mesh in 4.1.2
>
>
> Key: CASSANDRA-18620
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18620
> Project: Cassandra
> Issue Type: Bug
>Reporter: Vanessa Haro
>Priority: Normal
>
> NullPointerException in cassandra.audit.AuditLogManager.querySuccess when
> querying endpoints via mgmtapi
>
> cassandra version: 4.1.1
> cassandra.yaml:audit_logging_options:
> cassandra.yaml- enabled: true
> cassandra.yaml- logger:
> cassandra.yaml: - class_name: FileAuditLogger
>
> When querying endpoints (/api/v0/metadata/endpoints) via mgmtapi, 200 OK is
> returned. However, NPE is reported by AuditLogManager.
> {code:java}
> ERROR [epollEventLoopGroup-5-3] 2023-05-10 15:53:30,301 NoSpamLogger.java:111
> - Failed notifying listeners
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.audit.AuditLogManager.querySuccess(AuditLogManager.java:244)
> at
> org.apache.cassandra.cql3.QueryEvents.notifyQuerySuccess(QueryEvents.java:78)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:117)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:254)
> at
> org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:106)
> at
> org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:86)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollDomainSocketChannel$EpollDomainUnsafe.epollInReady(EpollDomainSocketChannel.java:138)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalR
[jira] [Updated] (CASSANDRA-18620) Gossip unstable with istio service mesh in 4.1.2
[
https://issues.apache.org/jira/browse/CASSANDRA-18620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vanessa Haro updated CASSANDRA-18620:
-
Bug Category: Parent values: Degradation(12984) (was: Parent values:
Correctness(12982)Level 1 values: Transient Incorrect Response(12987))
> Gossip unstable with istio service mesh in 4.1.2
>
>
> Key: CASSANDRA-18620
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18620
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Vanessa Haro
>Priority: Normal
>
> NullPointerException in cassandra.audit.AuditLogManager.querySuccess when
> querying endpoints via mgmtapi
>
> cassandra version: 4.1.1
> cassandra.yaml:audit_logging_options:
> cassandra.yaml- enabled: true
> cassandra.yaml- logger:
> cassandra.yaml: - class_name: FileAuditLogger
>
> When querying endpoints (/api/v0/metadata/endpoints) via mgmtapi, 200 OK is
> returned. However, NPE is reported by AuditLogManager.
> {code:java}
> ERROR [epollEventLoopGroup-5-3] 2023-05-10 15:53:30,301 NoSpamLogger.java:111
> - Failed notifying listeners
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.audit.AuditLogManager.querySuccess(AuditLogManager.java:244)
> at
> org.apache.cassandra.cql3.QueryEvents.notifyQuerySuccess(QueryEvents.java:78)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:117)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:254)
> at
> org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:106)
> at
> org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:86)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollDomainSocketChannel$EpollDomainUnsafe.epollInReady(EpollDomainSocketChannel.java:138)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.interna
[jira] [Updated] (CASSANDRA-18620) Gossip unstable with istio service mesh in 4.1.2
[
https://issues.apache.org/jira/browse/CASSANDRA-18620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vanessa Haro updated CASSANDRA-18620:
-
Description:
Gossip unstable with istio service mesh in 4.1.2
detected in cassandra version: 4.1.2
previously not observed version: 4.1.1
was:
NullPointerException in cassandra.audit.AuditLogManager.querySuccess when
querying endpoints via mgmtapi
cassandra version: 4.1.1
cassandra.yaml:audit_logging_options:
cassandra.yaml- enabled: true
cassandra.yaml- logger:
cassandra.yaml: - class_name: FileAuditLogger
When querying endpoints (/api/v0/metadata/endpoints) via mgmtapi, 200 OK is
returned. However, NPE is reported by AuditLogManager.
{code:java}
ERROR [epollEventLoopGroup-5-3] 2023-05-10 15:53:30,301 NoSpamLogger.java:111 -
Failed notifying listeners
java.lang.NullPointerException: null
at
org.apache.cassandra.audit.AuditLogManager.querySuccess(AuditLogManager.java:244)
at
org.apache.cassandra.cql3.QueryEvents.notifyQuerySuccess(QueryEvents.java:78)
at
org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:117)
at
org.apache.cassandra.transport.Message$Request.execute(Message.java:254)
at
org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:106)
at
org.apache.cassandra.transport.UnixSocketServer41x$UnixSockMessage.channelRead0(UnixSocketServer41x.java:86)
at
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at
io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
at
io.netty.channel.epoll.EpollDomainSocketChannel$EpollDomainUnsafe.epollInReady(EpollDomainSocketChannel.java:138)
at
io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
{code}
> Gossip unstable with istio service mesh in 4.1.2
>
>
> Key: CASSANDRA-18620
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18620
> Project: Cassandra
> Issue Type: Bug
> Components: C
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736219#comment-17736219
]
Brad Schoening commented on CASSANDRA-18305:
[~smiklosovic] yes, the above would be useful IMHO and it does tie out directly
with pending compactions – assuming a task means sstable.
> 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: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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-18620) Gossip unstable with istio service mesh in 4.1.2
[ https://issues.apache.org/jira/browse/CASSANDRA-18620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18620: - Status: Awaiting Feedback (was: Triage Needed) This is not descriptive enough to work on. > Gossip unstable with istio service mesh in 4.1.2 > > > Key: CASSANDRA-18620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18620 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Vanessa Haro >Priority: Normal > > Gossip unstable with istio service mesh in 4.1.2 > > detected in cassandra version: 4.1.2 > previously not observed version: 4.1.1 > -- This message was sent by Atlassian Jira (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-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736236#comment-17736236
]
Stefan Miklosovic commented on CASSANDRA-18305:
---
[~bschoeni] would you mind if mean rate would be {_}per hour{_}?
If you prefer it per minute, I still want to have a possibility to have it per
hour without multiplying it by 60 again in my head. We may have a flag for it.
If mean rate per hour is OK for you we can do it like that and drop the flag.
Cassandra is a process which is meant to be run non-stop and if an operator
wants to see how are compactions going, I doubt the metric "per minute" for
mean rate is useful. I think that extrapolating that number to represent mean
number of compactions per hour is more telling.
> 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: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736238#comment-17736238
]
Brad Schoening commented on CASSANDRA-18305:
Per hour is fine. I had considered suggesting that also.
> 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: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] (CASSANDRASC-58) Support retries in Sidecar Client when MD5 checksum is mismatched
[ https://issues.apache.org/jira/browse/CASSANDRASC-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRASC-58: -- Labels: pull-request-available (was: ) > Support retries in Sidecar Client when MD5 checksum is mismatched > - > > Key: CASSANDRASC-58 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-58 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > In rare occasions an SSTable upload will get corrupted during upload. Bit > flips are expected to occur occasionally while transmitting the SSTables from > the client to the server. The current behavior of the Sidecar Client in those > situations is to fail fast without any retries. > We want to support Sidecar Client retries when checksum mismatch occurs > during SSTable upload. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-58) Support retries in Sidecar Client when MD5 checksum is mismatched
[ https://issues.apache.org/jira/browse/CASSANDRASC-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRASC-58: -- Test and Documentation Plan: Added new tests for the new status code Status: Patch Available (was: In Progress) PR: https://github.com/apache/cassandra-sidecar/pull/54 CI: https://app.circleci.com/pipelines/github/frankgh/cassandra-sidecar/154 > Support retries in Sidecar Client when MD5 checksum is mismatched > - > > Key: CASSANDRASC-58 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-58 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > In rare occasions an SSTable upload will get corrupted during upload. Bit > flips are expected to occur occasionally while transmitting the SSTables from > the client to the server. The current behavior of the Sidecar Client in those > situations is to fail fast without any retries. > We want to support Sidecar Client retries when checksum mismatch occurs > during SSTable upload. -- This message was sent by Atlassian Jira (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
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18305:
--
Fix Version/s: (was: 4.0.x)
(was: 4.1.x)
> 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: Manish Ghildiyal
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] [Commented] (CASSANDRA-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736247#comment-17736247 ] Ariel Weisberg commented on CASSANDRA-18464: I am a little confused as to why memory mapped files are slow for sequential writes from multiple threads and if the fix for this should be to switch to direct IO? Sure direct IO will bring all the bottlenecks for managing memory, and sending commands to the disk, and managing concurrency to Cassandra where can address them directly, but why can't we saturate an NVMe disk using memory mapped files? I wrote a quick and dirty program that writes 1mb at a time to a memory mapped buffer and syncs it every 2gb of append and that has no problem saturating the 2gb/sec disk on my MBP (apples and oranges I know). So if you remove concurrency bottlenecks it seems like memory mapped files work on that particular platform. One thing I did observe running commit log stress is the throughput increases as mutation goes up, so there is definitely some contention around each append. It started at 1gb/sec and then settled down to 650mb/sec after about 10 seconds which is an odd. I'll take a look at the patch now. > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Assignee: Amit Pawar >Priority: Normal > Fix For: 5.x > > Attachments: EnableDirectIOForCommitLogUsingNativeAPI.patch, > UseDirectIOFeatureForCommitLogFiles.patch > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- This message was sent by Atlassian Jira (v8.20.10#820010) -
[jira] [Commented] (CASSANDRA-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736253#comment-17736253 ] Ariel Weisberg commented on CASSANDRA-18464: So short patch :-) I am not married at all to using MMAP for writing. For direct IO I think we definitely want to pool two of the commit log buffers, and then dynamically allocate the rest if writing out commit log segments falls behind. I am not sure this is crash safe, I can't remember if extending the length of a file with direct IO also updates the metadata of the file. Would need to do some googling. See https://ext4.wiki.kernel.org/index.php/Clarifying_Direct_IO%27s_Semantics "Allocating Writes". Is the issue this is addressing contention around page cache data structures either when touching each 4k page as we append, or a contention around msync, or both? It certainly seems like a relatively straightforward way to address it vs. trying to work around performance issues with msync. Can you factor out the rest of Cassandra and run commit log stress and demonstrate the speed difference between the two implementations on NVMe? Here are some changes I made to help with testing that https://pastebin.com/JXJv0tSd > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Assignee: Amit Pawar >Priority: Normal > Fix For: 5.x > > Attachments: EnableDirectIOForCommitLogUsingNativeAPI.patch, > UseDirectIOFeatureForCommitLogFiles.patch > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- This message was sent by Atlassian Jira (v8.20.10#820010) -
[jira] [Commented] (CASSANDRA-18465) Add support for multiple condition branches and results in Accord transaction
[
https://issues.apache.org/jira/browse/CASSANDRA-18465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736256#comment-17736256
]
David Capwell commented on CASSANDRA-18465:
---
left feedback in PR, but my main concern is the SELECT logic in the conditions
feels weird to me from a semantic point of view, so might be good to remove
that for now and only support update? If we do want the select, I feel we will
want to think through the semantics more
> Add support for multiple condition branches and results in Accord transaction
> -
>
> Key: CASSANDRA-18465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18465
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> I'd like to propose adding support for multiple branches and result sets for
> Accord transactions. It could look like this:
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> LET c = ...
> IF condition THEN
> SELECT 1, a.value
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 2, b.value
> UPDATE ...
> ELSE
> SELECT 3, c.value
> END IF
> COMMIT TRANSACTION
> {code}
> The existing syntax would remain valid, when a single SELECT is defined in
> which case the conditional SELECTs would not be valid.
> SELECTs would be validated to return columns of the same type. They would be
> able to return literals as well.
> This would be make the result of the transaction more intuitive as the client
> would know explicitly if the updates where applied or not.
> The following syntax would be considered as invalid:
> 1. SELECTs defined both on the top level and in branches
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> SELECT ... <
> IF condition THEN
> SELECT 'one', a.value <
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 'two', b.value <
> UPDATE ...
> ELSE
> SELECT 'three', NULL <
> END IF
> COMMIT TRANSACTION
> {code}
> 2. SELECT defined after update - select must be before the update to make it
> clear that the data is read before modification
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> UPDATE ...
> SELECT 'one', a.value <
> ELSE IF condition2 THEN
> UPDATE ...
> SELECT 'two', b.value
> ELSE
> SELECT 'three', NULL
> END IF
> COMMIT TRANSACTION
> {code}
> 3. Missing SELECT in a conditional branch - if SELECT is defined in a any
> conditional branch, it has to be defined in all branches:
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 'two', b.value
> UPDATE ...
> ELSE <
> UPDATE ...
> END IF
> COMMIT TRANSACTION
> {code}
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> END IF < (else branch is implicit and it
> has no SELECT)
> COMMIT TRANSACTION
> {code}
> Selections in conditional branches will support only returning references -
> no support for full query is planned in this ticket.
--
This message was sent by Atlassian 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 (726038ff -> d6c54bbd)
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 726038ff generate docs for 8efdf127 new d6c54bbd generate docs for 8efdf127 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 (726038ff) \ N -- N -- N refs/heads/asf-staging (d6c54bbd) 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: .../doc/4.2/cassandra/developing/cql/changes.html | 3 + .../cassandra/developing/cql/cql_singlefile.html | 81 - .../4.2/cassandra/developing/cql/definitions.html | 4 +- .../doc/4.2/cassandra/developing/cql/types.html| 29 .../trunk/cassandra/developing/cql/changes.html| 3 + .../cassandra/developing/cql/cql_singlefile.html | 81 - .../cassandra/developing/cql/definitions.html | 4 +- .../doc/trunk/cassandra/developing/cql/types.html | 29 content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4796900 -> 4796900 bytes 10 files changed, 229 insertions(+), 7 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18190) ECJ upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-18190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736257#comment-17736257 ] Ekaterina Dimitrova commented on CASSANDRA-18190: - Thank you both; this will be committed when we drop JDK8, pending on Jamm integration > ECJ upgrade > --- > > Key: CASSANDRA-18190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18190 > Project: Cassandra > Issue Type: Task > Components: Feature/UDF >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > During testing it was identified that we will need to update ECJ for the Java > UDF functions in order to bring Java 17 in. > It seems the compiler artifacts are moved from > [here|https://mvnrepository.com/artifact/org.eclipse.jdt.core.compiler/ecj] > to [here|https://mvnrepository.com/artifact/org.eclipse.jdt/ecj] and there is > change of license from EPL1.0 to EPL2.0 too. But if I read correctly > [here|https://www.apache.org/legal/resolved.html#weak-copyleft-licenses] that > should not affect us > Further testing and review of all changes between artifacts to be done. > ECJ is used for the eclipse-warnings and Java UDFs > As agreed on the [dev mailing > list|https://lists.apache.org/thread/8ok01odwx79crxw45cnfh0n1j4nsf9cp] we > will replace eclipse-warnings in trunk with CheckerFramework equivalent one > but better. > So as part of this ticket we are removing ant eclipse-warnings task and > upgrading ecj for Java UDFs. -- This message was sent by Atlassian Jira (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-18608) snappy-java vulnerability: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453
[
https://issues.apache.org/jira/browse/CASSANDRA-18608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18608:
-
Test and Documentation Plan: run CI
Status: Patch Available (was: Open)
> snappy-java vulnerability: CVE-2023-34455, CVE-2023-34454, CVE-2023-34453
> -
>
> Key: CASSANDRA-18608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18608
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Compression
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> Failing owasp:
> [https://nvd.nist.gov/vuln/detail/CVE-2023-34455]
> {quote}Due to use of an unchecked chunk length, an unrecoverable fatal error
> can occur in versions prior to 1.1.10.1.
> {quote}
> [https://nvd.nist.gov/vuln/detail/CVE-2023-34454]
> {quote}Due to unchecked multiplications, an integer overflow may occur in
> versions prior to 1.1.10.1, causing an unrecoverable fatal error.
> {quote}
> [https://nvd.nist.gov/vuln/detail/CVE-2023-34453]
> {quote}Due to unchecked multiplications, an integer overflow may occur in
> versions prior to 1.1.10.1, causing a fatal error.
> {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] [Commented] (CASSANDRA-18613) Add support for vectors on UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-18613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736265#comment-17736265
]
Andres de la Peña commented on CASSANDRA-18613:
---
Now that CASSANDRA-18504, here is the PR:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2436]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2972/workflows/5ac8c26e-de08-4803-bd4a-4b8b431e79b1]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2972/workflows/802d629a-74f5-4aca-ac8c-6aee9bc8d15e]|
I'll open a separate ticket for doing some refactoring to get rid of the
copy-pasted Java driver code, but in this one we still follow the current
approach.
> Add support for vectors on UDFs
> ---
>
> Key: CASSANDRA-18613
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18613
> Project: Cassandra
> Issue Type: New Feature
> Components: Cluster/Schema
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-18504 will add a new vector type, but [it won't be supported on
> UDFs|https://github.com/apache/cassandra/blob/5027e688da006e5d5bf9bfdf4719caddbf85986a/test/unit/org/apache/cassandra/cql3/validation/operations/CQLVectorTest.java#L248-L271].
> The goal of this ticket is to add that support.
> This will require adding a new {{o.a.c.cql3.functions.types.TypeCodec}} for
> vectors. Those codecs are mostly duplicates of the codecs on the Java driver.
> They are used for UDFs instead of the regular {{AbstractType}} to prevent
> pulling too many internal dependencies. The driver's vector codec has
> recently been added by
> [JAVA-3060|https://datastax-oss.atlassian.net/browse/JAVA-3060].
--
This message was sent by Atlassian Jira
(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-18613) Add support for vectors on UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-18613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18613:
--
Change Category: Semantic
Complexity: Normal
Status: Open (was: Triage Needed)
> Add support for vectors on UDFs
> ---
>
> Key: CASSANDRA-18613
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18613
> Project: Cassandra
> Issue Type: New Feature
> Components: Cluster/Schema
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-18504 will add a new vector type, but [it won't be supported on
> UDFs|https://github.com/apache/cassandra/blob/5027e688da006e5d5bf9bfdf4719caddbf85986a/test/unit/org/apache/cassandra/cql3/validation/operations/CQLVectorTest.java#L248-L271].
> The goal of this ticket is to add that support.
> This will require adding a new {{o.a.c.cql3.functions.types.TypeCodec}} for
> vectors. Those codecs are mostly duplicates of the codecs on the Java driver.
> They are used for UDFs instead of the regular {{AbstractType}} to prevent
> pulling too many internal dependencies. The driver's vector codec has
> recently been added by
> [JAVA-3060|https://datastax-oss.atlassian.net/browse/JAVA-3060].
--
This message was sent by Atlassian Jira
(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-18613) Add support for vectors on UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-18613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18613:
--
Test and Documentation Plan:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2436]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2972/workflows/5ac8c26e-de08-4803-bd4a-4b8b431e79b1]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2972/workflows/802d629a-74f5-4aca-ac8c-6aee9bc8d15e]|
Status: Patch Available (was: Open)
> Add support for vectors on UDFs
> ---
>
> Key: CASSANDRA-18613
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18613
> Project: Cassandra
> Issue Type: New Feature
> Components: Cluster/Schema
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-18504 will add a new vector type, but [it won't be supported on
> UDFs|https://github.com/apache/cassandra/blob/5027e688da006e5d5bf9bfdf4719caddbf85986a/test/unit/org/apache/cassandra/cql3/validation/operations/CQLVectorTest.java#L248-L271].
> The goal of this ticket is to add that support.
> This will require adding a new {{o.a.c.cql3.functions.types.TypeCodec}} for
> vectors. Those codecs are mostly duplicates of the codecs on the Java driver.
> They are used for UDFs instead of the regular {{AbstractType}} to prevent
> pulling too many internal dependencies. The driver's vector codec has
> recently been added by
> [JAVA-3060|https://datastax-oss.atlassian.net/browse/JAVA-3060].
--
This message was sent by Atlassian Jira
(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-18621) Update Cassandra logos on ASF project logos site
Melissa Logan created CASSANDRA-18621: - Summary: Update Cassandra logos on ASF project logos site Key: CASSANDRA-18621 URL: https://issues.apache.org/jira/browse/CASSANDRA-18621 Project: Cassandra Issue Type: Task Reporter: Melissa Logan Assignee: Melissa Logan It appears that the Cassandra logos on the ASF project logos website are outdated, as they include lowercase letters and no trademark: https://www.apache.org/logos/#cassandra The logo currently being used on the website is this one: https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/images/logo-white.svg To ensure proper usage by contributors and third parties, I propose the creation of the following logo set based on the current website logo: Version 1 - update and create black and white versions Version 2- remove Version 3 - update and create black and white versions Version 4 - no change If these already exist somewhere, then please upload them to the ASF project logos page (requires a committer): https://www.apache.org/logos/about.html Otherwise I will be asking our designer to create hi-res versions to be uploaded. -- This message was sent by Atlassian Jira (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-18180) bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736313#comment-17736313
]
Ekaterina Dimitrova commented on CASSANDRA-18180:
-
- Pushed new CI run with the latest changes -
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=CASSANDRA-18180-trunk]
There are two tests that I haven't seen failing before. Tests in discussion: *
[test_move_backwards_and_cleanup|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/e604ddb5-85fb-4828-b6d5-aae56ba6e6a6/jobs/26557/tests#failed-test-0]
- Python DTest
*
[testTruncationReleasesLogSpace-oa.jdk11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/ec4aaa50-acea-4c9d-bb20-5d139a6962ab/jobs/26575/tests#failed-test-0]
- unit test
I managed to reproduce the test_move_backwards_and_cleanup on current trunk
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2390/workflows/719ea674-1f0f-4165-92ba-785469e1bb2f/jobs/27021/tests].
I did not manage to reproduce the other one in 1000 runs but it seems it could
be just something random. (file not available)
- I ran the simulator tests with JDK17 again (locally until we get the JDK 17
simulator tests job to CircleCI, CASSANDRA-18616)
- I tested the check-test-names task. It works as expected.
- The JDK change we address here affects only GCM, as per the JEP [~djatnieks]
pointed to. The wrapper looks ok to me and it is used only in
debugging/testing.
- I did not find any other places where we might be hitting this problem.
- I also ran test_simple_bootstrap_with_ssl and sslnodetonode_test Python
DTests with Netty version that uses by default JDK provider (netty 4.1.73, I
also had at that branch netty-tcnative-boringssl-static - 2.0.51 but I do not
think that matters here) and it was hitting this problem before. The tests pass
with this patch.
Let's see if [~adelapena] will find something we are missing here, but I am
personally +1 on the current work.
> bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
> ---
>
> Key: CASSANDRA-18180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18180
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
> Attachments: cassandra-18180-directbufferref.diff
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While working on CASSANDRA-17992 we hit:
> {code:java}
> java.lang.ClassCastException: class
> org.apache.cassandra.utils.memory.BufferPool$Chunk cannot be cast to class
> sun.nio.ch.DirectBuffer (org.apache.cassandra.utils.memory.BufferPool$Chunk
> is in unnamed module of loader 'app'; sun.nio.ch.DirectBuffer is in module
> java.base of loader 'bootstrap')\n\tat
> java.base/com.sun.crypto.provider.GaloisCounterMode$GCMEngine.overlapDetection(GaloisCounterMode.java:865)\n\tat
>
> java.base/com.sun.crypto.provider.GaloisCounterMode$GCMDecrypt.doFinal(GaloisCounterMode.java:1502)\n\tat
>
> java.base/com.sun.crypto.provider.GaloisCounterMode.engineDoFinal(GaloisCounterMode.java:447)\n\tat
>
> {code}
> -The issue is exposed with JDK 17, trunk; if interested, ping- [~e.dimitrova]
> -for current branch as there is no feature branch at the moment- we can
> build and start from trunk with JDK17 already. Circle CI can be run for JDK17
> too. For more information how to do that - .circleci/readme.md
> CC [~benedict]
--
This message was sent by Atlassian Jira
(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-18180) bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736313#comment-17736313
]
Ekaterina Dimitrova edited comment on CASSANDRA-18180 at 6/23/23 1:08 AM:
--
- Pushed new CI run with the latest changes -
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=CASSANDRA-18180-trunk]
There are two tests that I haven't seen failing before. Tests in discussion: *
[test_move_backwards_and_cleanup|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/e604ddb5-85fb-4828-b6d5-aae56ba6e6a6/jobs/26557/tests#failed-test-0]
- Python DTest
*
[testTruncationReleasesLogSpace-oa.jdk11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/ec4aaa50-acea-4c9d-bb20-5d139a6962ab/jobs/26575/tests#failed-test-0]
- unit test
I managed to reproduce the test_move_backwards_and_cleanup on current trunk
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2390/workflows/719ea674-1f0f-4165-92ba-785469e1bb2f/jobs/27021/tests].
I did not manage to reproduce the other one in 1000 runs but it seems it could
be just something random. (file not available)
- I ran the simulator tests with JDK17 again (locally until we get the JDK 17
simulator tests job to CircleCI, CASSANDRA-18616)
- I tested the check-test-names task. It works as expected.
- The JDK change we address here affects only GCM, as per the JEP [~djatnieks]
pointed to. The wrapper looks ok to me and it is used only in
debugging/testing.
- I did not find any other places where we might be hitting this problem.
- I also ran test_simple_bootstrap_with_ssl and sslnodetonode_test Python
DTests with Netty version that uses by default JDK provider (netty 4.1.73, I
also had at that branch netty-tcnative-boringssl-static - 2.0.51 but I do not
think that matters here) and it was hitting this problem before. The tests pass
with this patch.
Let's see if [~adelapena] will find something we are missing here, but I am
personally +1 on the current work. (On squash, rebase and final CI ofc
pre-commit)
was (Author: e.dimitrova):
- Pushed new CI run with the latest changes -
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=CASSANDRA-18180-trunk]
There are two tests that I haven't seen failing before. Tests in discussion: *
[test_move_backwards_and_cleanup|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/e604ddb5-85fb-4828-b6d5-aae56ba6e6a6/jobs/26557/tests#failed-test-0]
- Python DTest
*
[testTruncationReleasesLogSpace-oa.jdk11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/ec4aaa50-acea-4c9d-bb20-5d139a6962ab/jobs/26575/tests#failed-test-0]
- unit test
I managed to reproduce the test_move_backwards_and_cleanup on current trunk
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2390/workflows/719ea674-1f0f-4165-92ba-785469e1bb2f/jobs/27021/tests].
I did not manage to reproduce the other one in 1000 runs but it seems it could
be just something random. (file not available)
- I ran the simulator tests with JDK17 again (locally until we get the JDK 17
simulator tests job to CircleCI, CASSANDRA-18616)
- I tested the check-test-names task. It works as expected.
- The JDK change we address here affects only GCM, as per the JEP [~djatnieks]
pointed to. The wrapper looks ok to me and it is used only in
debugging/testing.
- I did not find any other places where we might be hitting this problem.
- I also ran test_simple_bootstrap_with_ssl and sslnodetonode_test Python
DTests with Netty version that uses by default JDK provider (netty 4.1.73, I
also had at that branch netty-tcnative-boringssl-static - 2.0.51 but I do not
think that matters here) and it was hitting this problem before. The tests pass
with this patch.
Let's see if [~adelapena] will find something we are missing here, but I am
personally +1 on the current work.
> bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
> ---
>
> Key: CASSANDRA-18180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18180
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
> Attachments: cassandra-18180-directbufferref.diff
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While working on CASSANDRA-17992 we hit:
> {code:java}
> java.lang.ClassCastException: class
> org.apache.cassandra.utils.memory.BufferPool$Chunk cannot be cast to class
> sun.nio.ch.DirectBuffer (org.apache.
[jira] [Comment Edited] (CASSANDRA-18180) bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736313#comment-17736313
]
Ekaterina Dimitrova edited comment on CASSANDRA-18180 at 6/23/23 1:09 AM:
--
- Pushed new CI run with the latest changes -
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=CASSANDRA-18180-trunk]
There are two tests that I haven't seen failing before. Tests in discussion:
[test_move_backwards_and_cleanup|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/e604ddb5-85fb-4828-b6d5-aae56ba6e6a6/jobs/26557/tests#failed-test-0]
- Python DTest
*
[testTruncationReleasesLogSpace-oa.jdk11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/ec4aaa50-acea-4c9d-bb20-5d139a6962ab/jobs/26575/tests#failed-test-0]
- unit test
I managed to reproduce the test_move_backwards_and_cleanup on current trunk
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2390/workflows/719ea674-1f0f-4165-92ba-785469e1bb2f/jobs/27021/tests].
I did not manage to reproduce the other one in 1000 runs but it seems it could
be just something random. (file not available)
- I ran the simulator tests with JDK17 again (locally until we get the JDK 17
simulator tests job to CircleCI, CASSANDRA-18616)
- I tested the check-test-names task. It works as expected.
- The JDK change we address here affects only GCM, as per the JEP [~djatnieks]
pointed to. The wrapper looks ok to me and it is used only in
debugging/testing.
- I did not find any other places where we might be hitting this problem.
- I also ran test_simple_bootstrap_with_ssl and sslnodetonode_test Python
DTests with Netty version that uses by default JDK provider (netty 4.1.73, I
also had at that branch netty-tcnative-boringssl-static - 2.0.51 but I do not
think that matters here) and it was hitting this problem before. The tests pass
with this patch.
Let's see if [~adelapena] will find something we are missing here, but I am
personally +1 on the current work. (On squash, rebase and final CI ofc
pre-commit)
was (Author: e.dimitrova):
- Pushed new CI run with the latest changes -
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=CASSANDRA-18180-trunk]
There are two tests that I haven't seen failing before. Tests in discussion: *
[test_move_backwards_and_cleanup|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/e604ddb5-85fb-4828-b6d5-aae56ba6e6a6/jobs/26557/tests#failed-test-0]
- Python DTest
*
[testTruncationReleasesLogSpace-oa.jdk11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/ec4aaa50-acea-4c9d-bb20-5d139a6962ab/jobs/26575/tests#failed-test-0]
- unit test
I managed to reproduce the test_move_backwards_and_cleanup on current trunk
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2390/workflows/719ea674-1f0f-4165-92ba-785469e1bb2f/jobs/27021/tests].
I did not manage to reproduce the other one in 1000 runs but it seems it could
be just something random. (file not available)
- I ran the simulator tests with JDK17 again (locally until we get the JDK 17
simulator tests job to CircleCI, CASSANDRA-18616)
- I tested the check-test-names task. It works as expected.
- The JDK change we address here affects only GCM, as per the JEP [~djatnieks]
pointed to. The wrapper looks ok to me and it is used only in
debugging/testing.
- I did not find any other places where we might be hitting this problem.
- I also ran test_simple_bootstrap_with_ssl and sslnodetonode_test Python
DTests with Netty version that uses by default JDK provider (netty 4.1.73, I
also had at that branch netty-tcnative-boringssl-static - 2.0.51 but I do not
think that matters here) and it was hitting this problem before. The tests pass
with this patch.
Let's see if [~adelapena] will find something we are missing here, but I am
personally +1 on the current work. (On squash, rebase and final CI ofc
pre-commit)
> bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
> ---
>
> Key: CASSANDRA-18180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18180
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
> Attachments: cassandra-18180-directbufferref.diff
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While working on CASSANDRA-17992 we hit:
> {code:java}
> java.lang.ClassCastException: class
> org.apache.cassandra.utils.memory.BufferPool$Chunk cannot be cast t
[jira] [Comment Edited] (CASSANDRA-18180) bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736313#comment-17736313
]
Ekaterina Dimitrova edited comment on CASSANDRA-18180 at 6/23/23 1:09 AM:
--
- Pushed new CI run with the latest changes -
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=CASSANDRA-18180-trunk]
There are two tests that I haven't seen failing before. Tests in discussion:
[test_move_backwards_and_cleanup|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/e604ddb5-85fb-4828-b6d5-aae56ba6e6a6/jobs/26557/tests#failed-test-0]
- Python DTest
*
[testTruncationReleasesLogSpace-oa.jdk11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/ec4aaa50-acea-4c9d-bb20-5d139a6962ab/jobs/26575/tests#failed-test-0]
- unit test
I managed to reproduce the test_move_backwards_and_cleanup on current trunk
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2390/workflows/719ea674-1f0f-4165-92ba-785469e1bb2f/jobs/27021/tests].
I did not manage to reproduce the other one in 1000 runs but it seems it could
be just something random. (file not available)
- I ran the simulator tests with JDK17 again (locally until we get the JDK 17
simulator tests job to CircleCI, CASSANDRA-18616)
- I tested the check-test-names task. It works as expected.
- The JDK change we address here affects only GCM, as per the JEP [~djatnieks]
pointed to. The wrapper looks ok to me and it is used only in
debugging/testing.
- I did not find any other places where we might be hitting this problem.
- I also ran test_simple_bootstrap_with_ssl and sslnodetonode_test Python
DTests with Netty version that uses by default JDK provider (netty 4.1.73, I
also had at that branch netty-tcnative-boringssl-static - 2.0.51 but I do not
think that matters here) and it was hitting this problem before. The tests pass
with this patch.
Let's see if [~adelapena] will find something we are missing here, but I am
personally +1 on the current work. (On squash, rebase and final CI ofc
pre-commit)
was (Author: e.dimitrova):
- Pushed new CI run with the latest changes -
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=CASSANDRA-18180-trunk]
There are two tests that I haven't seen failing before. Tests in discussion:
[test_move_backwards_and_cleanup|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/e604ddb5-85fb-4828-b6d5-aae56ba6e6a6/jobs/26557/tests#failed-test-0]
- Python DTest
*
[testTruncationReleasesLogSpace-oa.jdk11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/ec4aaa50-acea-4c9d-bb20-5d139a6962ab/jobs/26575/tests#failed-test-0]
- unit test
I managed to reproduce the test_move_backwards_and_cleanup on current trunk
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2390/workflows/719ea674-1f0f-4165-92ba-785469e1bb2f/jobs/27021/tests].
I did not manage to reproduce the other one in 1000 runs but it seems it could
be just something random. (file not available)
- I ran the simulator tests with JDK17 again (locally until we get the JDK 17
simulator tests job to CircleCI, CASSANDRA-18616)
- I tested the check-test-names task. It works as expected.
- The JDK change we address here affects only GCM, as per the JEP [~djatnieks]
pointed to. The wrapper looks ok to me and it is used only in
debugging/testing.
- I did not find any other places where we might be hitting this problem.
- I also ran test_simple_bootstrap_with_ssl and sslnodetonode_test Python
DTests with Netty version that uses by default JDK provider (netty 4.1.73, I
also had at that branch netty-tcnative-boringssl-static - 2.0.51 but I do not
think that matters here) and it was hitting this problem before. The tests pass
with this patch.
Let's see if [~adelapena] will find something we are missing here, but I am
personally +1 on the current work. (On squash, rebase and final CI ofc
pre-commit)
> bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
> ---
>
> Key: CASSANDRA-18180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18180
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
> Attachments: cassandra-18180-directbufferref.diff
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While working on CASSANDRA-17992 we hit:
> {code:java}
> java.lang.ClassCastException: class
> org.apache.cassandra.utils.memory.BufferPool$Chunk cannot be cast t
[jira] [Comment Edited] (CASSANDRA-18180) bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736313#comment-17736313
]
Ekaterina Dimitrova edited comment on CASSANDRA-18180 at 6/23/23 1:10 AM:
--
- Pushed new CI run with the latest changes -
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=CASSANDRA-18180-trunk]
There are two tests that I haven't seen failing before. Tests in discussion:
*
[test_move_backwards_and_cleanup|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/e604ddb5-85fb-4828-b6d5-aae56ba6e6a6/jobs/26557/tests#failed-test-0]
- Python DTest
*
[testTruncationReleasesLogSpace-oa.jdk11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/ec4aaa50-acea-4c9d-bb20-5d139a6962ab/jobs/26575/tests#failed-test-0]
- unit test
I managed to reproduce the test_move_backwards_and_cleanup on current trunk
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2390/workflows/719ea674-1f0f-4165-92ba-785469e1bb2f/jobs/27021/tests].
I did not manage to reproduce the other one in 1000 runs but it seems it could
be just something random. (file not available)
- I ran the simulator tests with JDK17 again (locally until we get the JDK 17
simulator tests job to CircleCI, CASSANDRA-18616)
- I tested the check-test-names task. It works as expected.
- The JDK change we address here affects only GCM, as per the JEP [~djatnieks]
pointed to. The wrapper looks ok to me and it is used only in
debugging/testing.
- I did not find any other places where we might be hitting this problem.
- I also ran test_simple_bootstrap_with_ssl and sslnodetonode_test Python
DTests with Netty version that uses by default JDK provider (netty 4.1.73, I
also had at that branch netty-tcnative-boringssl-static - 2.0.51 but I do not
think that matters here) and it was hitting this problem before. The tests pass
with this patch.
Let's see if [~adelapena] will find something we are missing here, but I am
personally +1 on the current work. (On squash, rebase and final CI ofc
pre-commit)
was (Author: e.dimitrova):
- Pushed new CI run with the latest changes -
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=CASSANDRA-18180-trunk]
There are two tests that I haven't seen failing before. Tests in discussion:
[test_move_backwards_and_cleanup|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/e604ddb5-85fb-4828-b6d5-aae56ba6e6a6/jobs/26557/tests#failed-test-0]
- Python DTest
*
[testTruncationReleasesLogSpace-oa.jdk11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2386/workflows/ec4aaa50-acea-4c9d-bb20-5d139a6962ab/jobs/26575/tests#failed-test-0]
- unit test
I managed to reproduce the test_move_backwards_and_cleanup on current trunk
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2390/workflows/719ea674-1f0f-4165-92ba-785469e1bb2f/jobs/27021/tests].
I did not manage to reproduce the other one in 1000 runs but it seems it could
be just something random. (file not available)
- I ran the simulator tests with JDK17 again (locally until we get the JDK 17
simulator tests job to CircleCI, CASSANDRA-18616)
- I tested the check-test-names task. It works as expected.
- The JDK change we address here affects only GCM, as per the JEP [~djatnieks]
pointed to. The wrapper looks ok to me and it is used only in
debugging/testing.
- I did not find any other places where we might be hitting this problem.
- I also ran test_simple_bootstrap_with_ssl and sslnodetonode_test Python
DTests with Netty version that uses by default JDK provider (netty 4.1.73, I
also had at that branch netty-tcnative-boringssl-static - 2.0.51 but I do not
think that matters here) and it was hitting this problem before. The tests pass
with this patch.
Let's see if [~adelapena] will find something we are missing here, but I am
personally +1 on the current work. (On squash, rebase and final CI ofc
pre-commit)
> bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
> ---
>
> Key: CASSANDRA-18180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18180
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
> Attachments: cassandra-18180-directbufferref.diff
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While working on CASSANDRA-17992 we hit:
> {code:java}
> java.lang.ClassCastException: class
> org.apache.cassandra.utils.memory.BufferPool$Chunk cannot be ca
[jira] [Created] (CASSANDRA-18622) StorageService throws inconsistent exceptions for unknown hosts
Hao Zhong created CASSANDRA-18622:
-
Summary: StorageService throws inconsistent exceptions for unknown
hosts
Key: CASSANDRA-18622
URL: https://issues.apache.org/jira/browse/CASSANDRA-18622
Project: Cassandra
Issue Type: Bug
Reporter: Hao Zhong
When hosts are unknown, StorageService throws two types of exceptions. The
following methods throw RuntimeException:
{code:java}
public String getNativeaddress(InetAddressAndPort endpoint, boolean withPort){
...
try{
InetAddressAndPort address =
InetAddressAndPort.getByName(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT).value);
return address.getHostAddress(withPort);
}catch (UnknownHostException e) {
throw new RuntimeException(e);
}
}{code}
{code:java}
public void onChange(InetAddressAndPort endpoint, ApplicationState state,
VersionedValue value){
...
try {
InetAddressAndPort address = InetAddressAndPort.getByName(value.value);
SystemKeyspace.updatePeerNativeAddress(endpoint, address);
} catch (UnknownHostException e)
{
throw new RuntimeException(e);
}
...
}
{code}
A method throws IllegalArgumentException
{code:java}
public void rebuild(String sourceDc, String keyspace, String tokens, String
specificSources, boolean excludeLocalDatacenterNodes){
...
try{InetAddressAndPort
endpoint = InetAddressAndPort.getByName(stringHost);
if (FBUtilities.getBroadcastAddressAndPort().equals(endpoint))
{throw new
IllegalArgumentException("This host was specified as a source for rebuilding.
Sources for a rebuild can only be other nodes in the cluster.");
}sources.add(endpoint);
}catch (UnknownHostException ex)
{throw new IllegalArgumentException("Unknown
host specified " + stringHost, ex);}
} {code}
A method throws no exceptions:
{code:java}
private void handleStateBootreplacing(InetAddressAndPort newNode, String[]
pieces){
...
try {
oldNode = InetAddressAndPort.getByName(pieces[1]);
} catch (Exception e) {
logger.error("Node {} tried to replace malformed endpoint {}.", newNode,
pieces[1], e);
return;
}
...
} {code}
A method does not rethrow exceptions and throws
{color:#00}UnknownHostException{color}
{code:java}
public List getTokens(String endpoint) throws UnknownHostException
{return getTokens(InetAddressAndPort.getByName(endpoint));} {code}
{color:#00}The treatments look random. {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[GitHub] [cassandra-analytics] yifan-c closed pull request #5: CASSANDRA-18599 Upgrade to JUnit 5
yifan-c closed pull request #5: CASSANDRA-18599 Upgrade to JUnit 5 URL: https://github.com/apache/cassandra-analytics/pull/5 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18623) The exceptions related to queryNames are inconsistently handled in NodeProbe.java
Hao Zhong created CASSANDRA-18623:
-
Summary: The exceptions related to queryNames are inconsistently
handled in NodeProbe.java
Key: CASSANDRA-18623
URL: https://issues.apache.org/jira/browse/CASSANDRA-18623
Project: Cassandra
Issue Type: Bug
Reporter: Hao Zhong
The call of queryNames can cause MalformedObjectNameException and IOException,
but the exceptions are inconsistently handled.
The following method rethrows RuntimeException:
{code:java}
private static Multimap
getJmxThreadPools(MBeanServerConnection mbeanServerConn)
{
try
{
Multimap threadPools = HashMultimap.create();
Set threadPoolObjectNames = mbeanServerConn.queryNames(
new ObjectName("org.apache.cassandra.metrics:type=ThreadPools,*"),
null);
...
}catch (MalformedObjectNameException e) {
throw new RuntimeException("Bad query to JMX server: ", e);
}catch (IOException e)
{ throw new RuntimeException("Error getting threadpool names from JMX",
e);}
{code}
A method swallows the thrown exceptions:
{code:java}
public ColumnFamilyStoreMBean getCfsProxy(String ks, String cf)
{
...
try{
Set beans = mbeanServerConn.queryNames(new
ObjectName("org.apache.cassandra.db:type=*" + type +",keyspace=" + ks +
",columnfamily=" + cf), null);
...
}catch (MalformedObjectNameException mone){
System.err.println("ColumnFamilyStore for " + ks + "/" + cf + " not
found.");System.exit(1);
}catch (IOException e){
System.err.println("ColumnFamilyStore for " + ks + "/" + cf + " not found:
" + e);System.exit(1);}
{code}
A method does not handle it at all:
{code:java}
private List>
getCFSMBeans(MBeanServerConnection mbeanServerConn, String type)
throws MalformedObjectNameException, IOException
{
...
ObjectName query = new ObjectName("org.apache.cassandra.db:type=" + type
+",*");Set cfObjects = mbeanServerConn.queryNames(query,
null);
...
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18600) [Analytics] Add NOTICE.txt in Cassandra Analytics
[
https://issues.apache.org/jira/browse/CASSANDRA-18600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736348#comment-17736348
]
Dinesh Joshi commented on CASSANDRA-18600:
--
+1, thanks for the patch.
> [Analytics] Add NOTICE.txt in Cassandra Analytics
> --
>
> Key: CASSANDRA-18600
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18600
> Project: Cassandra
> Issue Type: Task
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The Cassandra Analytics project is missing the {{NOTICE.txt}} file required
> for compliance with the ASF guidance
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-54) Add NOTICE.txt file
[ https://issues.apache.org/jira/browse/CASSANDRASC-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736349#comment-17736349 ] Dinesh Joshi commented on CASSANDRASC-54: - +1, thanks for the patch. > Add NOTICE.txt file > --- > > Key: CASSANDRASC-54 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-54 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Documentation >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > The Cassandra Sidecar project is missing the NOTICE.txt file required for > compliance with the ASF guidance -- This message was sent by Atlassian Jira (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-18624) Make Corretto Crypto Provider the Default
Jordan West created CASSANDRA-18624: --- Summary: Make Corretto Crypto Provider the Default Key: CASSANDRA-18624 URL: https://issues.apache.org/jira/browse/CASSANDRA-18624 Project: Cassandra Issue Type: Improvement Reporter: Jordan West [Amazon Corretto Crypto Provider| https://github.com/corretto/amazon-corretto-crypto-provider] is an alternative provider of TLS and cryptographic functions that has significant performance benefits for Cassandra. It is Apache 2.0 licensed and has been deployed in several existing large fleets. -- This message was sent by Atlassian Jira (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-18624) Make Corretto Crypto Provider the Default
[ https://issues.apache.org/jira/browse/CASSANDRA-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-18624: Change Category: Performance Complexity: Low Hanging Fruit Component/s: Dependencies Assignee: Jordan West Status: Open (was: Triage Needed) > Make Corretto Crypto Provider the Default > - > > Key: CASSANDRA-18624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18624 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > > [Amazon Corretto Crypto Provider| > https://github.com/corretto/amazon-corretto-crypto-provider] is an > alternative provider of TLS and cryptographic functions that has significant > performance benefits for Cassandra. It is Apache 2.0 licensed and has been > deployed in several existing large fleets. -- This message was sent by Atlassian Jira (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-18358) Fix issue with system.local.broadcast_port when downgrading to v3
[
https://issues.apache.org/jira/browse/CASSANDRA-18358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren reassigned CASSANDRA-18358:
-
Assignee: Claude Warren
> Fix issue with system.local.broadcast_port when downgrading to v3
> -
>
> Key: CASSANDRA-18358
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18358
> Project: Cassandra
> Issue Type: Bug
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Normal
>
> {{system.local}} table 4.0 format adds the {{broadcast_port}} column. There
> is no way to make 3.x ignore it when we try to downgrade.
> There are some tables that are defined in code. (e.g. system.local)
> When v3 sstable schema for these tables detects:
> * a column in the sstable schema that is not in the data schema it creates a
> deleted column in the data schema.
> * a column in the data schema that is not in the sstable schema it throws an
> exception.
>
> There are two basic approaches to solve this:
> * rewrite the data so that the additional column is removed. This is an
> expensive process.
> * rework the code so that columns in the data but not in the table are
> ignored for this class of tables (statically defined in 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] [Created] (CASSANDRA-18625) Testing required to test upgrade and downgrade completeness
Claude Warren created CASSANDRA-18625: - Summary: Testing required to test upgrade and downgrade completeness Key: CASSANDRA-18625 URL: https://issues.apache.org/jira/browse/CASSANDRA-18625 Project: Cassandra Issue Type: Improvement Reporter: Claude Warren In the paper "Understanding and Detecting Software Upgrade Failures in Distributed Systems" the authors identify several hidden issues with Cassandra upgrade capabilities. Indeed these were submitted as bugs and fixed. The authors also point out that a failure during upgrade (or downgrade) is a critical failure often taking out a whole cluster. This issue is to find/create a testing library similar to the one described at [2] that is integrated into the Cassandra build system at appropriate points. Those points to be determined as development of the solution progresses. [1] [https://dl.acm.org/doi/10.1145/3477132.3483577] [2] https://sysartifacts.github.io/sosp2021/summaries/duptester -- This message was sent by Atlassian Jira (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-18625) Testing required to test upgrade and downgrade completeness
[ https://issues.apache.org/jira/browse/CASSANDRA-18625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren reassigned CASSANDRA-18625: - Assignee: Claude Warren > Testing required to test upgrade and downgrade completeness > --- > > Key: CASSANDRA-18625 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18625 > Project: Cassandra > Issue Type: Improvement >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Normal > > In the paper "Understanding and Detecting Software Upgrade Failures in > Distributed Systems" the authors identify several hidden issues with > Cassandra upgrade capabilities. Indeed these were submitted as bugs and > fixed. The authors also point out that a failure during upgrade (or > downgrade) is a critical failure often taking out a whole cluster. > This issue is to find/create a testing library similar to the one described > at [2] that is integrated into the Cassandra build system at appropriate > points. Those points to be determined as development of the solution > progresses. > > [1] [https://dl.acm.org/doi/10.1145/3477132.3483577] > [2] https://sysartifacts.github.io/sosp2021/summaries/duptester -- This message was sent by Atlassian Jira (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-18600) [Analytics] Add NOTICE.txt in Cassandra Analytics
[
https://issues.apache.org/jira/browse/CASSANDRA-18600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18600:
Reviewers: Berenguer Blasi, Dinesh Joshi, Michael Semb Wever
Status: Review In Progress (was: Needs Committer)
> [Analytics] Add NOTICE.txt in Cassandra Analytics
> --
>
> Key: CASSANDRA-18600
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18600
> Project: Cassandra
> Issue Type: Task
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The Cassandra Analytics project is missing the {{NOTICE.txt}} file required
> for compliance with the ASF guidance
--
This message was sent by Atlassian Jira
(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-18600) [Analytics] Add NOTICE.txt in Cassandra Analytics
[
https://issues.apache.org/jira/browse/CASSANDRA-18600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18600:
Status: Ready to Commit (was: Review In Progress)
> [Analytics] Add NOTICE.txt in Cassandra Analytics
> --
>
> Key: CASSANDRA-18600
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18600
> Project: Cassandra
> Issue Type: Task
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The Cassandra Analytics project is missing the {{NOTICE.txt}} file required
> for compliance with the ASF guidance
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
