[jira] [Commented] (CASSANDRA-16895) Support Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509144#comment-17509144 ] Ekaterina Dimitrova commented on CASSANDRA-16895: - PS I will make a list of all the dependency upgrades I had to do, for visibility... next week > Support Java 17 > --- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > 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 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16895) Support Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509143#comment-17509143
]
Ekaterina Dimitrova edited comment on CASSANDRA-16895 at 3/19/22, 2:38 AM:
---
Short update:
The bytebuddy issue was solved. I realized I have to update mockito which was
dependent on an old version of bytebuddy.
After update this is the latest CI run for Java 17:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1481/workflows/9f065c12-4c3d-4d6e-b9fc-ee4eb8c5f38b]
*CQLSH tests:*
* test_round_trip_random is failing with vnodes due to
{code:java}
Exception encountered during startup: The number of initial tokens (by
initial_token) specified (0) is different from num_tokens value (16){code}
Sounds weird, have to investigate it
*DTests:*
* test_oversized_mutation - known failure on trunk
* test_sjk - I just noticed we need to start Cassandra with _--add-exports
jdk.attach/sun.tools.attach=ALL-UNNAMED_ and then SJK works fine. Also, I
updated the SJK to the latest version
* There are 4 UDF functions I broke, please, ignore for now; just noise at
this point
* test_archiving_fql, test_archiving and test_fql_nodetool_options fail for
the same reason - a warning in the logs
{code:java}
Slf4jExceptionHandler.java:38 - Failed to shrink file as it exists no
longer{code}
I haven't had the chance to look at this one yet.
* test_batch_and_slice - fails with
{code:java}
Batch too large{code}
This also needs to be investigated
* test_failing_manual_rebuild_index - to be investigated
* test_hintedhandoff_window - I think this is a known issue
*JVM tests:*
* InternodeEncryptionOptionsTest - all failing if we run them together, but
locally when I run them separately
negotiatedProtocolMustBeAcceptedProtocolTest and
allInternodeEncryptionEstablishedTest are the only two failing in that class.
On a quick glance I think they were trying to use TLSv1 which as
[~maulin.vasavada] already mentioned is disabled in Java 17. To be checked
* bulkLoaderSuccessfullyStreamsOverSsl - to be checked; I guess could be again
the TLSv1
* testPreparedBatch, testReprepareNewBehaviour, testUseWithMultipleKeyspaces,
testReprepareTwoKeyspacesNewBehaviour, fuzzTest, startupNewIP,
sameIPFailWithoutReplace, sameIPFailWithoutReplace, mixedModeFuzzTest - all of
them hit CASSANDRA-16304; course of action TBD next week
* noWarningsSinglePartition, noWarningsScan - to be investigated
*Unit tests:*
* a few scripted UDF related tests, to be ignored
* EmptyValuesTest - the whole class; to be investigated
* testNoTreesRetainedAfterDifference - this one is really hungry for more and
more --add-opensI already opened a lot... to be checked further
* testTruncationReleasesLogSpace - this also needs more --add-opens
* testReplace - to be investigated
---
*To summarize -*
* 1 CQLSH python DTest
* 7 DTests failing (1 known fix and 3 failing for one and the same reason)
* 14 JVM tests – 3 probably TLSv1?, 9 because of CASSANDRA-16304
* 4 Unit tets - 2 of them probably just require more add-opens.
I have to take care of Jenkins, some adjustments around Java 11 upgrade tests
as up to now we were running them with Java 8
And I am wondering whether we don't want a feature branch for this one. Also, I
will be looking for reviewers at some point. Anyone interested to test how
things are going, just ping me on Slack. I will probably hit the mailing list
early next week. Have a nice weekend to whoever reads this :D
was (Author: e.dimitrova):
Short update:
The bytebuddy issue was solved. I realized I have to update mockito which was
dependent on an old version of bytebuddy.
After update this is the latest CI run for Java 17:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1481/workflows/9f065c12-4c3d-4d6e-b9fc-ee4eb8c5f38b]
*CQLSH tests:*
* test_round_trip_random is failing with vnodes due to
{code:java}
Exception encountered during startup: The number of initial tokens (by
initial_token) specified (0) is different from num_tokens value (16){code}
Sounds weird, have to investigate it
*DTests:*
* test_oversized_mutation - known failure on trunk
* test_sjk - I just noticed we need to start Cassandra with _--add-exports
jdk.attach/sun.tools.attach=ALL-UNNAMED_ and then SJK works fine. Also, I
updated the SJK to the latest version
* There are 4 UDF functions I broke, please, ignore for now; just noise at
this point
* test_archiving_fql, test_archiving and test_fql_nodetool_options fail for
the same reason - a warning in the logs
{code:java}
Slf4jExceptionHandler.java:38 - Failed to shrink file as it exists no
longer{code}
I haven't had the chance to look at this one yet.
* test_batch_and_slice - fails with
{code:java}
Batch too large{code}
This also needs to be investigated
*
[jira] [Comment Edited] (CASSANDRA-16895) Support Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509143#comment-17509143
]
Ekaterina Dimitrova edited comment on CASSANDRA-16895 at 3/19/22, 2:37 AM:
---
Short update:
The bytebuddy issue was solved. I realized I have to update mockito which was
dependent on an old version of bytebuddy.
After update this is the latest CI run for Java 17:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1481/workflows/9f065c12-4c3d-4d6e-b9fc-ee4eb8c5f38b]
*CQLSH tests:*
* test_round_trip_random is failing with vnodes due to
{code:java}
Exception encountered during startup: The number of initial tokens (by
initial_token) specified (0) is different from num_tokens value (16){code}
Sounds weird, have to investigate it
*DTests:*
* test_oversized_mutation - known failure on trunk
* test_sjk - I just noticed we need to start Cassandra with _--add-exports
jdk.attach/sun.tools.attach=ALL-UNNAMED_ and then SJK works fine. Also, I
updated the SJK to the latest version
* There are 4 UDF functions I broke, please, ignore for now; just noise at
this point
* test_archiving_fql, test_archiving and test_fql_nodetool_options fail for
the same reason - a warning in the logs
{code:java}
Slf4jExceptionHandler.java:38 - Failed to shrink file as it exists no
longer{code}
I haven't had the chance to look at this one yet.
* test_batch_and_slice - fails with
{code:java}
Batch too large{code}
This also needs to be investigated
* test_failing_manual_rebuild_index - to be investigated
* test_hintedhandoff_window - I think this is a known issue
*JVM tests:*
* InternodeEncryptionOptionsTest - all failing if we run them together, but
locally when I run them separately
negotiatedProtocolMustBeAcceptedProtocolTest and
allInternodeEncryptionEstablishedTest are the only two failing in that class.
On a quick glance I think they were trying to use TLSv1 which as
[~maulin.vasavada] already mentioned is disabled in Java 17. To be checked
* bulkLoaderSuccessfullyStreamsOverSsl - to be checked; I guess could be again
the TLSv1
* testPreparedBatch, testReprepareNewBehaviour, testUseWithMultipleKeyspaces,
testReprepareTwoKeyspacesNewBehaviour, fuzzTest, startupNewIP,
sameIPFailWithoutReplace, sameIPFailWithoutReplace, mixedModeFuzzTest - all of
them hit CASSANDRA-16304; course of action TBD next week
* noWarningsSinglePartition, noWarningsScan - to be investigated
*Unit tests:*
* a few scripted UDF related tests, to be ignored
* EmptyValuesTest - the whole class; to be investigated
* testNoTreesRetainedAfterDifference - this one is really hungry for more and
more --add-opensI already opened a lot... to be checked further
* testTruncationReleasesLogSpace - this also needs more --add-opens
* testReplace - to be investigated
---
*To summarize -*
* 1 CQLSH python DTest
* 7 DTests failing (1 known fix and 3 failing for one and the same reason)
* 14 JVM tests – 3 probably TLSv1?, 9 because of CASSANDRA-16304
* 4 Unit tets - 2 of them probably just require more add-opens.
I have to take care of Jenkins, some adjustments around Java 11 upgrade tests
as up to now we were running them with Java 8
And I am wondering whether we don't want a feature branch for this one. Also, I
will be looking for reviewers at some point. Anyone interested to test how
things are going, just ping me on Slack
was (Author: e.dimitrova):
Short update:
The bytebuddy issue was solved. I realized I have to update mockito which was
dependent on an old version of bytebuddy.
After update this is the latest CI run for Java 17:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1481/workflows/9f065c12-4c3d-4d6e-b9fc-ee4eb8c5f38b]
*CQLSH tests:*
* test_round_trip_random is failing with vnodes due to
{code:java}
Exception encountered during startup: The number of initial tokens (by
initial_token) specified (0) is different from num_tokens value (16){code}
Sounds weird, have to investigate it
*DTests:*
* test_oversized_mutation - known failure on trunk
* test_sjk - I just noticed we need to start Cassandra with _--add-exports
jdk.attach/sun.tools.attach=ALL-UNNAMED_ and then SJK works fine. Also, I
updated the SJK to the latest version
* There are 4 UDF functions I broke, please, ignore for now; just noise at
this point
* test_archiving_fql, test_archiving and test_fql_nodetool_options fail for
the same reason - a warning in the logs
{code:java}
Slf4jExceptionHandler.java:38 - Failed to shrink file as it exists no
longer{code}
I haven't had the chance to look at this one yet.
* test_batch_and_slice - fails with
{code:java}
Batch too large{code}
This also needs to be investigated
* test_failing_manual_rebuild_index - to be investigated
* test_hintedhandoff_window - I think this is a known
[jira] [Comment Edited] (CASSANDRA-16895) Support Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509143#comment-17509143
]
Ekaterina Dimitrova edited comment on CASSANDRA-16895 at 3/19/22, 2:37 AM:
---
Short update:
The bytebuddy issue was solved. I realized I have to update mockito which was
dependent on an old version of bytebuddy.
After update this is the latest CI run for Java 17:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1481/workflows/9f065c12-4c3d-4d6e-b9fc-ee4eb8c5f38b]
*CQLSH tests:*
* test_round_trip_random is failing with vnodes due to
{code:java}
Exception encountered during startup: The number of initial tokens (by
initial_token) specified (0) is different from num_tokens value (16){code}
Sounds weird, have to investigate it
*DTests:*
* test_oversized_mutation - known failure on trunk
* test_sjk - I just noticed we need to start Cassandra with _--add-exports
jdk.attach/sun.tools.attach=ALL-UNNAMED_ and then SJK works fine. Also, I
updated the SJK to the latest version
* There are 4 UDF functions I broke, please, ignore for now; just noise at
this point
* test_archiving_fql, test_archiving and test_fql_nodetool_options fail for
the same reason - a warning in the logs
{code:java}
Slf4jExceptionHandler.java:38 - Failed to shrink file as it exists no
longer{code}
I haven't had the chance to look at this one yet.
* test_batch_and_slice - fails with
{code:java}
Batch too large{code}
This also needs to be investigated
* test_failing_manual_rebuild_index - to be investigated
* test_hintedhandoff_window - I think this is a known issue
*JVM tests:*
* InternodeEncryptionOptionsTest - all failing if we run them together, but
locally when I run them separately
negotiatedProtocolMustBeAcceptedProtocolTest and
allInternodeEncryptionEstablishedTest are the only two failing in that class.
On a quick glance I think they were trying to use TLSv1 which as
[~maulin.vasavada] already mentioned is disabled in Java 17. To be checked
* bulkLoaderSuccessfullyStreamsOverSsl - to be checked; I guess could be again
the TLSv1
* testPreparedBatch, testReprepareNewBehaviour, testUseWithMultipleKeyspaces,
testReprepareTwoKeyspacesNewBehaviour, fuzzTest, startupNewIP,
sameIPFailWithoutReplace, sameIPFailWithoutReplace, mixedModeFuzzTest - all of
them hit CASSANDRA-16304; course of action TBD next week
* noWarningsSinglePartition, noWarningsScan - to be investigated
*Unit tests:*
* a few scripted UDF related tests, to be ignored
* EmptyValuesTest - the whole class; to be investigated
* testNoTreesRetainedAfterDifference - this one is really hungry for more and
more --add-opensI already opened a lot... to be checked further
* testTruncationReleasesLogSpace - this also needs more --add-opens
* testReplace - to be investigated
---
*To summarize -*
* 1 CQLSH python DTest
* 7 DTests failing (1 known fix and 3 failing for one and the same reason)
* 14 JVM tests – 3 probably TLSv1?, 9 because of CASSANDRA-16304
* 4 Unit tets - 2 probably just require more add-opens.
I have to take care of Jenkins, some adjustments around Java 11 upgrade tests
as up to now we were running them with Java 8
And I am wondering whether we don't want a feature branch for this one. Also, I
will be looking for reviewers at some point. Anyone interested to test how
things are going, just ping me on Slack
was (Author: e.dimitrova):
Short update:
The bytebuddy issue was solved. I realized I have to update mockito which was
dependent on an old version of bytebuddy.
After update this is the latest CI run for Java 17:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1481/workflows/9f065c12-4c3d-4d6e-b9fc-ee4eb8c5f38b]
*CQLSH tests:*
* test_round_trip_random is failing with vnodes due to
{code:java}
Exception encountered during startup: The number of initial tokens (by
initial_token) specified (0) is different from num_tokens value (16){code}
Sounds weird, have to investigate it
*DTests:*
* test_oversized_mutation - known failure on trunk
* test_sjk - I just noticed we need to start Cassandra with _--add-exports
jdk.attach/sun.tools.attach=ALL-UNNAMED_ and then SJK works fine. Also, I
updated the SJK to the latest version
* There are 4 UDF functions I broke, please, ignore for now; just noise at
this point
* test_archiving_fql, test_archiving and test_fql_nodetool_options fail for
the same reason - a warning in the logs
{code:java}
Slf4jExceptionHandler.java:38 - Failed to shrink file as it exists no
longer{code}
I haven't had the chance to look at this one yet.
* test_batch_and_slice - fails with
{code:java}
Batch too large{code}
This also needs to be investigated
* test_failing_manual_rebuild_index - to be investigated
* test_hintedhandoff_window - I think this is a known issue
*JVM
[jira] [Commented] (CASSANDRA-16895) Support Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509143#comment-17509143
]
Ekaterina Dimitrova commented on CASSANDRA-16895:
-
Short update:
The bytebuddy issue was solved. I realized I have to update mockito which was
dependent on an old version of bytebuddy.
After update this is the latest CI run for Java 17:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1481/workflows/9f065c12-4c3d-4d6e-b9fc-ee4eb8c5f38b]
*CQLSH tests:*
* test_round_trip_random is failing with vnodes due to
{code:java}
Exception encountered during startup: The number of initial tokens (by
initial_token) specified (0) is different from num_tokens value (16){code}
Sounds weird, have to investigate it
*DTests:*
* test_oversized_mutation - known failure on trunk
* test_sjk - I just noticed we need to start Cassandra with _--add-exports
jdk.attach/sun.tools.attach=ALL-UNNAMED_ and then SJK works fine. Also, I
updated the SJK to the latest version
* There are 4 UDF functions I broke, please, ignore for now; just noise at
this point
* test_archiving_fql, test_archiving and test_fql_nodetool_options fail for
the same reason - a warning in the logs
{code:java}
Slf4jExceptionHandler.java:38 - Failed to shrink file as it exists no
longer{code}
I haven't had the chance to look at this one yet.
* test_batch_and_slice - fails with
{code:java}
Batch too large{code}
This also needs to be investigated
* test_failing_manual_rebuild_index - to be investigated
* test_hintedhandoff_window - I think this is a known issue
*JVM tests:*
* InternodeEncryptionOptionsTest - all failing if we run them together, but
locally when I run them separately
negotiatedProtocolMustBeAcceptedProtocolTest and
allInternodeEncryptionEstablishedTest are the only two failing in that class.
On a quick glance I think they were trying to use TLSv1 which as
[~maulin.vasavada] already mentioned is disabled in Java 17. To be checked
* bulkLoaderSuccessfullyStreamsOverSsl - to be checked; I guess could be again
the TLSv1
* testPreparedBatch, testReprepareNewBehaviour, testUseWithMultipleKeyspaces,
testReprepareTwoKeyspacesNewBehaviour, fuzzTest, startupNewIP,
sameIPFailWithoutReplace, sameIPFailWithoutReplace, mixedModeFuzzTest - all of
them hit CASSANDRA-16304; course of action TBD next week
* noWarningsSinglePartition, noWarningsScan - to be investigated
*Unit tests:*
* a few scripted UDF related tests, to be ignored
* EmptyValuesTest - the whole class; to be investigated
* testNoTreesRetainedAfterDifference - this one is really hungry for more and
more --add-opensI already opened a lot... to be checked further
* testTruncationReleasesLogSpace - this also needs more --add-opens
* testReplace - to be investigated
---
*To summarize -*
* 1 CQLSH python DTest
* 7 DTests failing (1 known fix and 3 for the same reason)
* 14 JVM tests – 3 probably TLSv1?, 9 because of CASSANDRA-16304
* 4 Unit tets - 2 probably just require more add-opens.
I have to take care of Jenkins, some adjustments around Java 11 upgrade tests
as up to now we were running them with Java 8
And I am wondering whether we don't want a feature branch for this one. Also, I
will be looking for reviewers at some point. Anyone interested to test how
things are going, just ping me on Slack
> Support Java 17
> ---
>
> Key: CASSANDRA-16895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16895
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> 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
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17252) ConnectionLimitHandler may leaks connection count if remote connection drops
[
https://issues.apache.org/jira/browse/CASSANDRA-17252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-17252:
-
Status: Ready to Commit (was: Review In Progress)
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|cassandra-3.0|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17252-cassandra-3.0-D9AE02F1-3571-40CD-ACDC-7FA701325BEB]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17252-cassandra-3.0-D9AE02F1-3571-40CD-ACDC-7FA701325BEB]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1519/]|
|cassandra-3.11|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17252-cassandra-3.11-D9AE02F1-3571-40CD-ACDC-7FA701325BEB]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17252-cassandra-3.11-D9AE02F1-3571-40CD-ACDC-7FA701325BEB]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1520/]|
|cassandra-4.0|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17252-cassandra-4.0-D9AE02F1-3571-40CD-ACDC-7FA701325BEB]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17252-cassandra-4.0-D9AE02F1-3571-40CD-ACDC-7FA701325BEB]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1521/]|
|trunk|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17252-trunk-D9AE02F1-3571-40CD-ACDC-7FA701325BEB]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17252-trunk-D9AE02F1-3571-40CD-ACDC-7FA701325BEB]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1522/]|
> ConnectionLimitHandler may leaks connection count if remote connection drops
>
>
> Key: CASSANDRA-17252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17252
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> In some cases, Netty does not return the original IP used for per-IP counting
> when the channel becomes inactive,
> which throws an NPE before decrementing the active per-IP count.
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.transport.ConnectionLimitHandler.channelInactive(ConnectionLimitHandler.java:101)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248)
>at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:241)
>at
> io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:389)
>at
> io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:354)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248)
>at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:241)
>at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1405)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248)
>at
> io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901)
>at
> io.netty.channel.AbstractChannel$AbstractUnsafe$8.run(AbstractChannel.java:819)
>at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
>at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
>at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:497)
>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:834)
> {code}
--
This
[jira] [Commented] (CASSANDRA-17217) LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-17217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509087#comment-17509087
]
Yifan Cai commented on CASSANDRA-17217:
---
The flaky test is likely cause by the prior read query fails earlier than the
completion of the read command execution in each replica. A read is failed as
soon as one of the read command fails, and a failure is returned to client.
However, there could be still inflight read commands in the other replicas.
They will eventually fail and increment the counter.
For the test in question, once the size tracking is turned off, new queries
should not update the metrics, but the flakiness is cause by the prior read.
There is nothing wrong with the behavior. Probably either wait for some time
between each read query to make sure all replicas complete their read command.
Or even more clean, test without changing the size tracking in between. It
basically breaks the existing test into 2, read with size tracking and w/o.
> LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
> --
>
> Key: CASSANDRA-17217
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17217
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Fix For: 4.x
>
>
> The test
> {{org.apache.cassandra.distributed.test.trackwarnings.LocalReadSizeWarningTest#failThresholdSinglePartition}}
> seems to be flaky.
> It was discovered during CASSANDRA-17195 with [this CI
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1217/workflows/b366e352-0862-485a-acdc-5b75fe1ef575/jobs/11188].
> The failure can be reproduced running the test repeatedly for trunk, as it
> can be seen
> [here|https://app.circleci.com/pipelines/github/adelapena/cassandra/1219/workflows/a0c1fb7f-8a07-4fcf-97a4-7caf207dad78].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17448) allow users to change cqlsh history location using env variable
[
https://issues.apache.org/jira/browse/CASSANDRA-17448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509083#comment-17509083
]
Stefan Miklosovic edited comment on CASSANDRA-17448 at 3/18/22, 9:06 PM:
-
Yes. So, if CQL_HISTORY is empty string or not set at all, use default
destination. If it is set to something else, write it there. If it is
/dev/null, do not try to create directories leading to that file.
edit: I am not sure how save_history treats /dev/null, if it errors out or
what. That is interesting corner case. Have you already tested yet?
edit 2: yes, it works, readline.write_history_file('/dev/null') works just fine.
was (Author: smiklosovic):
Yes. So, if CQL_HISTORY is empty string or not set at all, use default
destination. If it is set to something else, write it there. If it is
/dev/null, do not try to create directories leading to that file.
edit: I am not sure how save_history treats /dev/null, if it errors out or
what. That is interesting corner case. Have you already tested yet?
> allow users to change cqlsh history location using env variable
> ---
>
> Key: CASSANDRA-17448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17448
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1
>
>
> User on GH sent:
> I just started using cassandra and found that it creates history folder in my
> home directory. I personally don't like it and all my folders follow XDG
> standard. I found stackoverflow question related to it which says that it's
> not possible to do without configuring source code of cqlsh.py.
> In this pull request I added a feature to choose history directory using
> environment variable. The name of variable is CQL_HISTORY. Why ? Because
> postgres and node-repl use approximately the same convention
> (NODE_REPL_HISTORY,PSQL_HISTORY). If you want I can change the name.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17448) allow users to change cqlsh history location using env variable
[ https://issues.apache.org/jira/browse/CASSANDRA-17448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509083#comment-17509083 ] Stefan Miklosovic edited comment on CASSANDRA-17448 at 3/18/22, 9:01 PM: - Yes. So, if CQL_HISTORY is empty string or not set at all, use default destination. If it is set to something else, write it there. If it is /dev/null, do not try to create directories leading to that file. edit: I am not sure how save_history treats /dev/null, if it errors out or what. That is interesting corner case. Have you already tested yet? was (Author: smiklosovic): Yes. So, if CQL_HISTORY is empty string or not set at all, use default destination. If it is set to something else, write it there. If it is /dev/null, do not try to create directories leading to that file. > allow users to change cqlsh history location using env variable > --- > > Key: CASSANDRA-17448 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17448 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > > User on GH sent: > I just started using cassandra and found that it creates history folder in my > home directory. I personally don't like it and all my folders follow XDG > standard. I found stackoverflow question related to it which says that it's > not possible to do without configuring source code of cqlsh.py. > In this pull request I added a feature to choose history directory using > environment variable. The name of variable is CQL_HISTORY. Why ? Because > postgres and node-repl use approximately the same convention > (NODE_REPL_HISTORY,PSQL_HISTORY). If you want I can change the name. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17448) allow users to change cqlsh history location using env variable
[ https://issues.apache.org/jira/browse/CASSANDRA-17448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509067#comment-17509067 ] Brandon Williams commented on CASSANDRA-17448: -- Or better yet always write it and users can point it at /dev/null. > allow users to change cqlsh history location using env variable > --- > > Key: CASSANDRA-17448 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17448 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > > User on GH sent: > I just started using cassandra and found that it creates history folder in my > home directory. I personally don't like it and all my folders follow XDG > standard. I found stackoverflow question related to it which says that it's > not possible to do without configuring source code of cqlsh.py. > In this pull request I added a feature to choose history directory using > environment variable. The name of variable is CQL_HISTORY. Why ? Because > postgres and node-repl use approximately the same convention > (NODE_REPL_HISTORY,PSQL_HISTORY). If you want I can change the name. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17246) DOCS - Update changed config + JVM, guide post CASSANDRA-15234
[ https://issues.apache.org/jira/browse/CASSANDRA-17246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509065#comment-17509065 ] Ekaterina Dimitrova commented on CASSANDRA-17246: - CASSANDRA-17456 > DOCS - Update changed config + JVM, guide post CASSANDRA-15234 > -- > > Key: CASSANDRA-17246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17246 > Project: Cassandra > Issue Type: Task > Components: Documentation/NEWS.txt, Documentation/Website >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1 > > > When CASSANDRA-15234 gets committed we need to update everywhere in the docs > the changed parameters names and we need to document: > * new types > * guide how to add new parameters > * some information about the backward compatibility framework > Possibly missing some bullets, to be considered while doing the actual work. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509064#comment-17509064 ] Ekaterina Dimitrova commented on CASSANDRA-17164: - CASSANDRA-17456 opened. I will link it to this one > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17456) Test Failures: write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
[
https://issues.apache.org/jira/browse/CASSANDRA-17456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509062#comment-17509062
]
Ekaterina Dimitrova commented on CASSANDRA-17456:
-
CC [~benedict]
> Test Failures:
> write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
> ---
>
> Key: CASSANDRA-17456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17456
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1002/testReport/dtest-offheap.write_failures_test/TestMultiDCWriteFailures/test_oversized_mutation/
> {code:java}
> Error Message
> AssertionError: assert 0 == 8 + where 8 = JolokiaAgent.read_attribute of 0x7f1fca78dac0>>('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
> 'Count') +where > =
> .read_attribute +
> and 'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
> make_mbean('metrics', type='Storage', name='TotalHints')
> Stacktrace
> self =
> def test_oversized_mutation(self):
> """
> Test that multi-DC write failures return operation failed rather
> than a timeout.
> @jira_ticket CASSANDRA-16334.
> """
>
> cluster = self.cluster
> cluster.populate([2, 2])
> cluster.set_configuration_options(values={'max_mutation_size_in_kb':
> 128})
> cluster.start()
>
> node1 = cluster.nodelist()[0]
> session = self.patient_exclusive_cql_connection(node1)
>
> session.execute("CREATE KEYSPACE k WITH replication = {'class':
> 'NetworkTopologyStrategy', 'dc1': 2, 'dc2': 2}")
> session.execute("CREATE TABLE k.t (key int PRIMARY KEY, val blob)")
>
> payload = '1' * 1024 * 256
> query = "INSERT INTO k.t (key, val) VALUES (1,
> textAsBlob('{}'))".format(payload)
>
> assert_write_failure(session, query, ConsistencyLevel.LOCAL_ONE)
> assert_write_failure(session, query, ConsistencyLevel.ONE)
>
> # verify that no hints are created
> with JolokiaAgent(node1) as jmx:
> > assert 0 == jmx.read_attribute(make_mbean('metrics',
> > type='Storage', name='TotalHints'), 'Count')
> E AssertionError: assert 0 == 8
> E+ where 8 = 0x7f1fca78dac0>>('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
> 'Count')
> E+where > =
> .read_attribute
> E+and
> 'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
> make_mbean('metrics', type='Storage', name='TotalHints')
> write_failures_test.py:277: AssertionError
> REST API
> CloudBees CI Client Controller 2.319.3.4-rolling
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17456) Test Failures: write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
[
https://issues.apache.org/jira/browse/CASSANDRA-17456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17456:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: Unit Test
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failures:
> write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
> ---
>
> Key: CASSANDRA-17456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17456
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1002/testReport/dtest-offheap.write_failures_test/TestMultiDCWriteFailures/test_oversized_mutation/
> {code:java}
> Error Message
> AssertionError: assert 0 == 8 + where 8 = JolokiaAgent.read_attribute of 0x7f1fca78dac0>>('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
> 'Count') +where > =
> .read_attribute +
> and 'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
> make_mbean('metrics', type='Storage', name='TotalHints')
> Stacktrace
> self =
> def test_oversized_mutation(self):
> """
> Test that multi-DC write failures return operation failed rather
> than a timeout.
> @jira_ticket CASSANDRA-16334.
> """
>
> cluster = self.cluster
> cluster.populate([2, 2])
> cluster.set_configuration_options(values={'max_mutation_size_in_kb':
> 128})
> cluster.start()
>
> node1 = cluster.nodelist()[0]
> session = self.patient_exclusive_cql_connection(node1)
>
> session.execute("CREATE KEYSPACE k WITH replication = {'class':
> 'NetworkTopologyStrategy', 'dc1': 2, 'dc2': 2}")
> session.execute("CREATE TABLE k.t (key int PRIMARY KEY, val blob)")
>
> payload = '1' * 1024 * 256
> query = "INSERT INTO k.t (key, val) VALUES (1,
> textAsBlob('{}'))".format(payload)
>
> assert_write_failure(session, query, ConsistencyLevel.LOCAL_ONE)
> assert_write_failure(session, query, ConsistencyLevel.ONE)
>
> # verify that no hints are created
> with JolokiaAgent(node1) as jmx:
> > assert 0 == jmx.read_attribute(make_mbean('metrics',
> > type='Storage', name='TotalHints'), 'Count')
> E AssertionError: assert 0 == 8
> E+ where 8 = 0x7f1fca78dac0>>('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
> 'Count')
> E+where > =
> .read_attribute
> E+and
> 'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
> make_mbean('metrics', type='Storage', name='TotalHints')
> write_failures_test.py:277: AssertionError
> REST API
> CloudBees CI Client Controller 2.319.3.4-rolling
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17456) Test Failures: write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
[
https://issues.apache.org/jira/browse/CASSANDRA-17456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17456:
Fix Version/s: 4.x
> Test Failures:
> write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
> ---
>
> Key: CASSANDRA-17456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17456
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1002/testReport/dtest-offheap.write_failures_test/TestMultiDCWriteFailures/test_oversized_mutation/
> {code:java}
> Error Message
> AssertionError: assert 0 == 8 + where 8 = JolokiaAgent.read_attribute of 0x7f1fca78dac0>>('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
> 'Count') +where > =
> .read_attribute +
> and 'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
> make_mbean('metrics', type='Storage', name='TotalHints')
> Stacktrace
> self =
> def test_oversized_mutation(self):
> """
> Test that multi-DC write failures return operation failed rather
> than a timeout.
> @jira_ticket CASSANDRA-16334.
> """
>
> cluster = self.cluster
> cluster.populate([2, 2])
> cluster.set_configuration_options(values={'max_mutation_size_in_kb':
> 128})
> cluster.start()
>
> node1 = cluster.nodelist()[0]
> session = self.patient_exclusive_cql_connection(node1)
>
> session.execute("CREATE KEYSPACE k WITH replication = {'class':
> 'NetworkTopologyStrategy', 'dc1': 2, 'dc2': 2}")
> session.execute("CREATE TABLE k.t (key int PRIMARY KEY, val blob)")
>
> payload = '1' * 1024 * 256
> query = "INSERT INTO k.t (key, val) VALUES (1,
> textAsBlob('{}'))".format(payload)
>
> assert_write_failure(session, query, ConsistencyLevel.LOCAL_ONE)
> assert_write_failure(session, query, ConsistencyLevel.ONE)
>
> # verify that no hints are created
> with JolokiaAgent(node1) as jmx:
> > assert 0 == jmx.read_attribute(make_mbean('metrics',
> > type='Storage', name='TotalHints'), 'Count')
> E AssertionError: assert 0 == 8
> E+ where 8 = 0x7f1fca78dac0>>('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
> 'Count')
> E+where > =
> .read_attribute
> E+and
> 'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
> make_mbean('metrics', type='Storage', name='TotalHints')
> write_failures_test.py:277: AssertionError
> REST API
> CloudBees CI Client Controller 2.319.3.4-rolling
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17456) Test Failures: write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
[
https://issues.apache.org/jira/browse/CASSANDRA-17456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17456:
Description:
https://ci-cassandra.apache.org/job/Cassandra-trunk/1002/testReport/dtest-offheap.write_failures_test/TestMultiDCWriteFailures/test_oversized_mutation/
{code:java}
Error Message
AssertionError: assert 0 == 8 + where 8 = >('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
'Count') +where > =
.read_attribute +and
'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
make_mbean('metrics', type='Storage', name='TotalHints')
Stacktrace
self =
def test_oversized_mutation(self):
"""
Test that multi-DC write failures return operation failed rather
than a timeout.
@jira_ticket CASSANDRA-16334.
"""
cluster = self.cluster
cluster.populate([2, 2])
cluster.set_configuration_options(values={'max_mutation_size_in_kb':
128})
cluster.start()
node1 = cluster.nodelist()[0]
session = self.patient_exclusive_cql_connection(node1)
session.execute("CREATE KEYSPACE k WITH replication = {'class':
'NetworkTopologyStrategy', 'dc1': 2, 'dc2': 2}")
session.execute("CREATE TABLE k.t (key int PRIMARY KEY, val blob)")
payload = '1' * 1024 * 256
query = "INSERT INTO k.t (key, val) VALUES (1,
textAsBlob('{}'))".format(payload)
assert_write_failure(session, query, ConsistencyLevel.LOCAL_ONE)
assert_write_failure(session, query, ConsistencyLevel.ONE)
# verify that no hints are created
with JolokiaAgent(node1) as jmx:
> assert 0 == jmx.read_attribute(make_mbean('metrics',
> type='Storage', name='TotalHints'), 'Count')
E AssertionError: assert 0 == 8
E+ where 8 = >('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
'Count')
E+where > =
.read_attribute
E+and
'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
make_mbean('metrics', type='Storage', name='TotalHints')
write_failures_test.py:277: AssertionError
REST API
CloudBees CI Client Controller 2.319.3.4-rolling
{code}
was:
{code:java}
Error Message
AssertionError: assert 0 == 8 + where 8 = >('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
'Count') +where > =
.read_attribute +and
'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
make_mbean('metrics', type='Storage', name='TotalHints')
Stacktrace
self =
def test_oversized_mutation(self):
"""
Test that multi-DC write failures return operation failed rather
than a timeout.
@jira_ticket CASSANDRA-16334.
"""
cluster = self.cluster
cluster.populate([2, 2])
cluster.set_configuration_options(values={'max_mutation_size_in_kb':
128})
cluster.start()
node1 = cluster.nodelist()[0]
session = self.patient_exclusive_cql_connection(node1)
session.execute("CREATE KEYSPACE k WITH replication = {'class':
'NetworkTopologyStrategy', 'dc1': 2, 'dc2': 2}")
session.execute("CREATE TABLE k.t (key int PRIMARY KEY, val blob)")
payload = '1' * 1024 * 256
query = "INSERT INTO k.t (key, val) VALUES (1,
textAsBlob('{}'))".format(payload)
assert_write_failure(session, query, ConsistencyLevel.LOCAL_ONE)
assert_write_failure(session, query, ConsistencyLevel.ONE)
# verify that no hints are created
with JolokiaAgent(node1) as jmx:
> assert 0 == jmx.read_attribute(make_mbean('metrics',
> type='Storage', name='TotalHints'), 'Count')
E AssertionError: assert 0 == 8
E+ where 8 = >('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
'Count')
E+where > =
.read_attribute
E+and
'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
make_mbean('metrics', type='Storage', name='TotalHints')
write_failures_test.py:277: AssertionError
REST API
CloudBees CI Client Controller 2.319.3.4-rolling
{code}
> Test Failures:
> write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
> ---
>
> Key: CASSANDRA-17456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17456
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1002/testReport/dtest-offheap.write_failures_test/TestMultiDCWriteFailures/test_oversized_mutation/
> {code:java}
> Error Message
> AssertionError: assert 0 == 8 + where 8 = JolokiaAgent.read_attribute of
[jira] [Created] (CASSANDRA-17456) Test Failures: write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
Ekaterina Dimitrova created CASSANDRA-17456:
---
Summary: Test Failures:
write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
Key: CASSANDRA-17456
URL: https://issues.apache.org/jira/browse/CASSANDRA-17456
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
{code:java}
Error Message
AssertionError: assert 0 == 8 + where 8 = >('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
'Count') +where > =
.read_attribute +and
'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
make_mbean('metrics', type='Storage', name='TotalHints')
Stacktrace
self =
def test_oversized_mutation(self):
"""
Test that multi-DC write failures return operation failed rather
than a timeout.
@jira_ticket CASSANDRA-16334.
"""
cluster = self.cluster
cluster.populate([2, 2])
cluster.set_configuration_options(values={'max_mutation_size_in_kb':
128})
cluster.start()
node1 = cluster.nodelist()[0]
session = self.patient_exclusive_cql_connection(node1)
session.execute("CREATE KEYSPACE k WITH replication = {'class':
'NetworkTopologyStrategy', 'dc1': 2, 'dc2': 2}")
session.execute("CREATE TABLE k.t (key int PRIMARY KEY, val blob)")
payload = '1' * 1024 * 256
query = "INSERT INTO k.t (key, val) VALUES (1,
textAsBlob('{}'))".format(payload)
assert_write_failure(session, query, ConsistencyLevel.LOCAL_ONE)
assert_write_failure(session, query, ConsistencyLevel.ONE)
# verify that no hints are created
with JolokiaAgent(node1) as jmx:
> assert 0 == jmx.read_attribute(make_mbean('metrics',
> type='Storage', name='TotalHints'), 'Count')
E AssertionError: assert 0 == 8
E+ where 8 = >('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
'Count')
E+where > =
.read_attribute
E+and
'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
make_mbean('metrics', type='Storage', name='TotalHints')
write_failures_test.py:277: AssertionError
REST API
CloudBees CI Client Controller 2.319.3.4-rolling
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509056#comment-17509056 ] Ekaterina Dimitrova commented on CASSANDRA-17164: - I will open a ticket. Thanks for the quick response > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509055#comment-17509055 ] Stefan Miklosovic commented on CASSANDRA-17164: --- [~adelapena] would you cover me here mate? I am out, filled other tickets and this one just slipped through. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509053#comment-17509053 ] Ekaterina Dimitrova edited comment on CASSANDRA-17164 at 3/18/22, 7:41 PM: --- I didn't find a ticket for this one and it is consistently failing. Is there a plan? Or a ticket that I am missing? CC our build lead this week [~stefan.miklosovic] was (Author: e.dimitrova): I didn't find a ticket for this one and it is consistently failing. Is there a plan? Or a ticket for it? CC our build lead this week [~stefan.miklosovic] > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509053#comment-17509053 ] Ekaterina Dimitrova commented on CASSANDRA-17164: - I didn't find a ticket for this one and it is consistently failing. Is there a plan? Or a ticket for it? CC our build lead this week [~stefan.miklosovic] > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17453) flaky in jvm CasCriticalSectionTest.criticalSectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509051#comment-17509051
]
Ekaterina Dimitrova commented on CASSANDRA-17453:
-
Appeared in one of my runs today:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1480/workflows/c2fa1dbc-74a2-4b8d-b200-185d6ecfd909/jobs/9648/tests#failed-test-0]
I saw it these days a few times, maybe it should be checked with [~benedict] if
it can be related to the latest paxos changes?
> flaky in jvm CasCriticalSectionTest.criticalSectionTest
> ---
>
> Key: CASSANDRA-17453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17453
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> From CI, there are variations of this error:
> {code:java}
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 0 of 3 required responses after 0 contention retries at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:732) at
> org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618) at
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307) at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17144) Fix test TestHintedHandoff#test_hintedhandoff_window
[
https://issues.apache.org/jira/browse/CASSANDRA-17144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509049#comment-17509049
]
Ekaterina Dimitrova commented on CASSANDRA-17144:
-
Still saw It failing today:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1480/workflows/b51909eb-633e-45f1-8dcc-eb43eb48fa38/jobs/9659]
I didn't find in in Butler, so I guess it is more common with the midres in
CircleCI
> Fix test TestHintedHandoff#test_hintedhandoff_window
>
>
> Key: CASSANDRA-17144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17144
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> This test fails from time to time (see butler
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/hintedhandoff_test/TestHintedHandoff/test_hintedhandoff_window)
> Example:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1101/workflows/7afb1c7e-8330-4ac6-963d-d7864282f2f3/jobs/7877
> {code}
> # Ensure second and third datasets are not present
> for x in range(100, 300):
> > query_c1c2(session, x, ConsistencyLevel.ONE,
> > tolerate_missing=True, must_be_missing=True)
> hintedhandoff_test.py:264:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:44: in query_c1c2
> assertions.assert_length_equal(rows, 0)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> object_with_length = [Row(c1='value1', c2='value2')], expected_length = 0
> def assert_length_equal(object_with_length, expected_length):
> """
> Assert an object has a specific length.
> @param object_with_length The object whose length will be checked
> @param expected_length The expected length of the object
>
> Examples:
> assert_length_equal(res, nb_counter)
> """
> assert len(object_with_length) == expected_length, \
> "Expected {} to have length {}, but instead is of length {}"\
> > .format(object_with_length, expected_length,
> > len(object_with_length))
> E AssertionError: Expected [Row(c1='value1', c2='value2')] to have
> length 0, but instead is of length 1
> tools/assertions.py:269: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17448) allow users to change cqlsh history location using env variable
[ https://issues.apache.org/jira/browse/CASSANDRA-17448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509031#comment-17509031 ] Brandon Williams commented on CASSANDRA-17448: -- If the var is set to empty, do not write history. If the var is completely unset, preserve the current behavior. > allow users to change cqlsh history location using env variable > --- > > Key: CASSANDRA-17448 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17448 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > > User on GH sent: > I just started using cassandra and found that it creates history folder in my > home directory. I personally don't like it and all my folders follow XDG > standard. I found stackoverflow question related to it which says that it's > not possible to do without configuring source code of cqlsh.py. > In this pull request I added a feature to choose history directory using > environment variable. The name of variable is CQL_HISTORY. Why ? Because > postgres and node-repl use approximately the same convention > (NODE_REPL_HISTORY,PSQL_HISTORY). If you want I can change the name. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17448) allow users to change cqlsh history location using env variable
[ https://issues.apache.org/jira/browse/CASSANDRA-17448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509029#comment-17509029 ] Stefan Miklosovic commented on CASSANDRA-17448: --- [~brandon.williams] I dont think this is a good idea. Hear me out please. Currently, users do not set this variable (CQL_HISTORY) and CQL history written to cqlsh_history file. If we control wether history should be written to a file or not, from 4.1 onwards, effectively, users will not have any history persisted without setting that variable first. So we go from "by default writing history" to "by default do not write history". Is this really something we want? I think it is pretty inconvenient to suddenly not have history written. > allow users to change cqlsh history location using env variable > --- > > Key: CASSANDRA-17448 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17448 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > > User on GH sent: > I just started using cassandra and found that it creates history folder in my > home directory. I personally don't like it and all my folders follow XDG > standard. I found stackoverflow question related to it which says that it's > not possible to do without configuring source code of cqlsh.py. > In this pull request I added a feature to choose history directory using > environment variable. The name of variable is CQL_HISTORY. Why ? Because > postgres and node-repl use approximately the same convention > (NODE_REPL_HISTORY,PSQL_HISTORY). If you want I can change the name. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509019#comment-17509019
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
Doc committed here -
https://github.com/apache/cassandra/commit/d67be0def4085863a039d5d3809a9457e883919b
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509019#comment-17509019
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 3/18/22, 6:57 PM:
---
CCM issue was fixed last week. No workarounds needed.
Doc committed here -
[https://github.com/apache/cassandra/commit/d67be0def4085863a039d5d3809a9457e883919b]
was (Author: e.dimitrova):
Doc committed here -
https://github.com/apache/cassandra/commit/d67be0def4085863a039d5d3809a9457e883919b
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Add docs about configuration framework added in CASSANDRA-15234 patch by Ekaterina Dimitrova; reviewed by Michael Semb Wever and Caleb Rackliffe for CASSANDRA-17246
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new d67be0d Add docs about configuration framework added in CASSANDRA-15234 patch by Ekaterina Dimitrova; reviewed by Michael Semb Wever and Caleb Rackliffe for CASSANDRA-17246 d67be0d is described below commit d67be0def4085863a039d5d3809a9457e883919b Author: Ekaterina Dimitrova AuthorDate: Thu Feb 17 18:51:22 2022 -0500 Add docs about configuration framework added in CASSANDRA-15234 patch by Ekaterina Dimitrova; reviewed by Michael Semb Wever and Caleb Rackliffe for CASSANDRA-17246 --- NEWS.txt | 9 + .../cassandra/pages/architecture/snitch.adoc | 4 +- .../pages/architecture/storage_engine.adoc | 26 +-- doc/modules/cassandra/pages/cql/functions.adoc | 2 +- doc/modules/cassandra/pages/faq/index.adoc | 6 +- doc/modules/cassandra/pages/new/configuration.adoc | 192 + doc/modules/cassandra/pages/new/messaging.adoc | 18 +- doc/modules/cassandra/pages/new/streaming.adoc | 16 +- .../cassandra/pages/new/transientreplication.adoc | 2 +- doc/modules/cassandra/pages/new/virtualtables.adoc | 2 +- doc/modules/cassandra/pages/operating/cdc.adoc | 4 +- doc/modules/cassandra/pages/operating/hints.adoc | 30 ++-- .../cassandra/pages/operating/topo_changes.adoc| 4 +- .../pages/tools/sstable/sstableloader.adoc | 2 +- 14 files changed, 259 insertions(+), 58 deletions(-) diff --git a/NEWS.txt b/NEWS.txt index 3ed36a7..5cad3e6 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -116,6 +116,15 @@ New features Upgrading - +- We added new JMX methods `setStreamThroughputMbitPerSec`, `getStreamThroughputMbitPerSec`, `setInterDCStreamThroughputMbitPerSec`, + `getInterDCStreamThroughputMbitPerSec` to the JMX MBean `org.apache.cassandra.db:type=StorageService`. They replace the now + deprecated methods `setStreamThroughputMbPerSec`, `getStreamThroughputMbPerSec`, `setInterDCStreamThroughputMbPerSec`, and + `getInterDCStreamThroughputMbPerSec`, which will be removed in a future major release. +- The config property `repair_session_space_in_mb` was wrongly advertised in previous versions that it should be set in + megabytes when it is interpreted internally in mebibytes. To reduce the confusion we added two new JMX methods + `setRepairSessionSpaceInMebibytes(int sizeInMebibytes)` and `getRepairSessionSpaceInMebibytes`. They replace the now + deprecated methods `setRepairSessionSpaceInMegabytes(int sizeInMegabytes)` and `getRepairSessionSpaceInMegabytes`, which + will be removed in a future major release. - There is a new cassandra.yaml version 2. Units suffixes should be provided for all rates(B/s|MiB/s|KiB/s|MiB/s), memory (KiB|MiB|GiB|B) and duration(d|h|s|ms|us|µs|ns|m) parameters. (CASSANDRA-15234) diff --git a/doc/modules/cassandra/pages/architecture/snitch.adoc b/doc/modules/cassandra/pages/architecture/snitch.adoc index 90b32fb..3ae066d 100644 --- a/doc/modules/cassandra/pages/architecture/snitch.adoc +++ b/doc/modules/cassandra/pages/architecture/snitch.adoc @@ -18,9 +18,9 @@ following properties on `cassandra.yaml`: * `dynamic_snitch`: whether the dynamic snitch should be enabled or disabled. -* `dynamic_snitch_update_interval_in_ms`: controls how often to perform +* `dynamic_snitch_update_interval`: 100ms, controls how often to perform the more expensive part of host score calculation. -* `dynamic_snitch_reset_interval_in_ms`: if set greater than zero, this +* `dynamic_snitch_reset_interval`: 10m, if set greater than zero, this will allow 'pinning' of replicas to hosts in order to increase cache capacity. * `dynamic_snitch_badness_threshold:`: The badness threshold will diff --git a/doc/modules/cassandra/pages/architecture/storage_engine.adoc b/doc/modules/cassandra/pages/architecture/storage_engine.adoc index 77c52e5..9a0c37a 100644 --- a/doc/modules/cassandra/pages/architecture/storage_engine.adoc +++ b/doc/modules/cassandra/pages/architecture/storage_engine.adoc @@ -11,7 +11,7 @@ will be applied to memtables. All mutations write optimized by storing in commitlog segments, reducing the number of seeks needed to write to disk. Commitlog Segments are -limited by the `commitlog_segment_size_in_mb` option, once the size is +limited by the `commitlog_segment_size` option, once the size is reached, a new commitlog segment is created. Commitlog segments can be archived, deleted, or recycled once all its data has been flushed to SSTables. Commitlog segments are truncated when Cassandra has written @@ -19,16 +19,16 @@ data older than a certain point to the SSTables. Running "nodetool drain" before stopping Cassandra will write
[jira] [Updated] (CASSANDRA-17246) DOCS - Update changed config + JVM, guide post CASSANDRA-15234
[ https://issues.apache.org/jira/browse/CASSANDRA-17246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17246: Fix Version/s: 4.1 (was: 4.x) Source Control Link: https://github.com/apache/cassandra/commit/d67be0def4085863a039d5d3809a9457e883919b Resolution: Fixed Status: Resolved (was: Ready to Commit) > DOCS - Update changed config + JVM, guide post CASSANDRA-15234 > -- > > Key: CASSANDRA-17246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17246 > Project: Cassandra > Issue Type: Task > Components: Documentation/NEWS.txt, Documentation/Website >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1 > > > When CASSANDRA-15234 gets committed we need to update everywhere in the docs > the changed parameters names and we need to document: > * new types > * guide how to add new parameters > * some information about the backward compatibility framework > Possibly missing some bullets, to be considered while doing the actual work. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17246) DOCS - Update changed config + JVM, guide post CASSANDRA-15234
[ https://issues.apache.org/jira/browse/CASSANDRA-17246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17246: Status: Ready to Commit (was: Review In Progress) > DOCS - Update changed config + JVM, guide post CASSANDRA-15234 > -- > > Key: CASSANDRA-17246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17246 > Project: Cassandra > Issue Type: Task > Components: Documentation/NEWS.txt, Documentation/Website >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > When CASSANDRA-15234 gets committed we need to update everywhere in the docs > the changed parameters names and we need to document: > * new types > * guide how to add new parameters > * some information about the backward compatibility framework > Possibly missing some bullets, to be considered while doing the actual work. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17246) DOCS - Update changed config + JVM, guide post CASSANDRA-15234
[ https://issues.apache.org/jira/browse/CASSANDRA-17246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509016#comment-17509016 ] Ekaterina Dimitrova commented on CASSANDRA-17246: - Committed to trunk: To [https://github.com/apache/cassandra.git] 34a7eba4b8..d67be0def4 trunk -> trunk CI: [j8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1480/workflows/b51909eb-633e-45f1-8dcc-eb43eb48fa38], [j11 |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1480/workflows/c2fa1dbc-74a2-4b8d-b200-185d6ecfd909] had just a few known failures. I will check in a minute whether all of them already have tickets though. If not I will open some. > DOCS - Update changed config + JVM, guide post CASSANDRA-15234 > -- > > Key: CASSANDRA-17246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17246 > Project: Cassandra > Issue Type: Task > Components: Documentation/NEWS.txt, Documentation/Website >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > When CASSANDRA-15234 gets committed we need to update everywhere in the docs > the changed parameters names and we need to document: > * new types > * guide how to add new parameters > * some information about the backward compatibility framework > Possibly missing some bullets, to be considered while doing the actual work. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17197) Diagnostic events for guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509008#comment-17509008
]
Andres de la Peña commented on CASSANDRA-17197:
---
It seems that the problem was that {{{}CQLTester{}}}'s asynchronous cleanup
task was messing with the tests, as we have already found while fixing other
flaky tests. That task produces an asynchronous flush of the tables created by
the test. Since those tables contain large collections, their asynchronous
flushing will emit diagnostic events that might be visible for the next tests.
I have modified the tests to immediately drop the tables at termination, so
there isn't anything for the async cleanup task. I have also disabled
autocompaction for the created tables, since that might be problematic too.
Here is CI doubling the number of iterations:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1485]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1384/workflows/93f9dee0-e2c8-4223-9b07-298d2f4a1ebe]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1384/workflows/d4fdc205-eed0-4e8a-babc-874602646fd6]|
> Diagnostic events for guardrails
>
>
> Key: CASSANDRA-17197
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17197
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add diagnostic events for guardrails, so we can monitor when each type of
> guardrail is triggered.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16895) Support Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508996#comment-17508996
]
Ekaterina Dimitrova commented on CASSANDRA-16895:
-
Thanks [~maulin.vasavada] , it is the netty upgrade that breaks things, that's
all I can say for now. Not upgrading it, tests look fine.
{quote}However based on Ekaterina's findings it seems the Netty upgrade may be
the cause of the underlying failure. My initial research was just based on the
test run logs I could see `assert "Connection e...c:2635)')})\n" == '' -
Connection error: ('Unable to connect to any servers',
{'127.0.0.1:9042': ConnectionShutdown('[SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1
alert internal error (_ssl.c:2635)')}
)` .
{quote}
I realized you looked into that one, that is why I pointed to the stack trace
for more details. Thanks again for looking into it :)
> Support Java 17
> ---
>
> Key: CASSANDRA-16895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16895
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> 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
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17140) Broken test_rolling_upgrade - upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
[
https://issues.apache.org/jira/browse/CASSANDRA-17140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508987#comment-17508987
]
Josh McKenzie commented on CASSANDRA-17140:
---
Regardless, I've been swamped. If you want to swap [~bereng] (you take assignee
I'll take review) on this one I'm happy to hand it off.
> Broken test_rolling_upgrade -
> upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
>
>
> Key: CASSANDRA-17140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17140
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Yifan Cai
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.0.x
>
>
> The tests "test_rolling_upgrade" fail with the below error.
>
> [https://app.circleci.com/pipelines/github/yifan-c/cassandra/279/workflows/6340cd42-0b27-42c2-8418-9f8b56c57bea/jobs/1990]
>
> I am able to alway produce it by running the test locally too.
> {{$ pytest --execute-upgrade-tests-only --upgrade-target-version-only
> --upgrade-version-selection all --cassandra-version=4.0
> upgrade_tests/upgrade_through_versions_test.py::TestUpgrade_indev_3_11_x_To_indev_4_0_x::test_rolling_upgrade}}
>
> {code:java}
> self =
> object at 0x7ffba4242fd0>
> subprocs = [,
> ]
> def _check_on_subprocs(self, subprocs):
> """
> Check on given subprocesses.
>
> If any are not alive, we'll go ahead and terminate any remaining
> alive subprocesses since this test is going to fail.
> """
> subproc_statuses = [s.is_alive() for s in subprocs]
> if not all(subproc_statuses):
> message = "A subprocess has terminated early. Subprocess
> statuses: "
> for s in subprocs:
> message += "{name} (is_alive: {aliveness}),
> ".format(name=s.name, aliveness=s.is_alive())
> message += "attempting to terminate remaining subprocesses now."
> self._terminate_subprocs()
> > raise RuntimeError(message)
> E RuntimeError: A subprocess has terminated early. Subprocess
> statuses: Process-1 (is_alive: True), Process-2 (is_alive: False), attempting
> to terminate remaining subprocesses now.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17425) Add new CQL function maxWritetime
[ https://issues.apache.org/jira/browse/CASSANDRA-17425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508970#comment-17508970 ] Yifan Cai commented on CASSANDRA-17425: --- Sounds great! I will sign up for reviewing :D > Add new CQL function maxWritetime > - > > Key: CASSANDRA-17425 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17425 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Syntax >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > The function "writetime" does not support multi-cell types, e.g. collections > and UDT. It would be useful to enable querying the latest modified timestamp > of a column value. > I'd like to propose to add a new function named "maxWritetime", which returns > the largest timestamp amongst the cells. When being applied to the single > cell types, it returns the same result as "writetime". -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17425) Add new CQL function maxWritetime
[ https://issues.apache.org/jira/browse/CASSANDRA-17425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508967#comment-17508967 ] Andres de la Peña commented on CASSANDRA-17425: --- Hi [~yifanc] I was planning on updating the old patch for CASSANDRA-8877 immediately after [~blerer] 's patch for CASSANDRA-11871, which probably would be ready for review very soon. > Add new CQL function maxWritetime > - > > Key: CASSANDRA-17425 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17425 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Syntax >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > The function "writetime" does not support multi-cell types, e.g. collections > and UDT. It would be useful to enable querying the latest modified timestamp > of a column value. > I'd like to propose to add a new function named "maxWritetime", which returns > the largest timestamp amongst the cells. When being applied to the single > cell types, it returns the same result as "writetime". -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17425) Add new CQL function maxWritetime
[ https://issues.apache.org/jira/browse/CASSANDRA-17425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508963#comment-17508963 ] Yifan Cai commented on CASSANDRA-17425: --- bq. selectors can be chained and used to reduce the selection. Good point. The patch does not handle the chained selector for collections and UDT. So it is incomplete in terms of semantics. And I agree that it should be implemented. Hi [~adelapena], it looks like that your patch already defines the syntax handling for the chained selectors. I think this logic is reused for 'maxTimestamp'. Do you plan to work on the patch for CASSANDRA-8877 any time soon? If not, do you mind if I jump in? > Add new CQL function maxWritetime > - > > Key: CASSANDRA-17425 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17425 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Syntax >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > The function "writetime" does not support multi-cell types, e.g. collections > and UDT. It would be useful to enable querying the latest modified timestamp > of a column value. > I'd like to propose to add a new function named "maxWritetime", which returns > the largest timestamp amongst the cells. When being applied to the single > cell types, it returns the same result as "writetime". -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16895) Support Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508583#comment-17508583
]
Maulin Vasavada edited comment on CASSANDRA-16895 at 3/18/22, 5:12 PM:
---
I guess it could be because prior TLS versions ({-}before{-} prior to TLSv1.2)
are disabled in JDK 17 and the python client in python 3.8 might be defaulting
to those. Not sure though, trying to look into it more.
was (Author: maulin.vasavada):
I guess it could be because prior TLS versions (before TLSv1.2) are disabled in
JDK 17 and the python client in python 3.8 might be defaulting to those. Not
sure though, trying to look into it more.
> Support Java 17
> ---
>
> Key: CASSANDRA-16895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16895
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> 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
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16895) Support Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508959#comment-17508959
]
Maulin Vasavada edited comment on CASSANDRA-16895 at 3/18/22, 5:11 PM:
---
Yes I am with you guys [~brandon.williams] and [~e.dimitrova] . I meant
versions prior to TLSv1.2 are disabled in Jdk 17. Hence my initial guess was -
what TLS protocol it uses when we trigger the run_cqlsh() from the python test.
If that was passing/using older version of the TLS than v1.2 it could fail.
Basically, if my understanding is right, the test is running cqlsh to describe
namespace and uses ssl options specifying the certificate so I assume it
connects to the node started by the test over ssl.
However based on Ekaterina's findings it seems the Netty upgrade may be the
cause of the underlying failure. My initial research was just based on the test
run logs I could see `assert "Connection e...c:2635)')})\n" == '' - Connection
error: ('Unable to connect to any servers',
{'127.0.0.1:9042': ConnectionShutdown('[SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1
alert internal error (_ssl.c:2635)')}
)` .
All-in-all, I believe we don't need to further suspect TLS at this point?
Please let me know otherwise, I can debug further.
was (Author: maulin.vasavada):
Yes I am with you guys [~brandon.williams] and [~e.dimitrova] . I meant
versions prior to TLSv1.2 are disabled in Jdk 17. Hence my initial guess was -
what TLS protocol it uses when we trigger the run_cqlsh() from the python test.
If that was passing/using older version of the TLS than v1.2 it could fail.
Basically, if my understanding is right, the test is running cqlsh to describe
namespace and uses ssl options specifying the certificate so I assume it
connects to the node started by the test via ssl.
However based on Ekaterina's findings it seems the Netty upgrade may be the
cause of the underlying failure. My initial research was just based on the test
run logs I could see `assert "Connection e...c:2635)')})\n" == '' - Connection
error: ('Unable to connect to any servers', {'127.0.0.1:9042':
ConnectionShutdown('[SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal
error (_ssl.c:2635)')})` .
All-in-all, I believe we don't need to further suspect TLS at this point?
Please let me know otherwise, I can debug further.
> Support Java 17
> ---
>
> Key: CASSANDRA-16895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16895
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> 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
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16895) Support Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508959#comment-17508959
]
Maulin Vasavada edited comment on CASSANDRA-16895 at 3/18/22, 5:11 PM:
---
Yes I am with you guys [~brandon.williams] and [~e.dimitrova] . I meant
versions prior to TLSv1.2 are disabled in Jdk 17. Hence my initial guess was -
what TLS protocol it uses when we trigger the run_cqlsh() from the python test.
If that was passing/using older version of the TLS than v1.2 it could fail.
Basically, if my understanding is right, the test is running cqlsh to describe
namespace and uses ssl options specifying the certificate so I assume it
connects to the node started by the test via ssl.
However based on Ekaterina's findings it seems the Netty upgrade may be the
cause of the underlying failure. My initial research was just based on the test
run logs I could see `assert "Connection e...c:2635)')})\n" == '' - Connection
error: ('Unable to connect to any servers', {'127.0.0.1:9042':
ConnectionShutdown('[SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal
error (_ssl.c:2635)')})` .
All-in-all, I believe we don't need to further suspect TLS at this point?
Please let me know otherwise, I can debug further.
was (Author: maulin.vasavada):
Yes I am with you guys [~brandon.williams] and [~e.dimitrova] . I meant
versions prior to TLSv1.2 are disabled in Jdk 17. Hence my initial guess was -
what TLS protocol it uses when we trigger the run_cqlsh() from the python test.
If that was passing/using older version of the TLS than v1.2 it could fail.
However based on Ekaterina's findings it seems the Netty upgrade may be the
cause of the underlying failure. My initial research was just based on the test
run logs I could see `assert "Connection e...c:2635)')})\n" == '' - Connection
error: ('Unable to connect to any servers', \{'127.0.0.1:9042':
ConnectionShutdown('[SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal
error (_ssl.c:2635)')})` .
All-in-all, I believe we don't need to further suspect TLS at this point?
Please let me know otherwise, I can debug further.
> Support Java 17
> ---
>
> Key: CASSANDRA-16895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16895
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> 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
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16895) Support Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508959#comment-17508959
]
Maulin Vasavada commented on CASSANDRA-16895:
-
Yes I am with you guys [~brandon.williams] and [~e.dimitrova] . I meant
versions prior to TLSv1.2 are disabled in Jdk 17. Hence my initial guess was -
what TLS protocol it uses when we trigger the run_cqlsh() from the python test.
If that was passing/using older version of the TLS than v1.2 it could fail.
However based on Ekaterina's findings it seems the Netty upgrade may be the
cause of the underlying failure. My initial research was just based on the test
run logs I could see `assert "Connection e...c:2635)')})\n" == '' - Connection
error: ('Unable to connect to any servers', \{'127.0.0.1:9042':
ConnectionShutdown('[SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal
error (_ssl.c:2635)')})` .
All-in-all, I believe we don't need to further suspect TLS at this point?
Please let me know otherwise, I can debug further.
> Support Java 17
> ---
>
> Key: CASSANDRA-16895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16895
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> 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
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17419) Prevent GH pull request commits to cassandra repository
[
https://issues.apache.org/jira/browse/CASSANDRA-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508956#comment-17508956
]
Benjamin Lerer commented on CASSANDRA-17419:
+1
> Prevent GH pull request commits to cassandra repository
> ---
>
> Key: CASSANDRA-17419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17419
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: Screenshot 2022-03-07 at 17.45.22.png
>
>
> The cassandra project (currently) does not permit commits to be pushed to the
> cassandra repository (trunk or any branch) via GH pull requests. It is easy
> to disable this with a {{.asf.yml}} file.
> Note, our other repositories: cassandra-dtest, cassandra-builds,
> cassandra-website, cassandra-in-jvm-dtest-api, …; may be candidates for
> allowing {{rebased}} GH PR merges.
> The cassandra-website repository is already set up to permit these, see
> [here|https://github.com/apache/cassandra-website/blob/trunk/.asf.yaml#L6-L10].
> So long as part of the PR review process tis checking the commit message is
> of the correct project format it works well (there are no forward merges
> across projects in this repository).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7662) Implement templated CREATE TABLE functionality (CREATE TABLE LIKE)
[ https://issues.apache.org/jira/browse/CASSANDRA-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-7662: -- Reviewers: (was: Benjamin Lerer) > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) > -- > > Key: CASSANDRA-7662 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7662 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/CQL >Reporter: Aleksey Yeschenko >Priority: Low > Labels: AdventCalendar2021, lhf > Fix For: 4.x > > Attachments: 7662.patch, CASSANDRA-7662.patch > > > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) to > simplify creating new tables duplicating existing ones (see parent_table part > of http://www.postgresql.org/docs/9.1/static/sql-createtable.html). > CREATE TABLE LIKE ; - would create a new table with > the same columns and options as > +Additional info for newcomers:+ > In order to implement this change you will need to change the Parser.g ANTLR > file located in the src/antlr directory and the java classes corresponding to > the CREATE statement located in the > org.apache.cassandra.cql3.statements.schema package. > The unit test for the CQL logic are located under > org.apache.cassandra.cql3.validation > cqlsh parsing will need to be modified to support the new LIKE syntax. The > logic is in pylib/cqlshlib/cql3handling.py and the test in > pylib/cqlshlib/test/test_cqlsh_completion.py -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16787) Copy from csv file with duration type fields fails to import
[
https://issues.apache.org/jira/browse/CASSANDRA-16787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-16787:
--
Assignee: (was: Benjamin Lerer)
> Copy from csv file with duration type fields fails to import
>
>
> Key: CASSANDRA-16787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16787
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Brijesh Dungarakoti
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: error_cassandra_copy_from_1.JPG,
> error_cassandra_copy_from_2.JPG
>
>
> Getting error:
> {code:java}
> cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv'
> WITH HEADER = FALSE AND NULL='null';
> Using 3 child processes
> Starting copy of users.user_credentials_by_email with columns [email,
> la_duration].
> Failed to make batch statement: Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.)_
> Failed to import 1 rows: TypeError - Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.), given up
> without retries
> Failed to process 1 rows; failed rows written to
> import_users_user_credentials_by_email.err
> Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s
> 0 rows imported from 1 files in 0.431 seconds (0 skipped).
> {code}
> *To Reproduce:*
> {code:java}
> CREATE KEYSPACE users WITH replication = {'class': 'NetworkTopologyStrategy',
> 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (
> email text,
> la_duration duration,
> PRIMARY KEY(email)
> );
> {code}
> create users.csv file with:
> {code:java}
> l...@la.com,8m26s482ms
> {code}
> Run:
> {code:java}
> COPY users.user_credentials_by_email FROM '/home/automaton/users.csv' WITH
> HEADER = FALSE AND NULL='null';
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17448) allow users to change cqlsh history location using env variable
[ https://issues.apache.org/jira/browse/CASSANDRA-17448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508902#comment-17508902 ] Brandon Williams commented on CASSANDRA-17448: -- I think there are too many ways to do things here, leading to the override. Instead, if we're going to respect the CQL_HISTORY env variable let's just use that, and if set to empty consider that as the signal to not store history. > allow users to change cqlsh history location using env variable > --- > > Key: CASSANDRA-17448 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17448 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > > User on GH sent: > I just started using cassandra and found that it creates history folder in my > home directory. I personally don't like it and all my folders follow XDG > standard. I found stackoverflow question related to it which says that it's > not possible to do without configuring source code of cqlsh.py. > In this pull request I added a feature to choose history directory using > environment variable. The name of variable is CQL_HISTORY. Why ? Because > postgres and node-repl use approximately the same convention > (NODE_REPL_HISTORY,PSQL_HISTORY). If you want I can change the name. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17392) Upgrade to netty 4.1.73.Final
[ https://issues.apache.org/jira/browse/CASSANDRA-17392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508896#comment-17508896 ] Brandon Williams commented on CASSANDRA-17392: -- Let's hold off on this since there's no pressing need for it and we now know it complicates CASSANDRA-16895 with java 17. > Upgrade to netty 4.1.73.Final > - > > Key: CASSANDRA-17392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17392 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > The current netty version has CVEs as shown in CASSANDRA-17368. There we > suppressed the CVEs for other versions, but for trunk let's investigate > upgrading. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16895) Support Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508893#comment-17508893 ] Ekaterina Dimitrova commented on CASSANDRA-16895: - Seems like now we have only 2-3(which are new) python dtests failing when we eliminate the Netty upgrade from the picture. > Support Java 17 > --- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > 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 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17210) Not able to override default transport port in cassandra 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-17210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508868#comment-17508868 ] Brandon Williams commented on CASSANDRA-17210: -- +1. It's a little sad that LoaderOptionsTest couldn't catch this. > Not able to override default transport port in cassandra 4.0 > > > Key: CASSANDRA-17210 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17210 > Project: Cassandra > Issue Type: Bug > Components: Tool/bulk load >Reporter: NISHANT GUPTA >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1, 4.0.4 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Bulk Loader is not honouring "-p" option given on the command line of the > sstableloader. > The command line used is: > ~/apache-cassandra-4.0.1/bin/sstableloader -d 10.14.20.148 -cph 1 -idct 0 -p > 9942 -ssp 7011 -sp 7010 --verbose ~/cassandra4_experiment/nishant/employee/ > > but the call is still going to /10.14.20.148:9042. We are just passing the > host information to the Cluster.Builder in NativeSSTableLoaderClient.java: > Cluster.Builder builder = > Cluster.builder().addContactPointsWithPorts(hosts).allowBetaProtocolVersion(); > Looks like default port is getting picked inside > com.datastax.driver.core.cluster. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16895) Support Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508863#comment-17508863
]
Ekaterina Dimitrova commented on CASSANDRA-16895:
-
Hey [~maulin.vasavada], thank you for looking into this. Unfortunately
[~brandon.williams] is right and what you mentioned is not the problem. If you
go to the link I
[shared|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1478/workflows/0c8a2139-c59d-4169-be7a-4f83f71524f5/jobs/9622/tests#failed-test-0]
and then under Artifacts section you search for test_tls, in this debug log
[dtest_j17_without_vnodes_logs/1647572865225_test_tls/node1_debug.log|https://9622-218559411-gh.circle-artifacts.com/23/dtest_j17_without_vnodes_logs/1647572865225_test_tls/node1_debug.log].
We see this in the stack trace
{code:java}
java.lang.ClassCastException: class
org.apache.cassandra.utils.memory.BufferPool$Chunk cannot be cast to class
sun.nio.ch.DirectBuffer{code}
Meanwhile, I managed to make at least these 2 tests pass if I do not update
Netty to latest version... which I did after I saw a ticket for doing it on
trunk which worked fine with Java 8/11. :( I am rerunning again the whole suite
with the old Netty version to see what happens then as I suspect this will fix
a lot of tests. I am not saying we should keep old versions around but at least
this finding gives a direction a bit
> Support Java 17
> ---
>
> Key: CASSANDRA-16895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16895
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> 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
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17197) Diagnostic events for guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-17197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508827#comment-17508827 ] Andres de la Peña commented on CASSANDRA-17197: --- It seems some of the new tests are flaky, I'm trying to figure out what's going on. > Diagnostic events for guardrails > > > Key: CASSANDRA-17197 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17197 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Add diagnostic events for guardrails, so we can monitor when each type of > guardrail is triggered. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15297: --- Fix Version/s: 4.1 4.0.4 (was: 4.x) Since Version: 3.0.0 Source Control Link: https://github.com/apache/cassandra/commit/e773bbd9c6c52a2fedc127cb7ab77a1fdbeb63d2 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed in 4.0 at e773bbd9c6c52a2fedc127cb7ab77a1fdbeb63d2 and merged into trunk > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: Saranya Krishnakumar >Priority: Normal > Labels: pull-request-available > Fix For: 4.1, 4.0.4 > > Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 0.5h > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508799#comment-17508799 ] Benjamin Lerer commented on CASSANDRA-15297: Thanks [~maxwellguo], [~saranya_k] and [~frankgh] for the patch. > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: Saranya Krishnakumar >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 0.5h > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (f3123a6 -> e773bbd)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from f3123a6 remove futures module requirement from pylib add e773bbd Reject snapshot names with special character No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../apache/cassandra/tools/nodetool/Snapshot.java | 5 + .../cassandra/tools/nodetool/SnapshotTest.java | 152 + 3 files changed, 158 insertions(+) create mode 100644 test/unit/org/apache/cassandra/tools/nodetool/SnapshotTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (96cecdb -> 34a7eba)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 96cecdb Increase cqlsh version to 6.1.0 add e773bbd Reject snapshot names with special character new 34a7eba Merge branch cassandra-4.0 into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../apache/cassandra/tools/nodetool/Snapshot.java | 19 ++- .../cassandra/tools/nodetool/SnapshotTest.java | 169 + 3 files changed, 182 insertions(+), 7 deletions(-) create mode 100644 test/unit/org/apache/cassandra/tools/nodetool/SnapshotTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch cassandra-4.0 into trunk
This is an automated email from the ASF dual-hosted git repository. blerer pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 34a7eba4b8d1813ad782fe2432cdfd85fa24e6c1 Merge: 96cecdb e773bbd Author: Benjamin Lerer AuthorDate: Fri Mar 18 15:03:38 2022 +0100 Merge branch cassandra-4.0 into trunk CHANGES.txt| 1 + .../apache/cassandra/tools/nodetool/Snapshot.java | 19 ++- .../cassandra/tools/nodetool/SnapshotTest.java | 169 + 3 files changed, 182 insertions(+), 7 deletions(-) diff --cc CHANGES.txt index e2575ff,5c0477b..22f4759 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,113 -1,5 +1,114 @@@ -4.0.4 +4.1 + * Increase cqlsh version (CASSANDRA-17432) + * Update SUPPORTED_UPGRADE_PATHS to include 3.0 and 3.x to 4.1 paths and remove obsolete tests (CASSANDRA-17362) + * Support DELETE in CQLSSTableWriter (CASSANDRA-14797) + * Failed inbound internode authentication failures generate ugly warning with stack trace (CASSANDRA-17068) + * Expose gossip information in system_views.gossip_info virtual table (CASSANDRA-17002) + * Add guardrails for collection items and size (CASSANDRA-17153) + * Improve guardrails messages (CASSANDRA-17430) + * Remove all usages of junit.framework and ban them via Checkstyle (CASSANDRA-17316) + * Add guardrails for read/write consistency levels (CASSANDRA-17188) + * Add guardrail for SELECT IN terms and their cartesian product (CASSANDRA-17187) + * remove unused imports in cqlsh.py and cqlshlib (CASSANDRA-17413) + * deprecate property windows_timer_interval (CASSANDRA-17404) + * Expose streaming as a vtable (CASSANDRA-17390) + * Expose all client options via system_views.clients and nodetool clientstats (CASSANDRA-16378) + * Make startup checks configurable (CASSANDRA-17220) + * Add guardrail for number of partition keys on IN queries (CASSANDRA-17186) + * update Python test framework from nose to pytest (CASSANDRA-17293) + * Fix improper CDC commit log segments deletion in non-blocking mode (CASSANDRA-17233) + * Add support for string concatenations through the + operator (CASSANDRA-17190) + * Limit the maximum hints size per host (CASSANDRA-17142) + * Add a virtual table for exposing batch metrics (CASSANDRA-17225) + * Flatten guardrails config (CASSANDRA-17353) + * Instance failed to start up due to NPE in StartupClusterConnectivityChecker (CASSANDRA-17347) + * add the shorter version of version flag (-v) in cqlsh (CASSANDRA-17236) + * Make vtables accessible via internode messaging (CASSANDRA-17295) + * Add support for PEM based key material for SSL (CASSANDRA-17031) + * Standardize storage configuration parameters' names. Support unit suffixes. (CASSANDRA-15234) + * Remove support for Windows (CASSANDRA-16956) + * Runtime-configurable YAML option to prohibit USE statements (CASSANDRA-17318) + * When streaming sees a ClosedChannelException this triggers the disk failure policy (CASSANDRA-17116) + * Add a virtual table for exposing prepared statements metrics (CASSANDRA-17224) + * Remove python 2.x support from cqlsh (CASSANDRA-17242) + * Prewarm role and credential caches to avoid timeouts at startup (CASSANDRA-16958) + * Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool (CASSANDRA-17063) + * Added startup check for read_ahead_kb setting (CASSANDRA-16436) + * Avoid unecessary array allocations and initializations when performing query checks (CASSANDRA-17209) + * Add guardrail for list operations that require read before write (CASSANDRA-17154) + * Migrate thresholds for number of keyspaces and tables to guardrails (CASSANDRA-17195) + * Remove self-reference in SSTableTidier (CASSANDRA-17205) + * Add guardrail for query page size (CASSANDRA-17189) + * Allow column_index_size_in_kb to be configurable through nodetool (CASSANDRA-17121) + * Emit a metric for number of local read and write calls + * Add non-blocking mode for CDC writes (CASSANDRA-17001) + * Add guardrails framework (CASSANDRA-17147) + * Harden resource management on SSTable components to prevent future leaks (CASSANDRA-17174) + * Make nodes more resilient to local unrelated files during startup (CASSANDRA-17082) + * repair prepare message would produce a wrong error message if network timeout happened rather than reply wait timeout (CASSANDRA-16992) + * Log queries that fail on timeout or unavailable errors up to once per minute by default (CASSANDRA-17159) + * Refactor normal/preview/IR repair to standardize repair cleanup and error handling of failed RepairJobs (CASSANDRA-17069) + * Log missing peers in StartupClusterConnectivityChecker (CASSANDRA-17130) + * Introduce separate rate limiting settings for entire SSTable streaming (CASSANDRA-17065) + * Implement Virtual Tables for Auth Caches (CASSANDRA-16914) + * Actively update auth cache in the background
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15297: --- Status: Ready to Commit (was: Review In Progress) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: Saranya Krishnakumar >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 0.5h > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508797#comment-17508797 ] Benjamin Lerer commented on CASSANDRA-15297: || Branches || CI || |[4.0|https://github.com/frankgh/cassandra/commit/2e90cd45505d139ee2310069d845f6e4091f235f] | [j8|https://app.circleci.com/pipelines/github/frankgh/cassandra?branch=CASSANDRA-15297-trunk=all] | |[trunk|https://github.com/frankgh/cassandra/commit/23c9550eac057eeab1e7e6b02c73ccd845618681] | [j8|https://app.circleci.com/pipelines/github/frankgh/cassandra?branch=CASSANDRA-15297-trunk=all] | > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: Saranya Krishnakumar >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 0.5h > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17425) Add new CQL function maxWritetime
[
https://issues.apache.org/jira/browse/CASSANDRA-17425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508787#comment-17508787
]
Andres de la Peña commented on CASSANDRA-17425:
---
Agree, that patch was able to do things like:
{code:java}
CREATE TABLE IF NOT EXISTS t (k int PRIMARY KEY, s set);
INSERT INTO t (k, s) VALUES (1, {1, 2}) USING TIMESTAMP 100 AND TTL 1;
UPDATE t USING TIMESTAMP 200 AND TTL 2 SET s += {3} WHERE k=1;
SELECT s[2..], WRITETIME(s[2..]), TTL(s[2..]) FROM t;
s[2..] | writetime(s[2..]) | ttl(s[2..])
+---+
{2, 3} |[100, 200] | [1, 2]
{code}
I also think that doing MaxWritetime on top of CASSANDRA-8877 would be the
easier and most flexible approach.
> Add new CQL function maxWritetime
> -
>
> Key: CASSANDRA-17425
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17425
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> The function "writetime" does not support multi-cell types, e.g. collections
> and UDT. It would be useful to enable querying the latest modified timestamp
> of a column value.
> I'd like to propose to add a new function named "maxWritetime", which returns
> the largest timestamp amongst the cells. When being applied to the single
> cell types, it returns the same result as "writetime".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17152) Guardrail for partition size
[
https://issues.apache.org/jira/browse/CASSANDRA-17152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17152:
--
Resolution: Duplicate
Status: Resolved (was: Triage Needed)
> Guardrail for partition size
>
>
> Key: CASSANDRA-17152
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17152
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add a guardrail for large partitions. Finding the size of a partition is
> tricky because partitions can be spread over multiple sstable and we want to
> avoid read before write. Thus, this might be just a warning thrown during
> compaction and not be linked to specific user queries, for example:
> {code}
> # Log a warning when compacting partitions larger than this value.
> # Defaults to -1 to disable
> # partition_size_warn_threshold_in_mb: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17152) Guardrail for partition size
[
https://issues.apache.org/jira/browse/CASSANDRA-17152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508780#comment-17508780
]
Andres de la Peña commented on CASSANDRA-17152:
---
Closing this as duplicate of CASSANDRA-17194, where it's proposed to migrate
the current {{compacted_partition_size_warn_threshold_mb}} to guardrails.
> Guardrail for partition size
>
>
> Key: CASSANDRA-17152
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17152
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add a guardrail for large partitions. Finding the size of a partition is
> tricky because partitions can be spread over multiple sstable and we want to
> avoid read before write. Thus, this might be just a warning thrown during
> compaction and not be linked to specific user queries, for example:
> {code}
> # Log a warning when compacting partitions larger than this value.
> # Defaults to -1 to disable
> # partition_size_warn_threshold_in_mb: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17425) Add new CQL function maxWritetime
[
https://issues.apache.org/jira/browse/CASSANDRA-17425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508758#comment-17508758
]
Benjamin Lerer edited comment on CASSANDRA-17425 at 3/18/22, 12:52 PM:
---
{quote}I do not have objections on extending 'writetime' and 'tty' functions to
support multi-cell types, although I do doubt how practical it is to return the
timestamps/TTLs of the entire collection. {quote}
It is a feature that I have seen requested quite often.
{quote}Do you have an ETA on when your patch will land?{quote}
Today or Monday
I had a quick look at the patch that we made for CASSANDRA-8877. It made me
realized that even for {{maxWritetime}} the situation is may be more
complicated than it looks at first glance. We apparently have ignored for
{{writetime}} and {{ttl}} the fact that selectors can be chained and used to
reduce the selection.
For example:
{code}
SELECT writetime(myMap['second'..'third']), ttl(myUdt.myFirstField) FROM myTable
{code}
The same problem will apply to {{maxTimestamp}} if I am not mistaken.
I feel that we should undust our patch has it adressed those problems. Adding
MaxWritetime on top of it should be relatively straight forward in my opinion.
was (Author: blerer):
{quote}I do not have objections on extending 'writetime' and 'tty' functions to
support multi-cell types, although I do doubt how practical it is to return the
timestamps/TTLs of the entire collection. {quote}
It is a feature that I have seen requested quite often.
{quote}Do you have an ETA on when your patch will land?{quote}
Today or Monday
I had a quick look at the patch that we made for CASSANDRA-8877. It made me
realized that even for {{maxWritetime}} the situation is may be more
complicated than it looks at first glance. We apparently have ignored for
{{writetime}} and {{ttl}} the fact that selectors can be chained and used to
reduce the selection.
For example:
{code}
SELECT writetime(myMap['second'..'third']), ttl(myUdt.myFirstField) FROM myTable
{code}
The same problem will apply to {{maxTimestamp}} if I am not mistaken.
> Add new CQL function maxWritetime
> -
>
> Key: CASSANDRA-17425
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17425
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> The function "writetime" does not support multi-cell types, e.g. collections
> and UDT. It would be useful to enable querying the latest modified timestamp
> of a column value.
> I'd like to propose to add a new function named "maxWritetime", which returns
> the largest timestamp amongst the cells. When being applied to the single
> cell types, it returns the same result as "writetime".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17425) Add new CQL function maxWritetime
[
https://issues.apache.org/jira/browse/CASSANDRA-17425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508758#comment-17508758
]
Benjamin Lerer edited comment on CASSANDRA-17425 at 3/18/22, 12:52 PM:
---
{quote}I do not have objections on extending 'writetime' and 'tty' functions to
support multi-cell types, although I do doubt how practical it is to return the
timestamps/TTLs of the entire collection. {quote}
It is a feature that I have seen requested quite often.
{quote}Do you have an ETA on when your patch will land?{quote}
Today or Monday
I had a quick look at the patch that we made for CASSANDRA-8877. It made me
realized that even for {{maxWritetime}} the situation is may be more
complicated than it looks at first glance. We apparently have ignored for
{{writetime}} and {{ttl}} the fact that selectors can be chained and used to
reduce the selection.
For example:
{code}
SELECT writetime(myMap['second'..'third']), ttl(myUdt.myFirstField) FROM myTable
{code}
The same problem will apply to {{maxTimestamp}} if I am not mistaken.
I feel that we should undust our patch has it adressed those problems. Adding
MaxWritetime on top of it should be relatively straight forward in my opinion.
What do you think?
was (Author: blerer):
{quote}I do not have objections on extending 'writetime' and 'tty' functions to
support multi-cell types, although I do doubt how practical it is to return the
timestamps/TTLs of the entire collection. {quote}
It is a feature that I have seen requested quite often.
{quote}Do you have an ETA on when your patch will land?{quote}
Today or Monday
I had a quick look at the patch that we made for CASSANDRA-8877. It made me
realized that even for {{maxWritetime}} the situation is may be more
complicated than it looks at first glance. We apparently have ignored for
{{writetime}} and {{ttl}} the fact that selectors can be chained and used to
reduce the selection.
For example:
{code}
SELECT writetime(myMap['second'..'third']), ttl(myUdt.myFirstField) FROM myTable
{code}
The same problem will apply to {{maxTimestamp}} if I am not mistaken.
I feel that we should undust our patch has it adressed those problems. Adding
MaxWritetime on top of it should be relatively straight forward in my opinion.
> Add new CQL function maxWritetime
> -
>
> Key: CASSANDRA-17425
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17425
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> The function "writetime" does not support multi-cell types, e.g. collections
> and UDT. It would be useful to enable querying the latest modified timestamp
> of a column value.
> I'd like to propose to add a new function named "maxWritetime", which returns
> the largest timestamp amongst the cells. When being applied to the single
> cell types, it returns the same result as "writetime".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17425) Add new CQL function maxWritetime
[
https://issues.apache.org/jira/browse/CASSANDRA-17425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508758#comment-17508758
]
Benjamin Lerer commented on CASSANDRA-17425:
{quote}I do not have objections on extending 'writetime' and 'tty' functions to
support multi-cell types, although I do doubt how practical it is to return the
timestamps/TTLs of the entire collection. {quote}
It is a feature that I have seen requested quite often.
{quote}Do you have an ETA on when your patch will land?{quote}
Today or Monday
I had a quick look at the patch that we made for CASSANDRA-8877. It made me
realized that even for {{maxWritetime}} the situation is may be more
complicated than it looks at first glance. We apparently have ignored for
{{writetime}} and {{ttl}} the fact that selectors can be chained and used to
reduce the selection.
For example:
{code}
SELECT writetime(myMap['second'..'third']), ttl(myUdt.myFirstField) FROM myTable
{code}
The same problem will apply to {{maxTimestamp}} if I am not mistaken.
> Add new CQL function maxWritetime
> -
>
> Key: CASSANDRA-17425
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17425
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> The function "writetime" does not support multi-cell types, e.g. collections
> and UDT. It would be useful to enable querying the latest modified timestamp
> of a column value.
> I'd like to propose to add a new function named "maxWritetime", which returns
> the largest timestamp amongst the cells. When being applied to the single
> cell types, it returns the same result as "writetime".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17217) LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-17217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508753#comment-17508753
]
Andres de la Peña commented on CASSANDRA-17217:
---
[~bernardo.botella] thanks for looking into this. Unfortunately, it seems that
[this repeated
run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1373/workflows/c64980f8-4f6a-439c-ac20-3f376e341f2c/jobs/13945]
of {{LocalReadSizeWarningTest}} with 500 iterations still hits the same
failure twice.
> LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
> --
>
> Key: CASSANDRA-17217
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17217
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Fix For: 4.x
>
>
> The test
> {{org.apache.cassandra.distributed.test.trackwarnings.LocalReadSizeWarningTest#failThresholdSinglePartition}}
> seems to be flaky.
> It was discovered during CASSANDRA-17195 with [this CI
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1217/workflows/b366e352-0862-485a-acdc-5b75fe1ef575/jobs/11188].
> The failure can be reproduced running the test repeatedly for trunk, as it
> can be seen
> [here|https://app.circleci.com/pipelines/github/adelapena/cassandra/1219/workflows/a0c1fb7f-8a07-4fcf-97a4-7caf207dad78].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17197) Diagnostic events for guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-17197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508741#comment-17508741 ] Andres de la Peña commented on CASSANDRA-17197: --- Thanks for the review. I have added your suggestion and I'm running CI again, let's see if we have better luck with the workers: ||PR||CI|| |[trunk|https://github.com/apache/cassandra/pull/1485]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1375/workflows/5133718b-8143-4382-87df-ea2b1c3e7df4] [j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1375/workflows/a7bfde6d-4e03-428b-9886-3671213c0f1c]| > Diagnostic events for guardrails > > > Key: CASSANDRA-17197 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17197 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Add diagnostic events for guardrails, so we can monitor when each type of > guardrail is triggered. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508714#comment-17508714
]
Maciej Sokol edited comment on CASSANDRA-15458 at 3/18/22, 11:57 AM:
-
While looking at the python tests i found why there's a difference. See:
CASSANDRA-6172
I've tested unquoting both maps and other collections and ran some tests
locally with ccm. The error mentioned in the ticket above is not reproducible
(atleast not with what was stated in the ticket).
Also noticed that some of the types in a UDTs are quoted but not all, which
feels strange as well.
It's a pretty drastic change but if we want to be consistent we should keep
everything unquoted (since everything is unquoted by default except when the
values are in a collection, or if values are in UDT).
What do you think Benjamin?
was (Author: JIRAUSER285315):
While looking at the python tests i found why there's a difference. See:
CASSANDRA-6172
I've tested unquoting both maps and other collections and ran some tests
locally with ccm. The error mentioned in the ticket above is not reproducible
(atleast not with what was stated in the ticket). Also noticed that UDTs are
quoted, which feels strange as well.
What do you think Benjamin? It's a pretty drastic change but if we want to be
consistent we should keep everything unquoted (since everything is unquoted by
default except when the values are in a collection).
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Maciej Sokol
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17432) Update cqlsh version in 4.1
[ https://issues.apache.org/jira/browse/CASSANDRA-17432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17432: - Fix Version/s: 4.1 (was: 4.x) Source Control Link: https://github.com/apache/cassandra/commit/96cecdbaa685b86bd2ac1d10545f9b9a39bbfdea Resolution: Fixed Status: Resolved (was: Ready to Commit) I'm relatively certain nothing actually uses this version so I think we're safe. Committed, thanks! > Update cqlsh version in 4.1 > --- > > Key: CASSANDRA-17432 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17432 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.1 > > Time Spent: 40m > Remaining Estimate: 0h > > The cqlsh in version 4.1 has had several important internal changes to > credentials management and removing compatibility with Python2. Therefore > the version should be incremented; e.g from 6.0.0 to 6.1.0 or similar. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17432) Update cqlsh version in 4.1
[ https://issues.apache.org/jira/browse/CASSANDRA-17432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17432: - Status: Ready to Commit (was: Review In Progress) > Update cqlsh version in 4.1 > --- > > Key: CASSANDRA-17432 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17432 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > The cqlsh in version 4.1 has had several important internal changes to > credentials management and removing compatibility with Python2. Therefore > the version should be incremented; e.g from 6.0.0 to 6.1.0 or similar. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Increase cqlsh version to 6.1.0
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 96cecdb Increase cqlsh version to 6.1.0
96cecdb is described below
commit 96cecdbaa685b86bd2ac1d10545f9b9a39bbfdea
Author: Brad Schoening <5796692+bschoen...@users.noreply.github.com>
AuthorDate: Wed Mar 16 14:45:05 2022 -0400
Increase cqlsh version to 6.1.0
Patch by Brad Schoening; reviewed by bereng and brandonwilliams for
CASSANDRA-17432
---
CHANGES.txt | 1 +
README.asc | 2 +-
bin/cqlsh.py | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 09f352c..e2575ff 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Increase cqlsh version (CASSANDRA-17432)
* Update SUPPORTED_UPGRADE_PATHS to include 3.0 and 3.x to 4.1 paths and
remove obsolete tests (CASSANDRA-17362)
* Support DELETE in CQLSSTableWriter (CASSANDRA-14797)
* Failed inbound internode authentication failures generate ugly warning with
stack trace (CASSANDRA-17068)
diff --git a/README.asc b/README.asc
index 27850cd..3c40bf4 100644
--- a/README.asc
+++ b/README.asc
@@ -39,7 +39,7 @@ be sitting in front of a prompt:
Connected to Test Cluster at localhost:9160.
-[cqlsh 2.2.0 | Cassandra 1.2.0 | CQL spec 3.0.0 | Thrift protocol 19.35.0]
+[cqlsh 6.0.0 | Cassandra 4.0.2 | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
cqlsh>
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index a75c25e..d292c17 100755
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -45,7 +45,7 @@ if platform.python_implementation().startswith('Jython'):
UTF8 = 'utf-8'
description = "CQL Shell for Apache Cassandra"
-version = "6.0.0"
+version = "6.1.0"
readline = None
try:
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17432) Update cqlsh version in 4.1
[ https://issues.apache.org/jira/browse/CASSANDRA-17432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508733#comment-17508733 ] Berenguer Blasi commented on CASSANDRA-17432: - I think failures match those of the latest trunk. But at 30-ish it is starting to be difficult to track. LGTM +1 > Update cqlsh version in 4.1 > --- > > Key: CASSANDRA-17432 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17432 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > The cqlsh in version 4.1 has had several important internal changes to > credentials management and removing compatibility with Python2. Therefore > the version should be incremented; e.g from 6.0.0 to 6.1.0 or similar. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17452) Adding TLS version in conf/cqlshrc.sample
[ https://issues.apache.org/jira/browse/CASSANDRA-17452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508727#comment-17508727 ] Brandon Williams edited comment on CASSANDRA-17452 at 3/18/22, 11:22 AM: - I'm relatively certain this isn't needed as we have tests for cqlsh and SSL/TLS that don't have this set and pass. was (Author: brandon.williams): I'm relatively certain this isn't needed as we have test for cqlsh and SSL/TLS that don't have this set and pass. > Adding TLS version in conf/cqlshrc.sample > -- > > Key: CASSANDRA-17452 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17452 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Hemang Ajmera >Priority: Low > > Created a Jira ticket to track [https://github.com/apache/cassandra/pull/974] > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17452) Adding TLS version in conf/cqlshrc.sample
[ https://issues.apache.org/jira/browse/CASSANDRA-17452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508727#comment-17508727 ] Brandon Williams commented on CASSANDRA-17452: -- I'm relatively certain this isn't needed as we have test for cqlsh and SSL/TLS that don't have this set and pass. > Adding TLS version in conf/cqlshrc.sample > -- > > Key: CASSANDRA-17452 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17452 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Hemang Ajmera >Priority: Low > > Created a Jira ticket to track [https://github.com/apache/cassandra/pull/974] > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17450) Increment python support to 3.7+
[ https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17450: - Change Category: Operability Complexity: Normal Component/s: CQL/Interpreter Fix Version/s: 4.x Status: Open (was: Triage Needed) > Increment python support to 3.7+ > > > Key: CASSANDRA-17450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17450 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 3.6 became EOL as of 12/23/21. There will be no further releases or > security fixes for Python 3.6. > https://github.com/httpie/httpie/issues/1177 > https://devguide.python.org/#status-of-python-branches -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16895) Support Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508726#comment-17508726 ] Brandon Williams commented on CASSANDRA-16895: -- We [specifically test|https://github.com/apache/cassandra-dtest/blob/trunk/cqlsh_tests/test_cqlsh.py#L184] for TLS 1.2. > Support Java 17 > --- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > 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 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17454) flaky dtest-upgrade.upgrade_tests.cql_tests TestCQLNodes2RF1_Upgrade_indev_4_0_x_To_indev_trunk test_static_cf
[ https://issues.apache.org/jira/browse/CASSANDRA-17454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17454: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Discovered By: DTest Severity: Normal Status: Open (was: Triage Needed) > flaky dtest-upgrade.upgrade_tests.cql_tests > TestCQLNodes2RF1_Upgrade_indev_4_0_x_To_indev_trunk test_static_cf > -- > > Key: CASSANDRA-17454 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17454 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Stefan Miklosovic >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17454) flaky dtest-upgrade.upgrade_tests.cql_tests TestCQLNodes2RF1_Upgrade_indev_4_0_x_To_indev_trunk test_static_cf
[
https://issues.apache.org/jira/browse/CASSANDRA-17454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17454:
--
Description:
{code:java}
Error Messagecassandra.WriteFailure: Error from server: code=1500 [Replica(s)
failed to execute write] message="Operation failed - received 1 responses and 1
failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
'required_responses': 1, 'received_responses': 1, 'failures': 1,
'error_code_map': {'127.0.0.1': '0x'}}Stacktraceself =
def test_static_cf(self):
""" Test static CF syntax """
cursor = self.prepare()
# Create
cursor.execute("""
CREATE TABLE users (
userid uuid PRIMARY KEY,
firstname text,
lastname text,
age int
);
""")
for is_upgraded, cursor in self.do_upgrade(cursor):
logger.debug("Querying {} node".format("upgraded" if is_upgraded
else "old"))
cursor.execute("TRUNCATE users")
# Inserts
cursor.execute("INSERT INTO users (userid, firstname, lastname,
age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
cursor.execute("UPDATE users SET firstname = 'Samwise', lastname =
'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
# Queries
assert_one(cursor, "SELECT firstname, lastname FROM users WHERE
userid = 550e8400-e29b-41d4-a716-44665544", ['Frodo', 'Baggins'])
assert_one(cursor, "SELECT * FROM users WHERE userid =
550e8400-e29b-41d4-a716-44665544",
[UUID('550e8400-e29b-41d4-a716-44665544'), 32, 'Frodo', 'Baggins'])
assert_all(cursor, "SELECT * FROM users",
[[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33, 'Samwise', 'Gamgee'],
[UUID('550e8400-e29b-41d4-a716-44665544'), 32, 'Frodo', 'Baggins']])
# Test batch inserts
> cursor.execute("""
BEGIN BATCH
INSERT INTO users (userid, age) VALUES
(550e8400-e29b-41d4-a716-44665544, 36)
UPDATE users SET age = 37 WHERE userid =
f47ac10b-58cc-4372-a567-0e02b2c3d479
DELETE firstname, lastname FROM users WHERE userid =
550e8400-e29b-41d4-a716-44665544
DELETE firstname, lastname FROM users WHERE userid =
f47ac10b-58cc-4372-a567-0e02b2c3d479
APPLY BATCH
""")
upgrade_tests/cql_tests.py:74:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
return self.execute_async(query, parameters, trace, custom_payload,
timeout, execution_profile, paging_state, host, execute_as).result() {code}
> flaky dtest-upgrade.upgrade_tests.cql_tests
> TestCQLNodes2RF1_Upgrade_indev_4_0_x_To_indev_trunk test_static_cf
> --
>
> Key: CASSANDRA-17454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17454
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> {code:java}
> Error Messagecassandra.WriteFailure: Error from server: code=1500 [Replica(s)
> failed to execute write] message="Operation failed - received 1 responses and
> 1 failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 1, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}Stacktraceself =
> 0x7f36e8ae1a60>
> def test_static_cf(self):
> """ Test static CF syntax """
> cursor = self.prepare()
>
> # Create
> cursor.execute("""
> CREATE TABLE users (
> userid uuid PRIMARY KEY,
> firstname text,
> lastname text,
> age int
> );
> """)
>
> for is_upgraded, cursor in self.do_upgrade(cursor):
> logger.debug("Querying {} node".format("upgraded" if is_upgraded
> else "old"))
> cursor.execute("TRUNCATE users")
>
> # Inserts
> cursor.execute("INSERT INTO users (userid, firstname, lastname,
> age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
> cursor.execute("UPDATE users SET firstname = 'Samwise', lastname
> = 'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
>
> # Queries
> assert_one(cursor, "SELECT firstname,
[jira] [Updated] (CASSANDRA-17455) Flaky org.apache.cassandra.tools TopPartitionsTest testServiceTopPartitionsSingleTable
[
https://issues.apache.org/jira/browse/CASSANDRA-17455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17455:
--
Description:
{code:java}
Error Messageexpected:<1> but
was:<0>Stacktracejunit.framework.AssertionFailedError: expected:<1> but was:<0>
at
org.apache.cassandra.tools.TopPartitionsTest.testServiceTopPartitionsSingleTable(TopPartitionsTest.java:82)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Standard OutputINFO [main] 2022-03-17 23:37:01,750
YamlConfigurationLoader.java:103 - Configuration location:
file:/home/cassandra/cassandra/test/conf/cassandra.yaml
DEBUG [main] 2022-03-17 23:37:01,754 YamlConfigurationLoader.java:124 - Loading
settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
INFO [main] 2022-03-17 23:37:01,878 Config.java:1119 - Node
configuration:[allocate_tokens_for_keyspace=null;
allocate_tokens_for_local_replication_factor=null;
allow_extra_insecure_udfs=false; all
...[truncated 49100 chars]...
lizing counter cache with capacity of 2 MiBs
INFO [MemtableFlushWriter:1] 2022-03-17 23:37:03,857 CacheService.java:164 -
Scheduling counter cache save to every 7200 seconds (going to save all keys).
DEBUG [MemtableFlushWriter:1] 2022-03-17 23:37:03,883
ColumnFamilyStore.java:1249 - Flushed to
[BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system/IndexInfo-9f5c6374d48532299a0a5094af9ad1e3/nb-1-big-Data.db')]
(1 sstables, 4.915KiB), biggest 4.915KiB, smallest 4.915KiB {code}
> Flaky org.apache.cassandra.tools TopPartitionsTest
> testServiceTopPartitionsSingleTable
> --
>
> Key: CASSANDRA-17455
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17455
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> {code:java}
> Error Messageexpected:<1> but
> was:<0>Stacktracejunit.framework.AssertionFailedError: expected:<1> but
> was:<0>
> at
> org.apache.cassandra.tools.TopPartitionsTest.testServiceTopPartitionsSingleTable(TopPartitionsTest.java:82)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard OutputINFO [main] 2022-03-17 23:37:01,750
> YamlConfigurationLoader.java:103 - Configuration location:
> file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2022-03-17 23:37:01,754 YamlConfigurationLoader.java:124 -
> Loading settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> INFO [main] 2022-03-17 23:37:01,878 Config.java:1119 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null;
> allow_extra_insecure_udfs=false; all
> ...[truncated 49100 chars]...
> lizing counter cache with capacity of 2 MiBs
> INFO [MemtableFlushWriter:1] 2022-03-17 23:37:03,857 CacheService.java:164 -
> Scheduling counter cache save to every 7200 seconds (going to save all keys).
> DEBUG [MemtableFlushWriter:1] 2022-03-17 23:37:03,883
> ColumnFamilyStore.java:1249 - Flushed to
> [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system/IndexInfo-9f5c6374d48532299a0a5094af9ad1e3/nb-1-big-Data.db')]
> (1 sstables, 4.915KiB), biggest 4.915KiB, smallest 4.915KiB {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17455) Flaky org.apache.cassandra.tools TopPartitionsTest testServiceTopPartitionsSingleTable
[ https://issues.apache.org/jira/browse/CASSANDRA-17455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17455: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Component/s: CI Discovered By: Unit Test Severity: Normal Status: Open (was: Triage Needed) > Flaky org.apache.cassandra.tools TopPartitionsTest > testServiceTopPartitionsSingleTable > -- > > Key: CASSANDRA-17455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17455 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Stefan Miklosovic >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17455) Flaky org.apache.cassandra.tools TopPartitionsTest testServiceTopPartitionsSingleTable
Stefan Miklosovic created CASSANDRA-17455: - Summary: Flaky org.apache.cassandra.tools TopPartitionsTest testServiceTopPartitionsSingleTable Key: CASSANDRA-17455 URL: https://issues.apache.org/jira/browse/CASSANDRA-17455 Project: Cassandra Issue Type: Bug Reporter: Stefan Miklosovic -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17454) flaky dtest-upgrade.upgrade_tests.cql_tests TestCQLNodes2RF1_Upgrade_indev_4_0_x_To_indev_trunk test_static_cf
Stefan Miklosovic created CASSANDRA-17454: - Summary: flaky dtest-upgrade.upgrade_tests.cql_tests TestCQLNodes2RF1_Upgrade_indev_4_0_x_To_indev_trunk test_static_cf Key: CASSANDRA-17454 URL: https://issues.apache.org/jira/browse/CASSANDRA-17454 Project: Cassandra Issue Type: Bug Components: CI Reporter: Stefan Miklosovic -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17453) flaky in jvm CasCriticalSectionTest.criticalSectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17453:
--
Description:
>From CI, there are variations of this error:
{code:java}
org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
out: received 0 of 3 required responses after 0 contention retries at
org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:732) at
org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618) at
org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307) at
org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
at
org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
at
org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
at
org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
at
org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829) {code}
> flaky in jvm CasCriticalSectionTest.criticalSectionTest
> ---
>
> Key: CASSANDRA-17453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17453
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> From CI, there are variations of this error:
> {code:java}
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 0 of 3 required responses after 0 contention retries at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:732) at
> org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618) at
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307) at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508714#comment-17508714
]
Maciej Sokol commented on CASSANDRA-15458:
--
While looking at the python tests i found why there's a difference. See:
CASSANDRA-6172
I've tested unquoting both maps and other collections and ran some tests
locally with ccm. The error mentioned in the ticket above is not reproducible
(atleast not with what was stated in the ticket). Also noticed that UDTs are
quoted, which feels strange as well.
What do you think Benjamin? It's a pretty drastic change but if we want to be
consistent we should keep everything unquoted (since everything is unquoted by
default except when the values are in a collection).
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Maciej Sokol
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17453) flaky in jvm CasCriticalSectionTest.criticalSectionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-17453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17453: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Component/s: CI Discovered By: Unit Test Severity: Normal Status: Open (was: Triage Needed) > flaky in jvm CasCriticalSectionTest.criticalSectionTest > --- > > Key: CASSANDRA-17453 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17453 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Stefan Miklosovic >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17453) flaky in jvm CasCriticalSectionTest.criticalSectionTest
Stefan Miklosovic created CASSANDRA-17453: - Summary: flaky in jvm CasCriticalSectionTest.criticalSectionTest Key: CASSANDRA-17453 URL: https://issues.apache.org/jira/browse/CASSANDRA-17453 Project: Cassandra Issue Type: Bug Reporter: Stefan Miklosovic -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17432) Update cqlsh version in 4.1
[ https://issues.apache.org/jira/browse/CASSANDRA-17432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17432: Status: Review In Progress (was: Needs Committer) > Update cqlsh version in 4.1 > --- > > Key: CASSANDRA-17432 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17432 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > The cqlsh in version 4.1 has had several important internal changes to > credentials management and removing compatibility with Python2. Therefore > the version should be incremented; e.g from 6.0.0 to 6.1.0 or similar. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17452) Adding TLS version in conf/cqlshrc.sample
[ https://issues.apache.org/jira/browse/CASSANDRA-17452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17452: -- Summary: Adding TLS version in conf/cqlshrc.sample (was: Adding TLS version) > Adding TLS version in conf/cqlshrc.sample > -- > > Key: CASSANDRA-17452 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17452 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Hemang Ajmera >Priority: Low > > Created a Jira ticket to track [https://github.com/apache/cassandra/pull/974] > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17452) Adding TLS version
[ https://issues.apache.org/jira/browse/CASSANDRA-17452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17452: -- Change Category: Operability Complexity: Low Hanging Fruit Component/s: Documentation Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Adding TLS version > -- > > Key: CASSANDRA-17452 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17452 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Hemang Ajmera >Priority: Low > > Created a Jira ticket to track [https://github.com/apache/cassandra/pull/974] > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17452) Adding TLS version
Hemang Ajmera created CASSANDRA-17452: - Summary: Adding TLS version Key: CASSANDRA-17452 URL: https://issues.apache.org/jira/browse/CASSANDRA-17452 Project: Cassandra Issue Type: Improvement Reporter: Hemang Ajmera Created a Jira ticket to track [https://github.com/apache/cassandra/pull/974] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17451) Flaky upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
[
https://issues.apache.org/jira/browse/CASSANDRA-17451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17451:
--
Description:
dtest-upgrade.upgrade_tests.cql_tests
TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk
test_noncomposite_static_cf is flaky.
{code}
Error Message
cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
execute write] message="Operation failed - received 1 responses and 1 failures:
UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE', 'required_responses':
1, 'received_responses': 1, 'failures': 1, 'error_code_map': {'127.0.0.1':
'0x'}}
Stacktrace
self =
def test_noncomposite_static_cf(self):
""" Test non-composite static CF syntax """
cursor = self.prepare()
# Create
cursor.execute("""
CREATE TABLE users (
userid uuid PRIMARY KEY,
firstname ascii,
lastname ascii,
age int
) WITH COMPACT STORAGE;
""")
for is_upgraded, cursor in self.do_upgrade(cursor):
logger.debug("Querying {} node".format("upgraded" if is_upgraded
else "old"))
cursor.execute("TRUNCATE users")
# Inserts
cursor.execute("INSERT INTO users (userid, firstname, lastname,
age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
cursor.execute("UPDATE users SET firstname = 'Samwise', lastname =
'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
# Queries
assert_one(cursor, "SELECT firstname, lastname FROM users WHERE
userid = 550e8400-e29b-41d4-a716-44665544", ['Frodo', 'Baggins'])
assert_one(cursor, "SELECT * FROM users WHERE userid =
550e8400-e29b-41d4-a716-44665544",
[UUID('550e8400-e29b-41d4-a716-44665544'), 32,
'Frodo', 'Baggins'])
# FIXME There appears to be some sort of problem with reusable cells
# when executing this query. It's likely that CASSANDRA-9705 will
# fix this, but I'm not 100% sure.
assert_one(cursor, "SELECT * FROM users WHERE userid =
f47ac10b-58cc-4372-a567-0e02b2c3d479",
[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
'Samwise', 'Gamgee'])
assert_all(cursor, "SELECT * FROM users",
[[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
'Samwise', 'Gamgee'],
[UUID('550e8400-e29b-41d4-a716-44665544'), 32,
'Frodo', 'Baggins']])
# Test batch inserts
> cursor.execute("""
BEGIN BATCH
INSERT INTO users (userid, age) VALUES
(550e8400-e29b-41d4-a716-44665544, 36)
UPDATE users SET age = 37 WHERE userid =
f47ac10b-58cc-4372-a567-0e02b2c3d479
DELETE firstname, lastname FROM users WHERE userid =
550e8400-e29b-41d4-a716-44665544
DELETE firstname, lastname FROM users WHERE userid =
f47ac10b-58cc-4372-a567-0e02b2c3d479
APPLY BATCH
""")
upgrade_tests/cql_tests.py:157:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
return self.execute_async(query, parameters, trace, custom_payload,
timeout, execution_profile, paging_state, host, execute_as).result()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
{code}
> Flaky
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
> ---
>
> Key: CASSANDRA-17451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17451
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> dtest-upgrade.upgrade_tests.cql_tests
> TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk
> test_noncomposite_static_cf is flaky.
> {code}
> Error Message
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 1 responses and 1
> failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 1, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> Stacktrace
> self = 0x7fc77ceb7d00>
> def test_noncomposite_static_cf(self):
> """ Test non-composite static CF syntax """
> cursor = self.prepare()
>
> # Create
>
[jira] [Updated] (CASSANDRA-17451) Flaky upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
[ https://issues.apache.org/jira/browse/CASSANDRA-17451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17451: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Discovered By: DTest Fix Version/s: 4.x Severity: Normal Status: Open (was: Triage Needed) > Flaky > upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf > --- > > Key: CASSANDRA-17451 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17451 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17451) Flaky upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
Stefan Miklosovic created CASSANDRA-17451: - Summary: Flaky upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf Key: CASSANDRA-17451 URL: https://issues.apache.org/jira/browse/CASSANDRA-17451 Project: Cassandra Issue Type: Bug Components: CI Reporter: Stefan Miklosovic -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17392) Upgrade to netty 4.1.73.Final
[ https://issues.apache.org/jira/browse/CASSANDRA-17392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508604#comment-17508604 ] Berenguer Blasi commented on CASSANDRA-17392: - Jenkins disk full so retrying [#1516|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1516/] > Upgrade to netty 4.1.73.Final > - > > Key: CASSANDRA-17392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17392 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > The current netty version has CVEs as shown in CASSANDRA-17368. There we > suppressed the CVEs for other versions, but for trunk let's investigate > upgrading. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17432) Update cqlsh version in 4.1
[ https://issues.apache.org/jira/browse/CASSANDRA-17432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508601#comment-17508601 ] Berenguer Blasi commented on CASSANDRA-17432: - Jenkins disk full + GH outages so I restarted it again now that the later runs seems to be ok [#1515|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1515/] > Update cqlsh version in 4.1 > --- > > Key: CASSANDRA-17432 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17432 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > The cqlsh in version 4.1 has had several important internal changes to > credentials management and removing compatibility with Python2. Therefore > the version should be incremented; e.g from 6.0.0 to 6.1.0 or similar. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17197) Diagnostic events for guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-17197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508598#comment-17508598 ] Berenguer Blasi commented on CASSANDRA-17197: - Ok so I dropped just a suggestion to add some more test lines but otherwise LGTM. I did check CI and also LGTM but the repeated runs have 2 failing workers. Test results were not uploaded and looking at some of the failed logs the tests I looked at passed. So it's probably some env issue causing the red. This would need to be confirmed or a new repeatable run be triggered. Otherwise +1 from me. > Diagnostic events for guardrails > > > Key: CASSANDRA-17197 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17197 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.x > > Time Spent: 2h > Remaining Estimate: 0h > > Add diagnostic events for guardrails, so we can monitor when each type of > guardrail is triggered. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16895) Support Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508583#comment-17508583 ] Maulin Vasavada commented on CASSANDRA-16895: - I guess it could be because prior TLS versions (before TLSv1.2) are disabled in JDK 17 and the python client in python 3.8 might be defaulting to those. Not sure though, trying to look into it more. > Support Java 17 > --- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > 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 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
