[jira] [Comment Edited] (CASSANDRA-14667) Upgrade Dropwizard Metrics to 4.x

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-14667 at 9/22/23 10:57 PM:
---

I have a question: does anyone know why we opted in for JmxReporter at the 
first place in NodeProbe - I believe the usage of JmxReporter was added in 
CASSANDRA-14523. Why was it not used CassandraMetricsRegistry as we do 
[now|https://github.com/apache/cassandra/pull/2238/files#diff-92f8748902f03f37a4f7db56b4dfb7d226adcf3839141e6adb8ebbc575020d57R1835]?
 It is also done everywhere else in NodeProbe. [~cnlwsu] ?
{quote}Better be safe than sorry.
{quote}
+1
{quote}ant resolver plugin has some bugs in it 
{quote}
[~mck] , do you have links? I agree with [~smiklosovic]  and [~mmuzaf]  that it 
is good to follow up on that. At least to be sure we do things correctly. But 
that is, of course, not a blocker for this ticket. Let's collect the info we 
already have and follow up on this.

I do not see in the PR slf4j-api being updated. I thought we will update that 
one, too?  

It is important to mention this note from 1.7.35 for SLF4J:
{code:java}
• In this release, the "slf4j-log4j12" artifact automatically instructs Maven 
to use the "slf4j-reload4j" artifact instead. As you might have guessed, the 
"slf4j-reload4j" binding delegates log processing to the reload4j logging 
framework.
The reload4j project is a fork of Apache log4j version 1.2.17 with the goal of 
fixing pressing security issues. It is intended as a drop-in replacement for 
log4j version 1.2.17. By drop-in, we mean the replacement of log4j.jar with 
reload4j.jar in your build with no source code changes in .java files being 
necessary.
{code}
While I do not see issues here, I wanted to mention it for visibility.

I also reviewed the logback release notes (Thank you for the link!!). The only 
breaking change I saw was regarding DBAPPENDER, which we do not use. (Do we?) I 
saw RollingFileAppender, ConsoleAppender, AsyncAppender, InstrumentedAppender, 
FileAppender.

*Question:* Do we need to highlight anything specific in the NEWS.txt regarding 
the new dropwizard version, or just the CHANGES.txt entry that we bumped the 
version is enough? 

For completeness, below is the changelog for the drivers:

[https://github.com/datastax/java-driver/tree/3.x/changelog]

I noticed we exclude with the driver - netty-buffer, netty-codec, 
netty-handler, netty-transport and a few other dependencies. [~smiklosovic], 
you've been working on some new exclusions for netty after the last upgrade; 
anything else we need to do here with the driver in that regard? 

I will push the full CI when we confirm what we do with slf4j-api and the 
drivers' exclusions. I want to run the full test suite with upgrade tests, 
etc., and I would like to prevent doing it 4 instead of only 2 times (5.0 and 
trunk). 


was (Author: e.dimitrova):
I have a question: does anyone know why we opted in for JmxReporter at the 
first place in NodeProbe - I believe the usage of JmxReporter was added in 
CASSANDRA-14523. Why was it not used CassandraMetricsRegistry as we do 
[now|https://github.com/apache/cassandra/pull/2238/files#diff-92f8748902f03f37a4f7db56b4dfb7d226adcf3839141e6adb8ebbc575020d57R1835]?
 It is also done everywhere else in NodeProbe. [~cnlwsu] ?

{quote} Better be safe than sorry.
{quote}
+1

{quote}ant resolver plugin has some bugs in it 
{quote}
[~mck] , do you have links? I agree with [~smiklosovic]  and [~mmuzaf]  that it 
is good to follow up on that. At least to be sure we do things correctly. But 
that is, of course, not a blocker for this ticket. Let's collect the info we 
already have and follow up on this.

I do not see in the PR slf4j-api being updated. I thought we will update that 
one, too?  

It is important to mention this note from 1.7.35 for SLF4J:
{code:java}
• In this release, the "slf4j-log4j12" artifact automatically instructs Maven 
to use the "slf4j-reload4j" artifact instead. As you might have guessed, the 
"slf4j-reload4j" binding delegates log processing to the reload4j logging 
framework.
The reload4j project is a fork of Apache log4j version 1.2.17 with the goal of 
fixing pressing security issues. It is intended as a drop-in replacement for 
log4j version 1.2.17. By drop-in, we mean the replacement of log4j.jar with 
reload4j.jar in your build with no source code changes in .java files being 
necessary.
{code}
While I do not see issues here, I wanted to mention it for visibility.

I also reviewed the logback release notes (Thank you for the link!!). The only 
breaking change I saw was regarding DBAPPENDER, which we do not use. (Do we?) I 
saw RollingFileAppender, ConsoleAppender, AsyncAppender, InstrumentedAppender, 
FileAppender.

*Question:* Do we need to highlight anything specific in the NEWS.txt regarding 
the new dropwizard 

[jira] [Comment Edited] (CASSANDRA-14667) Upgrade Dropwizard Metrics to 4.x

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-14667 at 9/22/23 10:56 PM:
---

I have a question: does anyone know why we opted in for JmxReporter at the 
first place in NodeProbe - I believe the usage of JmxReporter was added in 
CASSANDRA-14523. Why was it not used CassandraMetricsRegistry as we do 
[now|https://github.com/apache/cassandra/pull/2238/files#diff-92f8748902f03f37a4f7db56b4dfb7d226adcf3839141e6adb8ebbc575020d57R1835]?
 It is also done everywhere else in NodeProbe. [~cnlwsu] ?

{quote} Better be safe than sorry.
{quote}
+1

{quote}ant resolver plugin has some bugs in it 
{quote}
[~mck] , do you have links? I agree with [~smiklosovic]  and [~mmuzaf]  that it 
is good to follow up on that. At least to be sure we do things correctly. But 
that is, of course, not a blocker for this ticket. Let's collect the info we 
already have and follow up on this.

I do not see in the PR slf4j-api being updated. I thought we will update that 
one, too?  

It is important to mention this note from 1.7.35 for SLF4J:
{code:java}
• In this release, the "slf4j-log4j12" artifact automatically instructs Maven 
to use the "slf4j-reload4j" artifact instead. As you might have guessed, the 
"slf4j-reload4j" binding delegates log processing to the reload4j logging 
framework.
The reload4j project is a fork of Apache log4j version 1.2.17 with the goal of 
fixing pressing security issues. It is intended as a drop-in replacement for 
log4j version 1.2.17. By drop-in, we mean the replacement of log4j.jar with 
reload4j.jar in your build with no source code changes in .java files being 
necessary.
{code}
While I do not see issues here, I wanted to mention it for visibility.

I also reviewed the logback release notes (Thank you for the link!!). The only 
breaking change I saw was regarding DBAPPENDER, which we do not use. (Do we?) I 
saw RollingFileAppender, ConsoleAppender, AsyncAppender, InstrumentedAppender, 
FileAppender.

*Question:* Do we need to highlight anything specific in the NEWS.txt regarding 
the new dropwizard version, or just the CHANGES.txt entry that we bumped the 
version is enough? 

For completeness, below is the changelog for the drivers:

[https://github.com/datastax/java-driver/tree/3.x/changelog]

I noticed we exclude with the driver - natty-buffer, natty-codec, 
natty-handler, netty-transport and a few other dependencies. [~smiklosovic], 
you've been working on some new exclusions for netty after the last upgrade; 
anything else we need to do here with the driver in that regard? 

I will push the full CI when we confirm what we do with slf4j-api and the 
drivers' exclusions. I want to run the full test suite with upgrade tests, 
etc., and I would like to prevent doing it 4 instead of only 2 times (5.0 and 
trunk). 


was (Author: e.dimitrova):
I have a question: does anyone know why we opted in for JmxReporter at the 
first place in NodeProbe - I believe the usage of JmxReporter was added in 
CASSANDRA-14523. Why was it not used CassandraMetricsRegistry as we do 
[now|https://github.com/apache/cassandra/pull/2238/files#diff-92f8748902f03f37a4f7db56b4dfb7d226adcf3839141e6adb8ebbc575020d57R1835]?
 It is also done everywhere else in NodeProbe. [~cnlwsu] ?
{quote}{quote} Better be safe than sorry.
{quote}{quote}
+1
{quote}ant resolver plugin has some bugs in it 
{quote}
[~mck] , do you have links? I agree with [~smiklosovic]  and [~mmuzaf]  that it 
is good to follow up on that. At least to be sure we do things correctly. But 
that is, of course, not a blocker for this ticket. Let's collect the info we 
already have and follow up on this.

I do not see in the PR slf4j-api being updated. I thought we will update that 
one, too?  

It is important to mention this note from 1.7.35 for SLF4J:
{code:java}
• In this release, the "slf4j-log4j12" artifact automatically instructs Maven 
to use the "slf4j-reload4j" artifact instead. As you might have guessed, the 
"slf4j-reload4j" binding delegates log processing to the reload4j logging 
framework.
The reload4j project is a fork of Apache log4j version 1.2.17 with the goal of 
fixing pressing security issues. It is intended as a drop-in replacement for 
log4j version 1.2.17. By drop-in, we mean the replacement of log4j.jar with 
reload4j.jar in your build with no source code changes in .java files being 
necessary.
{code}
While I do not see issues here, I wanted to mention it for visibility.

I also reviewed the logback release notes (Thank you for the link!!). The only 
breaking change I saw was regarding DBAPPENDER, which we do not use. (Do we?) I 
saw RollingFileAppender, ConsoleAppender, AsyncAppender, InstrumentedAppender, 
FileAppender.

*Question:* Do we need to highlight anything specific in the NEWS.txt regarding 
the new 

[jira] [Comment Edited] (CASSANDRA-14667) Upgrade Dropwizard Metrics to 4.x

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-14667 at 9/22/23 10:55 PM:
---

I have a question: does anyone know why we opted in for JmxReporter at the 
first place in NodeProbe - I believe the usage of JmxReporter was added in 
CASSANDRA-14523. Why was it not used CassandraMetricsRegistry as we do 
[now|https://github.com/apache/cassandra/pull/2238/files#diff-92f8748902f03f37a4f7db56b4dfb7d226adcf3839141e6adb8ebbc575020d57R1835]?
 It is also done everywhere else in NodeProbe. [~cnlwsu] ?
{quote}{quote} Better be safe than sorry.
{quote}{quote}
+1
{quote}ant resolver plugin has some bugs in it 
{quote}
[~mck] , do you have links? I agree with [~smiklosovic]  and [~mmuzaf]  that it 
is good to follow up on that. At least to be sure we do things correctly. But 
that is, of course, not a blocker for this ticket. Let's collect the info we 
already have and follow up on this.

I do not see in the PR slf4j-api being updated. I thought we will update that 
one, too?  

It is important to mention this note from 1.7.35 for SLF4J:
{code:java}
• In this release, the "slf4j-log4j12" artifact automatically instructs Maven 
to use the "slf4j-reload4j" artifact instead. As you might have guessed, the 
"slf4j-reload4j" binding delegates log processing to the reload4j logging 
framework.
The reload4j project is a fork of Apache log4j version 1.2.17 with the goal of 
fixing pressing security issues. It is intended as a drop-in replacement for 
log4j version 1.2.17. By drop-in, we mean the replacement of log4j.jar with 
reload4j.jar in your build with no source code changes in .java files being 
necessary.
{code}
While I do not see issues here, I wanted to mention it for visibility.

I also reviewed the logback release notes (Thank you for the link!!). The only 
breaking change I saw was regarding DBAPPENDER, which we do not use. (Do we?) I 
saw RollingFileAppender, ConsoleAppender, AsyncAppender, InstrumentedAppender, 
FileAppender.

*Question:* Do we need to highlight anything specific in the NEWS.txt regarding 
the new dropwizard version, or just the CHANGES.txt entry that we bumped the 
version is enough? 

For completeness, below is the changelog for the drivers:

[https://github.com/datastax/java-driver/tree/3.x/changelog]

I noticed we exclude with the driver - natty-buffer, natty-codec, 
natty-handler, netty-transport and a few other dependencies. [~smiklosovic], 
you've been working on some new exclusions for netty after the last upgrade; 
anything else we need to do here with the driver in that regard? 

I will push the full CI when we confirm what we do with slf4j-api and the 
drivers' exclusions. I want to run the full test suite with upgrade tests, 
etc., and I would like to prevent doing it 4 instead of only 2 times (5.0 and 
trunk). 


was (Author: e.dimitrova):
I have a question: does anyone know why we opted in for JmxReporter at the 
first place in NodeProbe - I believe the usage of JmxReporter was added in 
CASSANDRA-14523. Why was it not used CassandraMetricsRegistry as we do now? It 
is also done everywhere else in NodeProbe. [~cnlwsu] ?
{quote}bq. Better be safe than sorry.
{quote}
+1
{quote}ant resolver plugin has some bugs in it 
{quote}
[~mck] , do you have links? I agree with [~smiklosovic]  and [~mmuzaf]  that it 
is good to follow up on that. At least to be sure we do things correctly. But 
that is, of course, not a blocker for this ticket. Let's collect the info we 
already have and follow up on this.

I do not see in the PR slf4j-api being updated. I thought we will update that 
one, too?  

It is important to mention this note from 1.7.35 for SLF4J:
{code:java}
• In this release, the "slf4j-log4j12" artifact automatically instructs Maven 
to use the "slf4j-reload4j" artifact instead. As you might have guessed, the 
"slf4j-reload4j" binding delegates log processing to the reload4j logging 
framework.
The reload4j project is a fork of Apache log4j version 1.2.17 with the goal of 
fixing pressing security issues. It is intended as a drop-in replacement for 
log4j version 1.2.17. By drop-in, we mean the replacement of log4j.jar with 
reload4j.jar in your build with no source code changes in .java files being 
necessary.
{code}
While I do not see issues here, I wanted to mention it for visibility.

I also reviewed the logback release notes (Thank you for the link!!). The only 
breaking change I saw was regarding DBAPPENDER, which we do not use. (Do we?) I 
saw RollingFileAppender, ConsoleAppender, AsyncAppender, InstrumentedAppender, 
FileAppender.

*Question:* Do we need to highlight anything specific in the NEWS.txt regarding 
the new dropwizard version, or just the CHANGES.txt entry that we bumped the 
version is enough? 

For completeness, below is the 

[jira] [Comment Edited] (CASSANDRA-14667) Upgrade Dropwizard Metrics to 4.x

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-14667 at 9/22/23 10:53 PM:
---

I have a question: does anyone know why we opted in for JmxReporter at the 
first place in NodeProbe - I believe the usage of JmxReporter was added in 
CASSANDRA-14523. Why was it not used CassandraMetricsRegistry as we do now? It 
is also done everywhere else in NodeProbe. [~cnlwsu] ?
{quote}bq. Better be safe than sorry.
{quote}
+1
{quote}ant resolver plugin has some bugs in it 
{quote}
[~mck] , do you have links? I agree with [~smiklosovic]  and [~mmuzaf]  that it 
is good to follow up on that. At least to be sure we do things correctly. But 
that is, of course, not a blocker for this ticket. Let's collect the info we 
already have and follow up on this.

I do not see in the PR slf4j-api being updated. I thought we will update that 
one, too?  

It is important to mention this note from 1.7.35 for SLF4J:
{code:java}
• In this release, the "slf4j-log4j12" artifact automatically instructs Maven 
to use the "slf4j-reload4j" artifact instead. As you might have guessed, the 
"slf4j-reload4j" binding delegates log processing to the reload4j logging 
framework.
The reload4j project is a fork of Apache log4j version 1.2.17 with the goal of 
fixing pressing security issues. It is intended as a drop-in replacement for 
log4j version 1.2.17. By drop-in, we mean the replacement of log4j.jar with 
reload4j.jar in your build with no source code changes in .java files being 
necessary.
{code}
While I do not see issues here, I wanted to mention it for visibility.

I also reviewed the logback release notes (Thank you for the link!!). The only 
breaking change I saw was regarding DBAPPENDER, which we do not use. (Do we?) I 
saw RollingFileAppender, ConsoleAppender, AsyncAppender, InstrumentedAppender, 
FileAppender.

*Question:* Do we need to highlight anything specific in the NEWS.txt regarding 
the new dropwizard version, or just the CHANGES.txt entry that we bumped the 
version is enough? 

For completeness, below is the changelog for the drivers:

[https://github.com/datastax/java-driver/tree/3.x/changelog]

I noticed we exclude with the driver - natty-buffer, natty-codec, 
natty-handler, netty-transport and a few other dependencies. [~smiklosovic], 
you've been working on some new exclusions for netty after the last upgrade; 
anything else we need to do here with the driver in that regard? 

I will push the full CI when we confirm what we do with slf4j-api and the 
drivers' exclusions. I want to run the full test suite with upgrade tests, 
etc., and I would like to prevent doing it 4 instead of only 2 times (5.0 and 
trunk). 


was (Author: e.dimitrova):
{quote}Better be safe than sorry.
{quote}
+1
{quote}ant resolver plugin has some bugs in it 
{quote}
[~mck] , do you have links? I agree with [~smiklosovic]  and [~mmuzaf]  that it 
is good to follow up on that. At least to be sure we do things correctly. But 
that is, of course, not a blocker for this ticket. Let's collect the info we 
already have and not forget to follow up on this.

I do not see in the PR slf4j-api being updated. I thought we will update that 
one, too?  

It is important to mention this note from 1.7.35 for SLF4J:

 
{code:java}
• In this release, the "slf4j-log4j12" artifact automatically instructs Maven 
to use the "slf4j-reload4j" artifact instead. As you might have guessed, the 
"slf4j-reload4j" binding delegates log processing to the reload4j logging 
framework.
The reload4j project is a fork of Apache log4j version 1.2.17 with the goal of 
fixing pressing security issues. It is intended as a drop-in replacement for 
log4j version 1.2.17. By drop-in, we mean the replacement of log4j.jar with 
reload4j.jar in your build with no source code changes in .java files being 
necessary.
{code}
While I do not see issues here, I wanted to mention it for visibility.

I also reviewed the logback release notes (Thank you for the link!!). The only 
breaking change I saw was regarding DBAPPENDER, which we do not use. (Do we?) I 
saw RollingFileAppender, ConsoleAppender, AsyncAppender, InstrumentedAppender, 
FileAppender.

*Question:* Do we need to highlight anything specific in the NEWS.txt regarding 
the new dropwizard version, or just the CHANGES.txt entry that we bumped the 
version is enough? 

For completeness, below is the changelog for the drivers:

[https://github.com/datastax/java-driver/tree/3.x/changelog]

I noticed we exclude with the driver - natty-buffer, natty-codec, 
natty-handler, netty-transport and a few other dependencies. [~smiklosovic], 
you've been working on some new exclusions for netty after the last upgrade; 
anything else we need to do here with the driver in that regard? 

I will push the full CI when we confirm 

[jira] [Commented] (CASSANDRA-14667) Upgrade Dropwizard Metrics to 4.x

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova commented on CASSANDRA-14667:
-

{quote}Better be safe than sorry.
{quote}
+1
{quote}ant resolver plugin has some bugs in it 
{quote}
[~mck] , do you have links? I agree with [~smiklosovic]  and [~mmuzaf]  that it 
is good to follow up on that. At least to be sure we do things correctly. But 
that is, of course, not a blocker for this ticket. Let's collect the info we 
already have and not forget to follow up on this.

I do not see in the PR slf4j-api being updated. I thought we will update that 
one, too?  

It is important to mention this note from 1.7.35 for SLF4J:

 
{code:java}
• In this release, the "slf4j-log4j12" artifact automatically instructs Maven 
to use the "slf4j-reload4j" artifact instead. As you might have guessed, the 
"slf4j-reload4j" binding delegates log processing to the reload4j logging 
framework.
The reload4j project is a fork of Apache log4j version 1.2.17 with the goal of 
fixing pressing security issues. It is intended as a drop-in replacement for 
log4j version 1.2.17. By drop-in, we mean the replacement of log4j.jar with 
reload4j.jar in your build with no source code changes in .java files being 
necessary.
{code}
While I do not see issues here, I wanted to mention it for visibility.

I also reviewed the logback release notes (Thank you for the link!!). The only 
breaking change I saw was regarding DBAPPENDER, which we do not use. (Do we?) I 
saw RollingFileAppender, ConsoleAppender, AsyncAppender, InstrumentedAppender, 
FileAppender.

*Question:* Do we need to highlight anything specific in the NEWS.txt regarding 
the new dropwizard version, or just the CHANGES.txt entry that we bumped the 
version is enough? 

For completeness, below is the changelog for the drivers:

[https://github.com/datastax/java-driver/tree/3.x/changelog]

I noticed we exclude with the driver - natty-buffer, natty-codec, 
natty-handler, netty-transport and a few other dependencies. [~smiklosovic], 
you've been working on some new exclusions for netty after the last upgrade; 
anything else we need to do here with the driver in that regard? 

I will push the full CI when we confirm what we do with slf4j-api and the 
drivers' exclusions. I want to run the full test suite with upgrade tests, 
etc., and I would like to prevent doing it 4 instead of only 2 times (5.0 and 
trunk). 

 

 

 

 

 

> Upgrade Dropwizard Metrics to 4.x
> -
>
> Key: CASSANDRA-14667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14667
> Project: Cassandra
>  Issue Type: Task
>  Components: Observability/Metrics
>Reporter: Stig Rohde Døssing
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: signature.asc, signature.asc, signature.asc, 
> signature.asc
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Cassandra currently uses Metrics 3.1.5. Version 4.0.0 added some fixes for 
> Java 9 compatibility. It would be good to upgrade the Metrics library as part 
> of the version of Cassandra that adds Java 9 compatibility 
> (https://issues.apache.org/jira/browse/CASSANDRA-9608). 



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

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

[jira] [Updated] (CASSANDRASC-75) Shaded Sidecar client should shade Jackson completely to avoid incompatibility issues

[Doug Rohrer (Jira)]

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

Doug Rohrer updated CASSANDRASC-75:
---
Description: 
Before, we were shading almost all of Jackson but left the annotations 
unshaded/relocated. However, this causes problems in older Spark environments 
where the annotations in the class path don’t quite match what the other shaded 
parts of Jackson expect (missing classes being the most serious issue). This 
can cause the library to fail on certain Spark versions.
 
We should shade +all+ of Jackson in the shaded client to prevent these issues.

  was:
Before, we we shading almost all of Jackson but left the annotations 
unshaded/relocated. However, this causes problems in older Spark environments 
where the annotations in the class path don’t quite match what the other shaded 
parts of Jackson expect (missing classes being the most serious issue). This 
can cause the library to fail on certain Spark versions.
 
We should shade +all+ of Jackson in the shaded client to prevent these issues.


> Shaded Sidecar client should shade Jackson completely to avoid 
> incompatibility issues
> -
>
> Key: CASSANDRASC-75
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-75
> Project: Sidecar for Apache Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Doug Rohrer
>Assignee: Doug Rohrer
>Priority: Normal
> Fix For: 1.0
>
>
> Before, we were shading almost all of Jackson but left the annotations 
> unshaded/relocated. However, this causes problems in older Spark environments 
> where the annotations in the class path don’t quite match what the other 
> shaded parts of Jackson expect (missing classes being the most serious 
> issue). This can cause the library to fail on certain Spark versions.
>  
> We should shade +all+ of Jackson in the shaded client to prevent these issues.



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

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

[jira] [Commented] (CASSANDRASC-75) Shaded Sidecar client should shade Jackson completely to avoid incompatibility issues

[Dinesh Joshi (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRASC-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768137#comment-17768137
 ] 

Dinesh Joshi commented on CASSANDRASC-75:
-

+1, thanks for the patch.

> Shaded Sidecar client should shade Jackson completely to avoid 
> incompatibility issues
> -
>
> Key: CASSANDRASC-75
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-75
> Project: Sidecar for Apache Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Doug Rohrer
>Assignee: Doug Rohrer
>Priority: Normal
> Fix For: 1.0
>
>
> Before, we we shading almost all of Jackson but left the annotations 
> unshaded/relocated. However, this causes problems in older Spark environments 
> where the annotations in the class path don’t quite match what the other 
> shaded parts of Jackson expect (missing classes being the most serious 
> issue). This can cause the library to fail on certain Spark versions.
>  
> We should shade +all+ of Jackson in the shaded client to prevent these issues.



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

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

[jira] [Commented] (CASSANDRA-18810) Cassandra Analytics Start-Up Validation

[Dinesh Joshi (Jira)]

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

Dinesh Joshi commented on CASSANDRA-18810:
--

+1, thanks for the patch.

> Cassandra Analytics Start-Up Validation
> ---
>
> Key: CASSANDRA-18810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18810
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Analytics Library
>Reporter: Yuriy Semchyshyn
>Assignee: Yuriy Semchyshyn
>Priority: Normal
>  Time Spent: 6.5h
>  Remaining Estimate: 0h
>
> Cassandra Analytics should perform a start-up validation of network 
> connectivity to Cassandra and Cassandra Sidecar, as well as of authentication 
> materials



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

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

[jira] [Commented] (CASSANDRASC-75) Shaded Sidecar client should shade Jackson completely to avoid incompatibility issues

[Doug Rohrer (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRASC-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768135#comment-17768135
 ] 

Doug Rohrer commented on CASSANDRASC-75:


Clean CI (after a few flakes dealing with, I think, OOMs but it's hard to tell 
from the logs of previous runs)

[https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra-sidecar/70/workflows/e335963c-7423-4016-aa54-403b09faf800]

> Shaded Sidecar client should shade Jackson completely to avoid 
> incompatibility issues
> -
>
> Key: CASSANDRASC-75
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-75
> Project: Sidecar for Apache Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Doug Rohrer
>Assignee: Doug Rohrer
>Priority: Normal
> Fix For: 1.0
>
>
> Before, we we shading almost all of Jackson but left the annotations 
> unshaded/relocated. However, this causes problems in older Spark environments 
> where the annotations in the class path don’t quite match what the other 
> shaded parts of Jackson expect (missing classes being the most serious 
> issue). This can cause the library to fail on certain Spark versions.
>  
> We should shade +all+ of Jackson in the shaded client to prevent these issues.



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

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

[GitHub] [cassandra-analytics] frankgh commented on a diff in pull request #15: [CASSANDRA-18810] Cassandra Analytics Start-Up Validation

[via GitHub]

frankgh commented on code in PR #15:
URL: 
https://github.com/apache/cassandra-analytics/pull/15#discussion_r1334733370


##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/data/CassandraDataLayer.java:
##
@@ -685,6 +700,7 @@ private void readObject(ObjectInputStream in) throws 
IOException, ClassNotFoundE
 }
 this.rfMap = (Map) in.readObject();
 this.initInstanceMap();
+this.startupValidate();

Review Comment:
   initInstanceMap, will instantiate the sidecar client, which is needed to 
perform the connection checks



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[GitHub] [cassandra-analytics] dineshjoshi commented on a diff in pull request #15: [CASSANDRA-18810] Cassandra Analytics Start-Up Validation

[via GitHub]

dineshjoshi commented on code in PR #15:
URL: 
https://github.com/apache/cassandra-analytics/pull/15#discussion_r1334732728


##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/data/CassandraDataLayer.java:
##
@@ -685,6 +700,7 @@ private void readObject(ObjectInputStream in) throws 
IOException, ClassNotFoundE
 }
 this.rfMap = (Map) in.readObject();
 this.initInstanceMap();
+this.startupValidate();

Review Comment:
   Shouldn't this be performed _before_ `initInstanceMap`? `initInstanceMap` 
will likely reach out to external services to build the instance map and may 
fail to retrieve information? This would defeat the purpose of using 
`startupValidate`?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[jira] [Commented] (CASSANDRASC-74) Unable to stream index file components

[Francisco Guerrero (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRASC-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768128#comment-17768128
 ] 

Francisco Guerrero commented on CASSANDRASC-74:
---

Green CI: 
https://app.circleci.com/pipelines/github/frankgh/cassandra-sidecar/306

> Unable to stream index file components
> --
>
> Key: CASSANDRASC-74
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-74
> Project: Sidecar for Apache Cassandra
>  Issue Type: Bug
>  Components: Rest API
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>  Labels: pull-request-available
>
> The stream SSTables components API fails on secondary index files. When a 
> table has a secondary index defined, and we list the snapshot including the 
> secondary index files, and then try to stream the SSTable components, we will 
> see a 404 (Not Found) error.



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

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

[jira] [Updated] (CASSANDRASC-75) Shaded Sidecar client should shade Jackson completely to avoid incompatibility issues

[Doug Rohrer (Jira)]

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

Doug Rohrer updated CASSANDRASC-75:
---
Authors: Doug Rohrer
Test and Documentation Plan: All existing tests should pass. There should 
be no exclusions in the vertx-client-all jar for Jackson libraries, and they 
should all be relocated.
 Status: Patch Available  (was: Open)

[https://github.com/apache/cassandra-sidecar/pull/71]

> Shaded Sidecar client should shade Jackson completely to avoid 
> incompatibility issues
> -
>
> Key: CASSANDRASC-75
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-75
> Project: Sidecar for Apache Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Doug Rohrer
>Assignee: Doug Rohrer
>Priority: Normal
> Fix For: 1.0
>
>
> Before, we we shading almost all of Jackson but left the annotations 
> unshaded/relocated. However, this causes problems in older Spark environments 
> where the annotations in the class path don’t quite match what the other 
> shaded parts of Jackson expect (missing classes being the most serious 
> issue). This can cause the library to fail on certain Spark versions.
>  
> We should shade +all+ of Jackson in the shaded client to prevent these issues.



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

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

[jira] [Updated] (CASSANDRASC-75) Shaded Sidecar client should shade Jackson completely to avoid incompatibility issues

[Doug Rohrer (Jira)]

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

Doug Rohrer updated CASSANDRASC-75:
---
Change Category: Operability
 Complexity: Low Hanging Fruit
Component/s: Configuration
  Fix Version/s: 1.0
   Assignee: Doug Rohrer
 Status: Open  (was: Triage Needed)

> Shaded Sidecar client should shade Jackson completely to avoid 
> incompatibility issues
> -
>
> Key: CASSANDRASC-75
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-75
> Project: Sidecar for Apache Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Doug Rohrer
>Assignee: Doug Rohrer
>Priority: Normal
> Fix For: 1.0
>
>
> Before, we we shading almost all of Jackson but left the annotations 
> unshaded/relocated. However, this causes problems in older Spark environments 
> where the annotations in the class path don’t quite match what the other 
> shaded parts of Jackson expect (missing classes being the most serious 
> issue). This can cause the library to fail on certain Spark versions.
>  
> We should shade +all+ of Jackson in the shaded client to prevent these issues.



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

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

[cassandra-website] branch asf-staging updated (b345dbfac -> aeb3a7d49)

[git-site-role]

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

git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git


 discard b345dbfac generate docs for bc8bfc13
 new aeb3a7d49 generate docs for bc8bfc13

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (b345dbfac)
\
 N -- N -- N   refs/heads/asf-staging (aeb3a7d49)

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

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

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


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


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

[jira] [Comment Edited] (CASSANDRA-18875) Upgrade the snakeyaml library version

[Brandon Williams (Jira)]

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

Brandon Williams edited comment on CASSANDRA-18875 at 9/22/23 4:06 PM:
---

No, those are in bugfix-only.  We can't risk regressions in stable branches to 
appease less sophisticated scanners.


was (Author: brandon.williams):
No, those are in bugfix-only.

> Upgrade the snakeyaml library version
> -
>
> Key: CASSANDRA-18875
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18875
> Project: Cassandra
>  Issue Type: Task
>  Components: Local/Config
>Reporter: Jai Bheemsen Rao Dhanwada
>Priority: Normal
> Fix For: 5.x
>
>
> Apache cassandra uses 1.26 version of snakeyaml dependency and there are 
> several 
> [vulnerabilities|https://mvnrepository.com/artifact/org.yaml/snakeyaml/1.26#] 
> in this version that can be fixed by upgrading to 2.x version. I understand 
> that this is not security issue as cassandra already uses SafeConstructor and 
> is not a vulnerability under OWASP, so there are no plans to fix it as per  
> CASSANDRA-18122
>  
> Cassandra as a open source used and distributed by many enterprise customers 
> and also when downloading cassandra as tar and using it external scanners are 
> not aware of the implementation of SafeConstructor have no idea if it's 
> vulnerable or not. 
> Can we consider upgrading the version to 2.x in the next releases as 
> snakeyaml is not something that has a large dependency between the major and 
> minor versions. I am happy to open a PR for this. Please let me know your 
> thoughts on this.



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

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

[jira] [Commented] (CASSANDRA-18875) Upgrade the snakeyaml library version

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-18875:
--

No, those are in bugfix-only.

> Upgrade the snakeyaml library version
> -
>
> Key: CASSANDRA-18875
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18875
> Project: Cassandra
>  Issue Type: Task
>  Components: Local/Config
>Reporter: Jai Bheemsen Rao Dhanwada
>Priority: Normal
> Fix For: 5.x
>
>
> Apache cassandra uses 1.26 version of snakeyaml dependency and there are 
> several 
> [vulnerabilities|https://mvnrepository.com/artifact/org.yaml/snakeyaml/1.26#] 
> in this version that can be fixed by upgrading to 2.x version. I understand 
> that this is not security issue as cassandra already uses SafeConstructor and 
> is not a vulnerability under OWASP, so there are no plans to fix it as per  
> CASSANDRA-18122
>  
> Cassandra as a open source used and distributed by many enterprise customers 
> and also when downloading cassandra as tar and using it external scanners are 
> not aware of the implementation of SafeConstructor have no idea if it's 
> vulnerable or not. 
> Can we consider upgrading the version to 2.x in the next releases as 
> snakeyaml is not something that has a large dependency between the major and 
> minor versions. I am happy to open a PR for this. Please let me know your 
> thoughts on this.



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

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

[jira] [Commented] (CASSANDRA-18875) Upgrade the snakeyaml library version

[Jai Bheemsen Rao Dhanwada (Jira)]

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

Jai Bheemsen Rao Dhanwada commented on CASSANDRA-18875:
---

Thanks [~brandon.williams] the current version is 4.x which is in active use 
for most of the industry, can we update in the future 4.x release? I can send a 
PR for it.

> Upgrade the snakeyaml library version
> -
>
> Key: CASSANDRA-18875
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18875
> Project: Cassandra
>  Issue Type: Task
>  Components: Local/Config
>Reporter: Jai Bheemsen Rao Dhanwada
>Priority: Normal
> Fix For: 5.x
>
>
> Apache cassandra uses 1.26 version of snakeyaml dependency and there are 
> several 
> [vulnerabilities|https://mvnrepository.com/artifact/org.yaml/snakeyaml/1.26#] 
> in this version that can be fixed by upgrading to 2.x version. I understand 
> that this is not security issue as cassandra already uses SafeConstructor and 
> is not a vulnerability under OWASP, so there are no plans to fix it as per  
> CASSANDRA-18122
>  
> Cassandra as a open source used and distributed by many enterprise customers 
> and also when downloading cassandra as tar and using it external scanners are 
> not aware of the implementation of SafeConstructor have no idea if it's 
> vulnerable or not. 
> Can we consider upgrading the version to 2.x in the next releases as 
> snakeyaml is not something that has a large dependency between the major and 
> minor versions. I am happy to open a PR for this. Please let me know your 
> thoughts on this.



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

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

[jira] [Commented] (CASSANDRA-18547) Refactor cqlsh On/Off switch implementation and make the output consistent

[Brad Schoening (Jira)]

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

Brad Schoening commented on CASSANDRA-18547:


[~smiklosovic] I've corrected that, let's see if that fixes it.

> Refactor cqlsh On/Off switch implementation and make the output consistent
> --
>
> Key: CASSANDRA-18547
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18547
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 5.x
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This change refactors the On/Off switch implemented in the class 
> SwitchCommand and subclass  SwitchCommandWithValue of cqlshmain.py to use an 
> Enum with static methods instead of custom classes.
> The body of on_off_switch + enum definition requires just 15 lines of code vs 
> 33 in SwitchCommand.
> The existing code is hard to read, including the usage in the code, which 
> instantiates a SwitchCommand object in-order to invoke the execute method:
>  
> {code:java}
> self.tracing_enabled = SwitchCommand("TRACING", 
> "Tracing").execute(self.tracing_enabled, parsed, self.printerr){code}
> this can be replaced by a more familiar direct function call:
> {code:java}
> self.tracing_enabled = self.on_off_toggle("TRACING", "Tracing", 
> self.tracing_enabled, parsed.get_binding('switch')){code}
>  
> The refactoring also updates the command output for consistency. Instead of 
> the current:
> {code:java}
> > tracing on
> Now Tracing is enabled
> > paging on
> Query paging is already enabled. Use PAGING OFF to disable.
> > expand on
> Now Expanded output is enabled
> {code}
> replace with more succinct and consistent, using 'ON/OFF' instead of 
> enabled/disabled and removing the redundant 'Now':
> {code:java}
> > tracing on
> TRACING set to ON
> > paging on
> PAGING is already ON
> > expand on
> EXPAND set to ON
> {code}
>  



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

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

[jira] [Updated] (CASSANDRA-18876) The vector data type shouldn't support empty value

[Jira]

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

Andres de la Peña updated CASSANDRA-18876:
--
Fix Version/s: 5.0.x
   5.x

> The vector data type shouldn't support empty value
> --
>
> Key: CASSANDRA-18876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18876
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Vector Search
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As discussed on [the mail 
> list|https://lists.apache.org/thread/qq0jkm6rlkd2slfmhgz7om14tbpys891], the 
> vector data type shouldn't allow empty values.



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

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

[jira] [Commented] (CASSANDRA-18876) The vector data type shouldn't support empty value

[Jira]

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

Andres de la Peña commented on CASSANDRA-18876:
---

CC [~dcapwell] 

> The vector data type shouldn't support empty value
> --
>
> Key: CASSANDRA-18876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18876
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Vector Search
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As discussed on [the mail 
> list|https://lists.apache.org/thread/qq0jkm6rlkd2slfmhgz7om14tbpys891], the 
> vector data type shouldn't allow empty values.



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

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

[jira] [Commented] (CASSANDRA-18876) The vector data type shouldn't support empty value

[Jira]

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

Andres de la Peña commented on CASSANDRA-18876:
---

Here is the patch for 5.0, CI is still running:
||PR||CI||
|[5.0|https://github.com/apache/cassandra/pull/2723]|[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/3209/workflows/8c1d6afe-b93c-4b78-9879-1bc3e711be3c]
 
[j17|https://app.circleci.com/pipelines/github/adelapena/cassandra/3209/workflows/bd410ccb-55fb-4efd-a0b0-565ac6da2347]|

The first commit removes support for empty values on the vector type. 

The second commit changes the method {{AbstractType#allowsEmpty}} to be false 
by default, so future new data types tend to follow this convention.

I'll add the PR for {{trunk}} if this one looks good. Most probably it will be 
very similar, if not identical.

> The vector data type shouldn't support empty value
> --
>
> Key: CASSANDRA-18876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18876
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Vector Search
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As discussed on [the mail 
> list|https://lists.apache.org/thread/qq0jkm6rlkd2slfmhgz7om14tbpys891], the 
> vector data type shouldn't allow empty values.



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

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

[jira] [Updated] (CASSANDRA-18876) The vector data type shouldn't support empty value

[Jira]

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

Andres de la Peña updated CASSANDRA-18876:
--
Test and Documentation Plan: 
||PR||CI||
|[5.0|https://github.com/apache/cassandra/pull/2723]|[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/3209/workflows/8c1d6afe-b93c-4b78-9879-1bc3e711be3c]
 
[j17|https://app.circleci.com/pipelines/github/adelapena/cassandra/3209/workflows/bd410ccb-55fb-4efd-a0b0-565ac6da2347]|
 Status: Patch Available  (was: In Progress)

> The vector data type shouldn't support empty value
> --
>
> Key: CASSANDRA-18876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18876
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Vector Search
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As discussed on [the mail 
> list|https://lists.apache.org/thread/qq0jkm6rlkd2slfmhgz7om14tbpys891], the 
> vector data type shouldn't allow empty values.



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

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

[jira] [Created] (CASSANDRASC-75) Shaded Sidecar client should shade Jackson completely to avoid incompatibility issues

[Doug Rohrer (Jira)]

Doug Rohrer created CASSANDRASC-75:
--

 Summary: Shaded Sidecar client should shade Jackson completely to 
avoid incompatibility issues
 Key: CASSANDRASC-75
 URL: https://issues.apache.org/jira/browse/CASSANDRASC-75
 Project: Sidecar for Apache Cassandra
  Issue Type: Improvement
Reporter: Doug Rohrer


Before, we we shading almost all of Jackson but left the annotations 
unshaded/relocated. However, this causes problems in older Spark environments 
where the annotations in the class path don’t quite match what the other shaded 
parts of Jackson expect (missing classes being the most serious issue). This 
can cause the library to fail on certain Spark versions.
 
We should shade +all+ of Jackson in the shaded client to prevent these issues.



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

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

[jira] [Updated] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-18861:
--
Component/s: CQL/Interpreter
 (was: CQL/Semantics)

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Interpreter
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Low
> Fix For: 5.x
>
>




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

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

[jira] [Comment Edited] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-18861 at 9/22/23 1:57 PM:


{code}
15:52 $ ./bin/cqlsh 
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.2.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.7 | Native protocol v5]
Use HELP for help.
cqlsh> ELAPSED
Displaying elapsed time for each CQL query is currently disabled. Use ELAPSED 
ON to enable.
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
cqlsh> ELAPSED ON
Now Displaying elapsed time for each CQL query is enabled
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
(1ms elapsed)
cqlsh> ELAPSED OFF
Disabled Displaying elapsed time for each CQL query.
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
cqlsh> ELAPSED ON
Now Displaying elapsed time for each CQL query is enabled
cqlsh> CREATE KEYSPACE myks WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': 1};
(53ms elapsed)
cqlsh> DROP  KEYSPACE myks ;
(316ms elapsed)
cqlsh> 
{code}

I added ELAPSED ON / OFF command.

https://github.com/instaclustr/cassandra/commit/d2d8bad393201536818dacb864b64cc0093203ca

[~maoling] is this OK for you?

I would also wait for CASSANDRA-18547 Switches will get more love there and 
this will just go on top. 

cc [~bschoeni]


was (Author: smiklosovic):
{code}
15:52 $ ./bin/cqlsh 
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.2.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.7 | Native protocol v5]
Use HELP for help.
cqlsh> ELAPSED
Displaying elapsed time for each CQL query is currently disabled. Use ELAPSED 
ON to enable.
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
cqlsh> ELAPSED ON
Now Displaying elapsed time for each CQL query is enabled
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
(1ms elapsed)
cqlsh> ELAPSED OFF
Disabled Displaying elapsed time for each CQL query.
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
cqlsh> ELAPSED ON
Now Displaying elapsed time for each CQL query is enabled
cqlsh> CREATE KEYSPACE myks WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': 1};
(53ms elapsed)
cqlsh> DROP  KEYSPACE myks ;
(316ms elapsed)
cqlsh> 
{code}

I added EXPAND ON / OFF command.

https://github.com/instaclustr/cassandra/commit/d2d8bad393201536818dacb864b64cc0093203ca

[~maoling] is this OK for you?

I would also wait for CASSANDRA-18547 Switches will get more love there and 
this will just go on top. 

cc [~bschoeni]

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Low
> Fix For: 5.x
>
>




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

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

[jira] [Commented] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-18861:
--

I think you meant 'ELAPSED', but I like this solution over --debug or a rc 
directive.

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Low
> Fix For: 5.x
>
>




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

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

[jira] [Comment Edited] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-18861 at 9/22/23 1:57 PM:


{code}
15:52 $ ./bin/cqlsh 
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.2.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.7 | Native protocol v5]
Use HELP for help.
cqlsh> ELAPSED
Displaying elapsed time for each CQL query is currently disabled. Use ELAPSED 
ON to enable.
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
cqlsh> ELAPSED ON
Now Displaying elapsed time for each CQL query is enabled
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
(1ms elapsed)
cqlsh> ELAPSED OFF
Disabled Displaying elapsed time for each CQL query.
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
cqlsh> ELAPSED ON
Now Displaying elapsed time for each CQL query is enabled
cqlsh> CREATE KEYSPACE myks WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': 1};
(53ms elapsed)
cqlsh> DROP  KEYSPACE myks ;
(316ms elapsed)
cqlsh> 
{code}

I added EXPAND ON / OFF command.

https://github.com/instaclustr/cassandra/commit/d2d8bad393201536818dacb864b64cc0093203ca

[~maoling] is this OK for you?

I would also wait for CASSANDRA-18547 Switches will get more love there and 
this will just go on top. 

cc [~bschoeni]


was (Author: smiklosovic):
{code}
15:52 $ ./bin/cqlsh 
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.2.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.7 | Native protocol v5]
Use HELP for help.
cqlsh> ELAPSED
Displaying elapsed time for each CQL query is currently disabled. Use ELAPSED 
ON to enable.
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
cqlsh> ELAPSED ON
Now Displaying elapsed time for each CQL query is enabled
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
(1ms elapsed)
cqlsh> ELAPSED OFF
Disabled Displaying elapsed time for each CQL query.
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
cqlsh> ELAPSED ON
Now Displaying elapsed time for each CQL query is enabled
cqlsh> CREATE KEYSPACE myks WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': 1};
(53ms elapsed)
cqlsh> DROP  KEYSPACE myks ;
(316ms elapsed)
cqlsh> 
{code}

I added EXPAND ON / OFF command.

https://github.com/instaclustr/cassandra/commit/d2d8bad393201536818dacb864b64cc0093203ca

[~maoling] is this OK for you?

I would also wait for CASSANDRA-18547 Switches will get more love there and 
this will just go on top. 

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Low
> Fix For: 5.x
>
>




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

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

[jira] [Comment Edited] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-18861 at 9/22/23 1:56 PM:


{code}
15:52 $ ./bin/cqlsh 
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.2.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.7 | Native protocol v5]
Use HELP for help.
cqlsh> ELAPSED
Displaying elapsed time for each CQL query is currently disabled. Use ELAPSED 
ON to enable.
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
cqlsh> ELAPSED ON
Now Displaying elapsed time for each CQL query is enabled
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
(1ms elapsed)
cqlsh> ELAPSED OFF
Disabled Displaying elapsed time for each CQL query.
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
cqlsh> ELAPSED ON
Now Displaying elapsed time for each CQL query is enabled
cqlsh> CREATE KEYSPACE myks WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': 1};
(53ms elapsed)
cqlsh> DROP  KEYSPACE myks ;
(316ms elapsed)
cqlsh> 
{code}

I added EXPAND ON / OFF command.

https://github.com/instaclustr/cassandra/commit/d2d8bad393201536818dacb864b64cc0093203ca

[~maoling] is this OK for you?

I would also wait for CASSANDRA-18547 Switches will get more love there and 
this will just go on top. 


was (Author: smiklosovic):
{code}
15:52 $ ./bin/cqlsh 
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.2.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.7 | Native protocol v5]
Use HELP for help.
cqlsh> ELAPSED
Displaying elapsed time for each CQL query is currently disabled. Use ELAPSED 
ON to enable.
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
cqlsh> ELAPSED ON
Now Displaying elapsed time for each CQL query is enabled
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
(1ms elapsed)
cqlsh> ELAPSED OFF
Disabled Displaying elapsed time for each CQL query.
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
cqlsh> ELAPSED ON
Now Displaying elapsed time for each CQL query is enabled
cqlsh> CREATE KEYSPACE myks WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': 1};
(53ms elapsed)
cqlsh> DROP  KEYSPACE myks ;
(316ms elapsed)
cqlsh> 
{code}

I added EXPAND ON / OFF command.

https://github.com/instaclustr/cassandra/commit/d2d8bad393201536818dacb864b64cc0093203ca

[~maoling] is this OK for you?



> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Low
> Fix For: 5.x
>
>




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

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

[jira] [Updated] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-18861:
--
Test and Documentation Plan: CI
 Status: Patch Available  (was: In Progress)

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Low
> Fix For: 5.x
>
>




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

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

[jira] [Updated] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-18861:
--
Change Category: Operability
 Complexity: Low Hanging Fruit
   Priority: Low  (was: Normal)
 Status: Open  (was: Triage Needed)

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Low
> Fix For: 5.x
>
>




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

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

[jira] [Commented] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic commented on CASSANDRA-18861:
---

{code}
15:52 $ ./bin/cqlsh 
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.2.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.7 | Native protocol v5]
Use HELP for help.
cqlsh> ELAPSED
Displaying elapsed time for each CQL query is currently disabled. Use ELAPSED 
ON to enable.
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
cqlsh> ELAPSED ON
Now Displaying elapsed time for each CQL query is enabled
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
(1ms elapsed)
cqlsh> ELAPSED OFF
Disabled Displaying elapsed time for each CQL query.
cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
cqlsh> ELAPSED ON
Now Displaying elapsed time for each CQL query is enabled
cqlsh> CREATE KEYSPACE myks WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': 1};
(53ms elapsed)
cqlsh> DROP  KEYSPACE myks ;
(316ms elapsed)
cqlsh> 
{code}

I added EXPAND ON / OFF command.

https://github.com/instaclustr/cassandra/commit/d2d8bad393201536818dacb864b64cc0093203ca

[~maoling] is this OK for you?



> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>




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

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

[jira] [Updated] (CASSANDRA-18876) The vector data type shouldn't support empty value

[Jira]

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

Andres de la Peña updated CASSANDRA-18876:
--
   Complexity: Normal
Discovered By: Code Inspection
 Severity: Normal
   Status: Open  (was: Triage Needed)

> The vector data type shouldn't support empty value
> --
>
> Key: CASSANDRA-18876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18876
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Vector Search
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> As discussed on [the mail 
> list|https://lists.apache.org/thread/qq0jkm6rlkd2slfmhgz7om14tbpys891], the 
> vector data type shouldn't allow empty values.



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

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

[jira] [Updated] (CASSANDRA-18876) The vector data type shouldn't support empty value

[Jira]

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

Andres de la Peña updated CASSANDRA-18876:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: API / 
Semantic Definition(13162)

> The vector data type shouldn't support empty value
> --
>
> Key: CASSANDRA-18876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18876
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Vector Search
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> As discussed on [the mail 
> list|https://lists.apache.org/thread/qq0jkm6rlkd2slfmhgz7om14tbpys891], the 
> vector data type shouldn't allow empty values.



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

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

[jira] [Created] (CASSANDRA-18876) The vector data type shouldn't support empty value

[Jira]

Andres de la Peña created CASSANDRA-18876:
-

 Summary: The vector data type shouldn't support empty value
 Key: CASSANDRA-18876
 URL: https://issues.apache.org/jira/browse/CASSANDRA-18876
 Project: Cassandra
  Issue Type: Bug
  Components: Feature/Vector Search
Reporter: Andres de la Peña
Assignee: Andres de la Peña


As discussed on [the mail 
list|https://lists.apache.org/thread/qq0jkm6rlkd2slfmhgz7om14tbpys891], the 
vector data type shouldn't allow empty values.



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

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

[jira] [Commented] (CASSANDRA-18865) Enable unnecessary import from the same package check in IDEs

[Maxim Muzafarov (Jira)]

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

Maxim Muzafarov commented on CASSANDRA-18865:
-

Thank you, Stefan, I would also like to point out that the "Java | Imports | 
Unnecessary import from the 'java.lang' package" is also included in the 
RedundantImport checkstyle rule by default, so there should be no problems from 
that side.

> Enable unnecessary import from the same package check in IDEs
> -
>
> Key: CASSANDRA-18865
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18865
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: Screenshot 2023-09-22 at 13.13.23.png, Screenshot from 
> 2023-09-22 14-29-58.png, Screenshot from 2023-09-22 14-31-46.png, 
> image-2023-09-18-10-19-15-531.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, the unnecessary imports are disabled by the code style and are not 
> displayed by the IDE with the configuration stored in the project root. See 
> the screenshot below. 
> It seems the following needs to be done:
> - enable this check in the IDE configuration for all supported IDEs;
> - update the documentation;



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

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

[jira] [Commented] (CASSANDRA-18865) Enable unnecessary import from the same package check in IDEs

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic commented on CASSANDRA-18865:
---

 !Screenshot from 2023-09-22 14-29-58.png! 

after this patch it will be:

 !Screenshot from 2023-09-22 14-31-46.png! 

+1

> Enable unnecessary import from the same package check in IDEs
> -
>
> Key: CASSANDRA-18865
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18865
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: Screenshot 2023-09-22 at 13.13.23.png, Screenshot from 
> 2023-09-22 14-29-58.png, Screenshot from 2023-09-22 14-31-46.png, 
> image-2023-09-18-10-19-15-531.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, the unnecessary imports are disabled by the code style and are not 
> displayed by the IDE with the configuration stored in the project root. See 
> the screenshot below. 
> It seems the following needs to be done:
> - enable this check in the IDE configuration for all supported IDEs;
> - update the documentation;



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

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

[jira] [Updated] (CASSANDRA-18865) Enable unnecessary import from the same package check in IDEs

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-18865:
--
Status: Needs Committer  (was: Review In Progress)

> Enable unnecessary import from the same package check in IDEs
> -
>
> Key: CASSANDRA-18865
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18865
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: Screenshot 2023-09-22 at 13.13.23.png, Screenshot from 
> 2023-09-22 14-29-58.png, Screenshot from 2023-09-22 14-31-46.png, 
> image-2023-09-18-10-19-15-531.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, the unnecessary imports are disabled by the code style and are not 
> displayed by the IDE with the configuration stored in the project root. See 
> the screenshot below. 
> It seems the following needs to be done:
> - enable this check in the IDE configuration for all supported IDEs;
> - update the documentation;



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

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

[jira] [Updated] (CASSANDRA-18865) Enable unnecessary import from the same package check in IDEs

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-18865:
--
Attachment: Screenshot from 2023-09-22 14-31-46.png

> Enable unnecessary import from the same package check in IDEs
> -
>
> Key: CASSANDRA-18865
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18865
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: Screenshot 2023-09-22 at 13.13.23.png, Screenshot from 
> 2023-09-22 14-29-58.png, Screenshot from 2023-09-22 14-31-46.png, 
> image-2023-09-18-10-19-15-531.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, the unnecessary imports are disabled by the code style and are not 
> displayed by the IDE with the configuration stored in the project root. See 
> the screenshot below. 
> It seems the following needs to be done:
> - enable this check in the IDE configuration for all supported IDEs;
> - update the documentation;



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

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

[jira] [Updated] (CASSANDRA-18865) Enable unnecessary import from the same package check in IDEs

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-18865:
--
Attachment: Screenshot from 2023-09-22 14-29-58.png

> Enable unnecessary import from the same package check in IDEs
> -
>
> Key: CASSANDRA-18865
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18865
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: Screenshot 2023-09-22 at 13.13.23.png, Screenshot from 
> 2023-09-22 14-29-58.png, Screenshot from 2023-09-22 14-31-46.png, 
> image-2023-09-18-10-19-15-531.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, the unnecessary imports are disabled by the code style and are not 
> displayed by the IDE with the configuration stored in the project root. See 
> the screenshot below. 
> It seems the following needs to be done:
> - enable this check in the IDE configuration for all supported IDEs;
> - update the documentation;



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

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

[jira] [Updated] (CASSANDRA-18830) Set io.netty.transport.noNative to false for in-jvm dtests

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-18830:
--
  Fix Version/s: 5.0-alpha2
 5.1
 (was: 5.x)
Source Control Link: 
https://github.com/apache/cassandra/commit/9f4368cbb74d7163b6396eec3722b8c1d7fb55dc
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Set io.netty.transport.noNative to false for in-jvm dtests
> --
>
> Key: CASSANDRA-18830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18830
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-alpha2, 5.1
>
>
> This ticket was created as a reaction to (1).
> (1) https://lists.apache.org/thread/p42yksvo6t0dy67wmnl2bzpnggo9gpp9



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

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

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

[smiklosovic]

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

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

commit c5bb6725438997c0591acb31879e7f7ae54b757b
Merge: 970ec2d1db 9f4368cbb7
Author: Stefan Miklosovic 
AuthorDate: Fri Sep 22 14:05:25 2023 +0200

Merge branch 'cassandra-5.0' into trunk

 src/java/org/apache/cassandra/config/CassandraRelevantProperties.java   | 1 +
 .../org/apache/cassandra/distributed/impl/AbstractCluster.java  | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)


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

[cassandra] branch trunk updated (970ec2d1db -> c5bb672543)

[smiklosovic]

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

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


from 970ec2d1db Merge branch 'cassandra-5.0' into trunk
 add 9f4368cbb7 Set io.netty.transport.noNative to false for in-jvm dtests
 new c5bb672543 Merge branch 'cassandra-5.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:
 src/java/org/apache/cassandra/config/CassandraRelevantProperties.java   | 1 +
 .../org/apache/cassandra/distributed/impl/AbstractCluster.java  | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)


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

[cassandra] branch cassandra-5.0 updated (a23f4c0b15 -> 9f4368cbb7)

[smiklosovic]

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

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


from a23f4c0b15 Merge branch 'cassandra-4.1' into cassandra-5.0
 add 9f4368cbb7 Set io.netty.transport.noNative to false for in-jvm dtests

No new revisions were added by this update.

Summary of changes:
 src/java/org/apache/cassandra/config/CassandraRelevantProperties.java   | 1 +
 .../org/apache/cassandra/distributed/impl/AbstractCluster.java  | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)


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

[jira] [Updated] (CASSANDRA-18865) Enable unnecessary import from the same package check in IDEs

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-18865:
--
Status: Review In Progress  (was: Patch Available)

> Enable unnecessary import from the same package check in IDEs
> -
>
> Key: CASSANDRA-18865
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18865
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: Screenshot 2023-09-22 at 13.13.23.png, 
> image-2023-09-18-10-19-15-531.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, the unnecessary imports are disabled by the code style and are not 
> displayed by the IDE with the configuration stored in the project root. See 
> the screenshot below. 
> It seems the following needs to be done:
> - enable this check in the IDE configuration for all supported IDEs;
> - update the documentation;



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

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

[jira] [Commented] (CASSANDRA-16949) Fix flaky test org.apache.cassandra.transport.CQLConnectionTest

[Jacek Lewandowski (Jira)]

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

Jacek Lewandowski commented on CASSANDRA-16949:
---

Let's try that then, maybe it will help getting rid of this flakiness. Thanks 
for explanation [~samt]

> Fix flaky test org.apache.cassandra.transport.CQLConnectionTest
> ---
>
> Key: CASSANDRA-16949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16949
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: David Capwell
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1037/workflows/c728d370-49b9-41aa-bdfb-8c41cf0355d8/jobs/6577/parallel-runs/3
> {code}
> [junit-timeout] Testsuite: org.apache.cassandra.transport.CQLConnectionTest
> [junit-timeout] Testsuite: org.apache.cassandra.transport.CQLConnectionTest 
> Tests run: 9, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 12.926 sec
> [junit-timeout] 
> [junit-timeout] Testcase: 
> handleCorruptionOfLargeMessageFrame(org.apache.cassandra.transport.CQLConnectionTest):
>   FAILED
> [junit-timeout] null
> [junit-timeout] junit.framework.AssertionFailedError
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:484)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:446)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.handleCorruptionOfLargeMessageFrame(CQLConnectionTest.java:217)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] 
> [junit-timeout] 
> [junit-timeout] Testcase: 
> testNegativeEnvelopeBodySize(org.apache.cassandra.transport.CQLConnectionTest):
>  FAILED
> [junit-timeout] expected:<[]0L> but was:<[52424]0L>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<[]0L> but 
> was:<[52424]0L>
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest$AllocationObserver.lambda$verifier$0(CQLConnectionTest.java:850)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:492)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:446)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testNegativeEnvelopeBodySize(CQLConnectionTest.java:326)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] 
> [junit-timeout] 
> [junit-timeout] Testcase: 
> testUnrecoverableMessageDecodingErrors(org.apache.cassandra.transport.CQLConnectionTest):
>FAILED
> [junit-timeout] expected:<[]0L> but was:<[52424]0L>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<[]0L> but 
> was:<[52424]0L>
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest$AllocationObserver.lambda$verifier$0(CQLConnectionTest.java:850)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:492)
> [junit-timeout]   at 
> 

[jira] [Commented] (CASSANDRA-16949) Fix flaky test org.apache.cassandra.transport.CQLConnectionTest

[Sam Tunnicliffe (Jira)]

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

Sam Tunnicliffe commented on CASSANDRA-16949:
-

Yep, I think that would probably work just as welI (I don't think we had 
started using {{Awaitility}} when the test was first written, or maybe I just 
wasn't aware of it then).  

> Fix flaky test org.apache.cassandra.transport.CQLConnectionTest
> ---
>
> Key: CASSANDRA-16949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16949
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: David Capwell
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1037/workflows/c728d370-49b9-41aa-bdfb-8c41cf0355d8/jobs/6577/parallel-runs/3
> {code}
> [junit-timeout] Testsuite: org.apache.cassandra.transport.CQLConnectionTest
> [junit-timeout] Testsuite: org.apache.cassandra.transport.CQLConnectionTest 
> Tests run: 9, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 12.926 sec
> [junit-timeout] 
> [junit-timeout] Testcase: 
> handleCorruptionOfLargeMessageFrame(org.apache.cassandra.transport.CQLConnectionTest):
>   FAILED
> [junit-timeout] null
> [junit-timeout] junit.framework.AssertionFailedError
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:484)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:446)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.handleCorruptionOfLargeMessageFrame(CQLConnectionTest.java:217)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] 
> [junit-timeout] 
> [junit-timeout] Testcase: 
> testNegativeEnvelopeBodySize(org.apache.cassandra.transport.CQLConnectionTest):
>  FAILED
> [junit-timeout] expected:<[]0L> but was:<[52424]0L>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<[]0L> but 
> was:<[52424]0L>
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest$AllocationObserver.lambda$verifier$0(CQLConnectionTest.java:850)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:492)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:446)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testNegativeEnvelopeBodySize(CQLConnectionTest.java:326)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] 
> [junit-timeout] 
> [junit-timeout] Testcase: 
> testUnrecoverableMessageDecodingErrors(org.apache.cassandra.transport.CQLConnectionTest):
>FAILED
> [junit-timeout] expected:<[]0L> but was:<[52424]0L>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<[]0L> but 
> was:<[52424]0L>
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest$AllocationObserver.lambda$verifier$0(CQLConnectionTest.java:850)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:492)
> [junit-timeout]   at 
> 

[jira] [Comment Edited] (CASSANDRA-18865) Enable unnecessary import from the same package check in IDEs

[Maxim Muzafarov (Jira)]

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

Maxim Muzafarov edited comment on CASSANDRA-18865 at 9/22/23 11:31 AM:
---

[~smiklosovic], [~Bereng]

I've updated the configuration for IntelliJ IDEA in order to reflect redundant 
imports at the "error" level. I have also tried to do the same for NetBeans 
configuration that stored in the  {{ide/nbproject}} directory, but these 
options are only available at the global level and can't be saved at the 
per-project level.

 !Screenshot 2023-09-22 at 13.13.23.png|height=50%,width=50%! 

Can you take a look at these changes?




was (Author: mmuzaf):
[~smiklosovic], [~Bereng]

I've updated the configuration for IntelliJ IDEA in order to reflect redundant 
imports at the "error" level. I have also tried to do the same for NetBeans 
configuration that stored in the  {{ide/nbproject}} directory, but these 
options are only available at the global level and can't be saved at the 
per-project level.

 !Screenshot 2023-09-22 at 13.13.23.png! 

Can you take a look at these changes?



> Enable unnecessary import from the same package check in IDEs
> -
>
> Key: CASSANDRA-18865
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18865
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: Screenshot 2023-09-22 at 13.13.23.png, 
> image-2023-09-18-10-19-15-531.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, the unnecessary imports are disabled by the code style and are not 
> displayed by the IDE with the configuration stored in the project root. See 
> the screenshot below. 
> It seems the following needs to be done:
> - enable this check in the IDE configuration for all supported IDEs;
> - update the documentation;



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

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

[jira] [Updated] (CASSANDRA-18865) Enable unnecessary import from the same package check in IDEs

[Maxim Muzafarov (Jira)]

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

Maxim Muzafarov updated CASSANDRA-18865:

Test and Documentation Plan: Test manually by running ant 
generate-ide-files from scratch
 Status: Patch Available  (was: Open)

> Enable unnecessary import from the same package check in IDEs
> -
>
> Key: CASSANDRA-18865
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18865
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: Screenshot 2023-09-22 at 13.13.23.png, 
> image-2023-09-18-10-19-15-531.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, the unnecessary imports are disabled by the code style and are not 
> displayed by the IDE with the configuration stored in the project root. See 
> the screenshot below. 
> It seems the following needs to be done:
> - enable this check in the IDE configuration for all supported IDEs;
> - update the documentation;



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

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

[jira] [Commented] (CASSANDRA-18865) Enable unnecessary import from the same package check in IDEs

[Maxim Muzafarov (Jira)]

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

Maxim Muzafarov commented on CASSANDRA-18865:
-

[~smiklosovic], [~Bereng]

I've updated the configuration for IntelliJ IDEA in order to reflect redundant 
imports at the "error" level. I have also tried to do the same for NetBeans 
configuration that stored in the  {{ide/nbproject}} directory, but these 
options are only available at the global level and can't be saved at the 
per-project level.

 !Screenshot 2023-09-22 at 13.13.23.png! 

Can you take a look at these changes?



> Enable unnecessary import from the same package check in IDEs
> -
>
> Key: CASSANDRA-18865
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18865
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: Screenshot 2023-09-22 at 13.13.23.png, 
> image-2023-09-18-10-19-15-531.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, the unnecessary imports are disabled by the code style and are not 
> displayed by the IDE with the configuration stored in the project root. See 
> the screenshot below. 
> It seems the following needs to be done:
> - enable this check in the IDE configuration for all supported IDEs;
> - update the documentation;



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

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

[jira] [Updated] (CASSANDRA-18865) Enable unnecessary import from the same package check in IDEs

[Maxim Muzafarov (Jira)]

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

Maxim Muzafarov updated CASSANDRA-18865:

Attachment: Screenshot 2023-09-22 at 13.13.23.png

> Enable unnecessary import from the same package check in IDEs
> -
>
> Key: CASSANDRA-18865
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18865
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: Screenshot 2023-09-22 at 13.13.23.png, 
> image-2023-09-18-10-19-15-531.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, the unnecessary imports are disabled by the code style and are not 
> displayed by the IDE with the configuration stored in the project root. See 
> the screenshot below. 
> It seems the following needs to be done:
> - enable this check in the IDE configuration for all supported IDEs;
> - update the documentation;



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

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

[jira] [Updated] (CASSANDRA-18875) Upgrade the snakeyaml library version

[Brandon Williams (Jira)]

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

Brandon Williams updated CASSANDRA-18875:
-
Change Category: Semantic
 Complexity: Normal
Component/s: Local/Config
  Fix Version/s: 5.x
 Status: Open  (was: Triage Needed)

Sure, we can target trunk for this and take a look when it's done to consider 
5.0.

> Upgrade the snakeyaml library version
> -
>
> Key: CASSANDRA-18875
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18875
> Project: Cassandra
>  Issue Type: Task
>  Components: Local/Config
>Reporter: Jai Bheemsen Rao Dhanwada
>Priority: Normal
> Fix For: 5.x
>
>
> Apache cassandra uses 1.26 version of snakeyaml dependency and there are 
> several 
> [vulnerabilities|https://mvnrepository.com/artifact/org.yaml/snakeyaml/1.26#] 
> in this version that can be fixed by upgrading to 2.x version. I understand 
> that this is not security issue as cassandra already uses SafeConstructor and 
> is not a vulnerability under OWASP, so there are no plans to fix it as per  
> CASSANDRA-18122
>  
> Cassandra as a open source used and distributed by many enterprise customers 
> and also when downloading cassandra as tar and using it external scanners are 
> not aware of the implementation of SafeConstructor have no idea if it's 
> vulnerable or not. 
> Can we consider upgrading the version to 2.x in the next releases as 
> snakeyaml is not something that has a large dependency between the major and 
> minor versions. I am happy to open a PR for this. Please let me know your 
> thoughts on this.



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

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

[jira] [Commented] (CASSANDRA-16949) Fix flaky test org.apache.cassandra.transport.CQLConnectionTest

[Jacek Lewandowski (Jira)]

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

Jacek Lewandowski commented on CASSANDRA-16949:
---

I saw that comment, but I don't get it - is that {{await}} deliberately used as 
a sleep? We get a single message - can we just await even longer for a single 
message to arrive, then check what that message is (assert it is an error), and 
finally assert that the connection is closed in a {{Awaitlily}} loop?



> Fix flaky test org.apache.cassandra.transport.CQLConnectionTest
> ---
>
> Key: CASSANDRA-16949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16949
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: David Capwell
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1037/workflows/c728d370-49b9-41aa-bdfb-8c41cf0355d8/jobs/6577/parallel-runs/3
> {code}
> [junit-timeout] Testsuite: org.apache.cassandra.transport.CQLConnectionTest
> [junit-timeout] Testsuite: org.apache.cassandra.transport.CQLConnectionTest 
> Tests run: 9, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 12.926 sec
> [junit-timeout] 
> [junit-timeout] Testcase: 
> handleCorruptionOfLargeMessageFrame(org.apache.cassandra.transport.CQLConnectionTest):
>   FAILED
> [junit-timeout] null
> [junit-timeout] junit.framework.AssertionFailedError
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:484)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:446)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.handleCorruptionOfLargeMessageFrame(CQLConnectionTest.java:217)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] 
> [junit-timeout] 
> [junit-timeout] Testcase: 
> testNegativeEnvelopeBodySize(org.apache.cassandra.transport.CQLConnectionTest):
>  FAILED
> [junit-timeout] expected:<[]0L> but was:<[52424]0L>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<[]0L> but 
> was:<[52424]0L>
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest$AllocationObserver.lambda$verifier$0(CQLConnectionTest.java:850)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:492)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:446)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testNegativeEnvelopeBodySize(CQLConnectionTest.java:326)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] 
> [junit-timeout] 
> [junit-timeout] Testcase: 
> testUnrecoverableMessageDecodingErrors(org.apache.cassandra.transport.CQLConnectionTest):
>FAILED
> [junit-timeout] expected:<[]0L> but was:<[52424]0L>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<[]0L> but 
> was:<[52424]0L>
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest$AllocationObserver.lambda$verifier$0(CQLConnectionTest.java:850)
> [junit-timeout]   at 
> 

[jira] [Commented] (CASSANDRA-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-16999:
--

It will be included when it's solved.

> system.peers and system.peers_v2 do not contain the native_transport and/or 
> native_transport_port_ssl
> -
>
> Key: CASSANDRA-16999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16999
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Other
>Reporter: Steve Lacerda
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> system.peers_v2 includes a “native_port” but has no notion of 
> native_transport_port vs. native_transport_port_ssl.  Given this limited 
> information, there’s no clear way for the driver to know that different ports 
> are being used for SSL vs. non-SSL or which of those two ports is identified 
> by “native_port”.
>  
> The issue we ran into is that the java driver, since it has no notion of the 
> transport port SSL, the driver was only using the contact points and was not 
> load balancing.
>  
> The customer had both set:
> native_transport_port: 9042
> native_transport_port_ssl: 9142
>  
> They were attempting to connect to 9142, but that was failing. They could 
> only use 9042, and so their applications load balancing was failing. We found 
> that any node that was a contact point was connecting, but the other nodes 
> were never acting as coordinators.
>  
> There are still issues in the driver, for which I have created JAVA-2967, 
> which also refers to JAVA-2638, but the system.peers and system.peers_v2 
> tables should both contain native_transport_port and 
> native_transport_port_ssl.
>  
>  



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

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

[jira] [Commented] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-18861:
--

bq.  I think it makes sense to add. Not every time a user wants to have TRACING 
ON

That makes sense to me.



> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>




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

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

[jira] [Updated] (CASSANDRA-18830) Set io.netty.transport.noNative to false for in-jvm dtests

[Brandon Williams (Jira)]

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

Brandon Williams updated CASSANDRA-18830:
-
Status: Ready to Commit  (was: Review In Progress)

Can't argue with all that green CI, +1.

> Set io.netty.transport.noNative to false for in-jvm dtests
> --
>
> Key: CASSANDRA-18830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18830
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> This ticket was created as a reaction to (1).
> (1) https://lists.apache.org/thread/p42yksvo6t0dy67wmnl2bzpnggo9gpp9



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

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

[jira] [Updated] (CASSANDRA-18830) Set io.netty.transport.noNative to false for in-jvm dtests

[Brandon Williams (Jira)]

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

Brandon Williams updated CASSANDRA-18830:
-
Reviewers: Brandon Williams
   Status: Review In Progress  (was: Needs Committer)

> Set io.netty.transport.noNative to false for in-jvm dtests
> --
>
> Key: CASSANDRA-18830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18830
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> This ticket was created as a reaction to (1).
> (1) https://lists.apache.org/thread/p42yksvo6t0dy67wmnl2bzpnggo9gpp9



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

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

[jira] [Commented] (CASSANDRA-16949) Fix flaky test org.apache.cassandra.transport.CQLConnectionTest

[Sam Tunnicliffe (Jira)]

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

Sam Tunnicliffe commented on CASSANDRA-16949:
-

{quote}So, the first thing is that client.awaitResponses() awaits two messages 
and returns regardless of whether it is successful. Only one message is being 
sent - the error message, so the statement always times out. Irrespective of 
whether the server completes its job or not, we expect the client to be 
disconnected
{quote}
{noformat}
// Client needs to expect multiple responses or else awaitResponses returns
// after the error is first received and we race between handling the exception
// caused by remote disconnection and checking the connection status.{noformat}
i.e. if we don't coerce the client into additional waiting, the client may not 
have finished reacting to the server closing the connection before we check. An 
alternative would be to add a sleep between the two:

 
{code:java}
client.awaitResponses();
TimeUnit.SECONDS.sleep(1);
// Client has disconnected
assertFalse(client.isConnected());
{code}
{quote}we cannot guarantee the order of events will be retained on the client 
side. It is even more apparent in real deployments.
{quote}
I don't quite understand this. For sure we in a real deployment we cannot 
guarantee the order of events on the client side as we don't control the 
client, but we do in a test like this.
{quote}we should implement the test differently - assert that the message was 
sent rather than received
{quote}
If I remember right (but it's been a while, sorry), then the reasoning for 
doing it this way was mostly that it was easier/cleaner/less invasive to have a 
custom test client that we could inspect than to modify the server side in a 
way that is only really useful for testing.
{quote}we should expect some ack from the client before the server closes the 
connection
{quote}
Not really, the sending of the error response is really just an optimisation to 
try and avoid client side timeouts. It's especially optimistic given we have so 
little control over how disparate client implementations deal with 
errors/timeouts (and even stream tracking). The server doesn't need to wait for 
an ack before closing.

> Fix flaky test org.apache.cassandra.transport.CQLConnectionTest
> ---
>
> Key: CASSANDRA-16949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16949
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: David Capwell
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1037/workflows/c728d370-49b9-41aa-bdfb-8c41cf0355d8/jobs/6577/parallel-runs/3
> {code}
> [junit-timeout] Testsuite: org.apache.cassandra.transport.CQLConnectionTest
> [junit-timeout] Testsuite: org.apache.cassandra.transport.CQLConnectionTest 
> Tests run: 9, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 12.926 sec
> [junit-timeout] 
> [junit-timeout] Testcase: 
> handleCorruptionOfLargeMessageFrame(org.apache.cassandra.transport.CQLConnectionTest):
>   FAILED
> [junit-timeout] null
> [junit-timeout] junit.framework.AssertionFailedError
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:484)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:446)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.handleCorruptionOfLargeMessageFrame(CQLConnectionTest.java:217)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] 
> [junit-timeout] 
> [junit-timeout] Testcase: 
> testNegativeEnvelopeBodySize(org.apache.cassandra.transport.CQLConnectionTest):
>  FAILED
> [junit-timeout] expected:<[]0L> but was:<[52424]0L>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<[]0L> but 
> was:<[52424]0L>
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [junit-timeout]   at 
> 

[cassandra-website] branch asf-staging updated (3258fdf8b -> b345dbfac)

[git-site-role]

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

git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git


 discard 3258fdf8b generate docs for bc8bfc13
 new b345dbfac generate docs for bc8bfc13

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (3258fdf8b)
\
 N -- N -- N   refs/heads/asf-staging (b345dbfac)

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

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

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


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


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

[jira] [Comment Edited] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-18861 at 9/22/23 9:11 AM:


This patch prints elapsed times to everything (1) when --debug is specified 
with cqlsh:

{code:java}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;
(3ms elapsed)
cassandra@cqlsh> DROP KEYSPACE  ks2 ;
(525ms elapsed)
cassandra@cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
(4ms elapsed)
{code}
I would personally hide this behind a flag in cqlshrc file. It could be also 
activated automatically if cqlsh is executed with "--debug" flag  (which 
already exists) as the patch below shows

(1) 
[https://github.com/instaclustr/cassandra/commit/4c3ec54ddefb34f6a5fcb6df0ad45c4ac95bdedb]


was (Author: smiklosovic):
This patch prints elapsed times to everything (1) when --debug is specified 
with cqlsh:

{code:java}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;
(3ms elapsed)
cassandra@cqlsh> DROP KEYSPACE  ks2 ;
(525ms elapsed)
cassandra@cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
(4ms elapsed)
{code}
I would personally hide this behind a flag in cqlshrc option. It could be also 
activated automatically if cqlsh is executed with "--debug" flag  (which 
already exists) as the patch below shows

(1) 
[https://github.com/instaclustr/cassandra/commit/4c3ec54ddefb34f6a5fcb6df0ad45c4ac95bdedb]

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>




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

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

[jira] [Comment Edited] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-18861 at 9/22/23 9:10 AM:


This patch prints elapsed times to everything (1) when --debug is specified 
with cqlsh:

{code:java}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;
(3ms elapsed)
cassandra@cqlsh> DROP KEYSPACE  ks2 ;
(525ms elapsed)
cassandra@cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
(4ms elapsed)
{code}
I would personally hide this behind a flag in cqlshrc option. It could be also 
activated automatically if cqlsh is executed with "--debug" flag  (which 
already exists) as the patch below shows

(1) 
[https://github.com/instaclustr/cassandra/commit/4c3ec54ddefb34f6a5fcb6df0ad45c4ac95bdedb]


was (Author: smiklosovic):
This patch prints elapsed times to everything (1)

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;
(3ms elapsed)
cassandra@cqlsh> DROP KEYSPACE  ks2 ;
(525ms elapsed)
cassandra@cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
(4ms elapsed)
{code}

I would personally hide this behind a flag in cqlshrc option. It could be also 
activated automatically if cqlsh is executed with "--debug" flag (which already 
exists).

(1) 
https://github.com/instaclustr/cassandra/commit/c4911edeaa769849e1f1dff8dcd33a6784c26310

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>




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

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

[jira] [Comment Edited] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-18861 at 9/22/23 9:03 AM:


This patch prints elapsed times to everything (1)

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;
(3ms elapsed)
cassandra@cqlsh> DROP KEYSPACE  ks2 ;
(525ms elapsed)
cassandra@cqlsh> SELECT * from system_views.queries ;

 thread_id | queued_micros | running_micros | task
---+---++--

(0 rows)
(4ms elapsed)
{code}

I would personally hide this behind a flag in cqlshrc option. It could be also 
activated automatically if cqlsh is executed with "--debug" flag (which already 
exists).

(1) 
https://github.com/instaclustr/cassandra/commit/c4911edeaa769849e1f1dff8dcd33a6784c26310


was (Author: smiklosovic):
This patch prints elapsed times to everything (1)

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;
(3ms elapsed)
cassandra@cqlsh> DROP KEYSPACE  ks2 ;
(525ms elapsed)
{code}

I would personally hide this behind a flag in cqlshrc option. It could be also 
activated automatically if cqlsh is executed with "--debug" flag (which already 
exists).

(1) 
https://github.com/instaclustr/cassandra/commit/c4911edeaa769849e1f1dff8dcd33a6784c26310

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>




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

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

[jira] [Comment Edited] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-18861 at 9/22/23 9:02 AM:


This patch prints elapsed times to everything (1)

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;
(3ms elapsed)
cassandra@cqlsh> DROP KEYSPACE  ks2 ;
(525ms elapsed)
{code}

I would personally hide this behind a flag in cqlshrc option. It could be also 
activated automatically if cqlsh is executed with "--debug" flag (which already 
exists).

(1) 
https://github.com/instaclustr/cassandra/commit/c4911edeaa769849e1f1dff8dcd33a6784c26310


was (Author: smiklosovic):
This patch prints elapsed times to everything (1)

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;
(3ms elapsed)
cassandra@cqlsh> DROP KEYSPACE  ks2 ;
(525ms elapsed)
{code}

I would personally hide this behind a flag in cqlshrc option. It could be also 
activated automatically if cqlsh is executed with "--debug" flag (which already 
exists).

(1) 
https://github.com/instaclustr/cassandra/commit/5e8b9d20cc8ed1fe75e3b4d242372e561153de9a

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>




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

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

[jira] [Comment Edited] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-18861 at 9/22/23 8:55 AM:


This patch prints elapsed times to everything (1)

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;
(3ms elapsed)
cassandra@cqlsh> DROP KEYSPACE  ks2 ;
(525ms elapsed)
{code}

I would personally hide this behind a flag in cqlshrc option. It could be also 
activated automatically if cqlsh is executed with "--debug" flag (which already 
exists).

(1) 
https://github.com/instaclustr/cassandra/commit/5e8b9d20cc8ed1fe75e3b4d242372e561153de9a


was (Author: smiklosovic):
This patch prints elapsed times to everything (1)

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;
(3ms elapsed)
cassandra@cqlsh> DROP KEYSPACE  ks2 ;
(525ms elapsed)
{code}

I would personally hide this behind a flag in cqlsh. It could be also activated 
automatically if cqlsh is executed with "--debug" flag (which already exists).

(1) 
https://github.com/instaclustr/cassandra/commit/5e8b9d20cc8ed1fe75e3b4d242372e561153de9a

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>




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

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

[jira] [Comment Edited] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-18861 at 9/22/23 8:54 AM:


This patch prints elapsed times to everything (1)

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;
(3ms elapsed)
cassandra@cqlsh> DROP KEYSPACE  ks2 ;
(525ms elapsed)
{code}

I would personally hide this behind a flag in cqlsh. It could be also activated 
automatically if cqlsh is executed with "--debug" flag (which already exists).

(1) 
https://github.com/instaclustr/cassandra/commit/5e8b9d20cc8ed1fe75e3b4d242372e561153de9a


was (Author: smiklosovic):
This patch prints elapsed timestamps to everything (1)

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;
(3ms elapsed)
cassandra@cqlsh> DROP KEYSPACE  ks2 ;
(525ms elapsed)
{code}

I would personally hide this behind a flag in cqlsh. It could be also activated 
automatically if cqlsh is executed with "--debug" flag (which already exists).

(1) 
https://github.com/instaclustr/cassandra/commit/5e8b9d20cc8ed1fe75e3b4d242372e561153de9a

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>




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

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

[jira] [Commented] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic commented on CASSANDRA-18861:
---

This patch prints elapsed timestamps to everything (1)

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;
(3ms elapsed)
cassandra@cqlsh> DROP KEYSPACE  ks2 ;
(525ms elapsed)
{code}

I would personally hide this behind a flag in cqlsh. It could be also activated 
automatically if cqlsh is executed with "--debug" flag (which already exists).

(1) 
https://github.com/instaclustr/cassandra/commit/5e8b9d20cc8ed1fe75e3b4d242372e561153de9a

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>




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

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

[jira] [Assigned] (CASSANDRA-16949) Fix flaky test org.apache.cassandra.transport.CQLConnectionTest

[Jacek Lewandowski (Jira)]

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

Jacek Lewandowski reassigned CASSANDRA-16949:
-

Assignee: Jacek Lewandowski

> Fix flaky test org.apache.cassandra.transport.CQLConnectionTest
> ---
>
> Key: CASSANDRA-16949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16949
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: David Capwell
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1037/workflows/c728d370-49b9-41aa-bdfb-8c41cf0355d8/jobs/6577/parallel-runs/3
> {code}
> [junit-timeout] Testsuite: org.apache.cassandra.transport.CQLConnectionTest
> [junit-timeout] Testsuite: org.apache.cassandra.transport.CQLConnectionTest 
> Tests run: 9, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 12.926 sec
> [junit-timeout] 
> [junit-timeout] Testcase: 
> handleCorruptionOfLargeMessageFrame(org.apache.cassandra.transport.CQLConnectionTest):
>   FAILED
> [junit-timeout] null
> [junit-timeout] junit.framework.AssertionFailedError
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:484)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:446)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.handleCorruptionOfLargeMessageFrame(CQLConnectionTest.java:217)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] 
> [junit-timeout] 
> [junit-timeout] Testcase: 
> testNegativeEnvelopeBodySize(org.apache.cassandra.transport.CQLConnectionTest):
>  FAILED
> [junit-timeout] expected:<[]0L> but was:<[52424]0L>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<[]0L> but 
> was:<[52424]0L>
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest$AllocationObserver.lambda$verifier$0(CQLConnectionTest.java:850)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:492)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:446)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testNegativeEnvelopeBodySize(CQLConnectionTest.java:326)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] 
> [junit-timeout] 
> [junit-timeout] Testcase: 
> testUnrecoverableMessageDecodingErrors(org.apache.cassandra.transport.CQLConnectionTest):
>FAILED
> [junit-timeout] expected:<[]0L> but was:<[52424]0L>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<[]0L> but 
> was:<[52424]0L>
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest$AllocationObserver.lambda$verifier$0(CQLConnectionTest.java:850)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:492)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testUnrecoverableMessageDecodingErrors(CQLConnectionTest.java:392)
> [junit-timeout]   at 
> 

[jira] [Commented] (CASSANDRA-16949) Fix flaky test org.apache.cassandra.transport.CQLConnectionTest

[Jacek Lewandowski (Jira)]

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

Jacek Lewandowski commented on CASSANDRA-16949:
---

This test is weird. 

Looking at the script:
{code:java}
client.connect(address, port);
assertTrue(client.isConnected());

// Only install the transform after protocol negotiation is complete
controller.withPayloadTransform(transform);

for (int i = 0; i < messageCount; i++)
client.send(envelopeProvider.apply(i));

client.awaitResponses();
// Client has disconnected
assertFalse(client.isConnected());
// But before it did, it sent an error response
Envelope received = client.inboundMessages.poll();
assertNotNull(received); // <--- ERROR
Message.Response response = 
Message.responseDecoder().decode(client.channel, received);
{code}

We can see that we first wait for the error message, then expect the connection 
to be closed, and eventually, we read the message asserting its content. 

So, the first thing is that {{client.awaitResponses()}} awaits two messages and 
returns regardless of whether it is successful. Only one message is being sent 
- the error message, so the statement always times out. Irrespective of whether 
the server completes its job or not, we expect the client to be disconnected - 
it is enough to add a small sleep in the {{ExceptionHandlers}} before the 
connection should be closed and the test starts to fail at 
{{assertFalse(client.isConnected())}}. Eventually - we test it with networking, 
and since we only make sure that the error message is sent before the 
connection is closed, we cannot guarantee the order of events will be retained 
on the client side. It is even more apparent in real deployments. 

So, if I'm not wrong, the expectation that the client receives and processes 
the error message before closing the connection without expecting any ack from 
the client does not make sense. If we want to verify that such a message is 
sent before closing the connection on the server side, we should implement the 
test differently - assert that the message was sent rather than received. 
Otherwise, if we expect the client to process the error message before closing 
the connection, we should expect some ack from the client before the server 
closes the connection.

[~dcapwell] wdyt ?

> Fix flaky test org.apache.cassandra.transport.CQLConnectionTest
> ---
>
> Key: CASSANDRA-16949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16949
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 5.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1037/workflows/c728d370-49b9-41aa-bdfb-8c41cf0355d8/jobs/6577/parallel-runs/3
> {code}
> [junit-timeout] Testsuite: org.apache.cassandra.transport.CQLConnectionTest
> [junit-timeout] Testsuite: org.apache.cassandra.transport.CQLConnectionTest 
> Tests run: 9, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 12.926 sec
> [junit-timeout] 
> [junit-timeout] Testcase: 
> handleCorruptionOfLargeMessageFrame(org.apache.cassandra.transport.CQLConnectionTest):
>   FAILED
> [junit-timeout] null
> [junit-timeout] junit.framework.AssertionFailedError
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:484)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:446)
> [junit-timeout]   at 
> org.apache.cassandra.transport.CQLConnectionTest.handleCorruptionOfLargeMessageFrame(CQLConnectionTest.java:217)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] 
> [junit-timeout] 
> [junit-timeout] Testcase: 
> testNegativeEnvelopeBodySize(org.apache.cassandra.transport.CQLConnectionTest):
>  FAILED
> [junit-timeout] expected:<[]0L> but was:<[52424]0L>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<[]0L> but 
> was:<[52424]0L>
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
> [junit-timeout]   at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 

[jira] [Comment Edited] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-18861 at 9/22/23 8:31 AM:


examples of the output:

{code}
cassandra@cqlsh> ALTER TABLE myks.mytb ADD age int;
{code}

{code}
cassandra@cqlsh> list USERS ;

 name  | super | datacenters
---+---+-
 cassandra |  True | ALL

(1 rows, 12ms elapsed)
{code}

{code}
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1;
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1 IF exists;

 [applied]
---
  True

(36ms elapsed)
{code}

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); APPLY BATCH;
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS ; APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(8ms elapsed)
{code}

It is interesting to see that elapsed time is written only for CAS statements. 
So if I do this when one statement is CAS and another is not:

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS; insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(9ms elapsed)
{code}

It will basically take into account not the time of whole batch but only of 
statements which are CAS. So it will leave out another one from the elapsed 
time computation.

Or am I getting it wrong?

That is because of this (1). Basically, we will ever have that elapsed timeout 
displayed only in case a statement returns some rows back to client and we 
completely leave out all other statements which is quite unfortunate. 

Maybe it would be better to hide this behind a flag in cqlshrc and once turned 
on (default turned off), it would write the elapsed time to absolutely 
everything? I mean ... we either print it _everywhere_ if a user asked for it 
or nowhere. I dont see a reason why it should be displayed only for statements 
returning a row. 

For example, if I do "DROP KEYSPACE mykeyspace", it will take way more than a 
couple of milliseconds. That is because dropping of a keyspace seems to be 
synchronous operation from CQLSH perspective. Even I do not know how long that 
statement took exactly, one can just feel from the CQLSH as he is executing 
that statement that it takes way longer than "3ms".

(1) 
https://github.com/apache/cassandra/blob/a4e5e0bd2e5bf80275443bcefc72cebad5ea10fc/pylib/cqlshlib/cqlshmain.py#L996-L1006


was (Author: smiklosovic):
examples of the output:

{code}
cassandra@cqlsh> ALTER TABLE myks.mytb ADD age int;
{code}

{code}
cassandra@cqlsh> list USERS ;

 name  | super | datacenters
---+---+-
 cassandra |  True | ALL

(1 rows, 12ms elapsed)
{code}

{code}
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1;
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1 IF exists;

 [applied]
---
  True

(36ms elapsed)
{code}

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); APPLY BATCH;
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS ; APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(8ms elapsed)
{code}

It is interesting to see that elapsed time is written only for CAS statements. 
So if I do this when one statement is CAS and another is not:

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS; insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(9ms elapsed)
{code}

It will basically take into account not the time of whole batch but only of 
statements which are CAS. So it will leave out another one from the elapsed 
time computation.

Or am I getting it wrong?

That is because of this (1). Basically, we will ever have that elapsed timeout 
displayed only in case a statement returns some rows back to client and we 
completely leave out all other statements which is quite unfortunate. 

Maybe it would be better to hide this behind a flag in cqlshrc and once turned 
on (default turned off), it would write the elapsed time to absolutely 
everything? I mean ... we either print it _everywhere_ if a user asked for it 
or nowhere. I dont see a reason why it should be displayed only for statements 
returning a row. 

(1) 
https://github.com/apache/cassandra/blob/a4e5e0bd2e5bf80275443bcefc72cebad5ea10fc/pylib/cqlshlib/cqlshmain.py#L996-L1006

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: 

[cassandra-website] branch asf-staging updated (49f23ea8e -> 3258fdf8b)

[git-site-role]

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

git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git


 discard 49f23ea8e generate docs for bc8bfc13
 new 3258fdf8b generate docs for bc8bfc13

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (49f23ea8e)
\
 N -- N -- N   refs/heads/asf-staging (3258fdf8b)

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

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

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


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


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

[jira] [Comment Edited] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-18861 at 9/22/23 8:26 AM:


examples of the output:

{code}
cassandra@cqlsh> ALTER TABLE myks.mytb ADD age int;
{code}

{code}
cassandra@cqlsh> list USERS ;

 name  | super | datacenters
---+---+-
 cassandra |  True | ALL

(1 rows, 12ms elapsed)
{code}

{code}
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1;
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1 IF exists;

 [applied]
---
  True

(36ms elapsed)
{code}

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); APPLY BATCH;
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS ; APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(8ms elapsed)
{code}

It is interesting to see that elapsed time is written only for CAS statements. 
So if I do this when one statement is CAS and another is not:

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS; insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(9ms elapsed)
{code}

It will basically take into account not the time of whole batch but only of 
statements which are CAS. So it will leave out another one from the elapsed 
time computation.

Or am I getting it wrong?

That is because of this (1). Basically, we will ever have that elapsed timeout 
displayed only in case a statement returns some rows back to client and we 
completely leave out all other statements which is quite unfortunate. 

Maybe it would be better to hide this behind a flag in cqlshrc and once turned 
on (default turned off), it would write the elapsed time to absolutely 
everything? I mean ... we either print it _everywhere_ if a user asked for it 
or nowhere. I dont see a reason why it should be displayed only for statements 
returning a row. 

(1) 
https://github.com/apache/cassandra/blob/a4e5e0bd2e5bf80275443bcefc72cebad5ea10fc/pylib/cqlshlib/cqlshmain.py#L996-L1006


was (Author: smiklosovic):
examples of the output:

{code}
cassandra@cqlsh> ALTER TABLE myks.mytb ADD age int;
{code}

{code}
cassandra@cqlsh> list USERS ;

 name  | super | datacenters
---+---+-
 cassandra |  True | ALL

(1 rows, 12ms elapsed)
{code}

{code}
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1;
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1 IF exists;

 [applied]
---
  True

(36ms elapsed)
{code}

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); APPLY BATCH;
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS ; APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(8ms elapsed)
{code}

It is interesting to see that elapsed time is written only for CAS statements. 
So if I do this when one statement is CAS and another is not:

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS; insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(9ms elapsed)
{code}

It will basically take into account not the time of whole batch but only of 
statements which are CAS. So it will leave out another one from the elapsed 
time computation.

That is because of this (1). Basically, we will ever have that elapsed timeout 
displayed only in case a statement returns some rows back to client and we 
completely leave out all other statements which is quite unfortunate. 

Maybe it would be better to hide this behind a flag in cqlshrc and once turned 
on (default turned off), it would write the elapsed time to absolutely 
everything? I mean ... we either print it _everywhere_ if a user asked for it 
or nowhere. I dont see a reason why it should be displayed only for statements 
returning a row. 

(1) 
https://github.com/apache/cassandra/blob/a4e5e0bd2e5bf80275443bcefc72cebad5ea10fc/pylib/cqlshlib/cqlshmain.py#L996-L1006

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>




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

[jira] [Comment Edited] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-18861 at 9/22/23 8:25 AM:


examples of the output:

{code}
cassandra@cqlsh> ALTER TABLE myks.mytb ADD age int;
{code}

{code}
cassandra@cqlsh> list USERS ;

 name  | super | datacenters
---+---+-
 cassandra |  True | ALL

(1 rows, 12ms elapsed)
{code}

{code}
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1;
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1 IF exists;

 [applied]
---
  True

(36ms elapsed)
{code}

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); APPLY BATCH;
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS ; APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(8ms elapsed)
{code}

It is interesting to see that elapsed time is written only for CAS statements. 
So if I do this when one statement is CAS and another is not:

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS; insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(9ms elapsed)
{code}

It will basically take into account not the time of whole batch but only of 
statements which are CAS. So it will leave out another one from the elapsed 
time computation.

That is because of this (1). Basically, we will ever have that elapsed timeout 
displayed only in case a statement returns some rows back to client and we 
completely leave out all other statements which is quite unfortunate. 

Maybe it would be better to hide this behind a flag in cqlshrc and once turned 
on (default turned off), it would write the elapsed time to absolutely 
everything? I mean ... we either print it _everywhere_ if a user asked for it 
or nowhere. I dont see a reason why it should be displayed only for statements 
returning a row. 

(1) 
https://github.com/apache/cassandra/blob/a4e5e0bd2e5bf80275443bcefc72cebad5ea10fc/pylib/cqlshlib/cqlshmain.py#L996-L1006


was (Author: smiklosovic):
examples of the output:

{code}
cassandra@cqlsh> list USERS ;

 name  | super | datacenters
---+---+-
 cassandra |  True | ALL

(1 rows, 12ms elapsed)
{code}

{code}
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1;
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1 IF exists;

 [applied]
---
  True

(36ms elapsed)
{code}

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); APPLY BATCH;
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS ; APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(8ms elapsed)
{code}

It is interesting to see that elapsed time is written only for CAS statements. 
So if I do this when one statement is CAS and another is not:

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS; insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(9ms elapsed)
{code}

It will basically take into account not the time of whole batch but only of 
statements which are CAS. So it will leave out another one from the elapsed 
time computation.

That is because of this (1). Basically, we will ever have that elapsed timeout 
displayed only in case a statement returns some rows back to client and we 
completely leave out all other statements which is quite unfortunate. 

Maybe it would be better to hide this behind a flag in cqlshrc and once turned 
on (default turned off), it would write the elapsed time to absolutely 
everything? 

(1) 
https://github.com/apache/cassandra/blob/a4e5e0bd2e5bf80275443bcefc72cebad5ea10fc/pylib/cqlshlib/cqlshmain.py#L996-L1006

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>




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

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

[jira] [Comment Edited] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-18861 at 9/22/23 8:22 AM:


examples of the output:

{code}
cassandra@cqlsh> list USERS ;

 name  | super | datacenters
---+---+-
 cassandra |  True | ALL

(1 rows, 12ms elapsed)
{code}

{code}
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1;
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1 IF exists;

 [applied]
---
  True

(36ms elapsed)
{code}

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); APPLY BATCH;
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS ; APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(8ms elapsed)
{code}

It is interesting to see that elapsed time is written only for CAS statements. 
So if I do this when one statement is CAS and another is not:

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS; insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(9ms elapsed)
{code}

It will basically take into account not the time of whole batch but only of 
statements which are CAS. So it will leave out another one from the elapsed 
time computation.

That is because of this (1). Basically, we will ever have that elapsed timeout 
displayed only in case a statement returns some rows back to client and we 
completely leave out all other statements which is quite unfortunate. 

Maybe it would be better to hide this behind a flag in cqlshrc and once turned 
on (default turned off), it would write the elapsed time to absolutely 
everything? 

(1) 
https://github.com/apache/cassandra/blob/a4e5e0bd2e5bf80275443bcefc72cebad5ea10fc/pylib/cqlshlib/cqlshmain.py#L996-L1006


was (Author: smiklosovic):
examples of the output:

{code}
cassandra@cqlsh> list USERS ;

 name  | super | datacenters
---+---+-
 cassandra |  True | ALL

(1 rows, 12ms elapsed)
{code}

{code}
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1;
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1 IF exists;

 [applied]
---
  True

(36ms elapsed)
{code}

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); APPLY BATCH;
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS ; APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(8ms elapsed)
{code}

It is interesting to see that elapsed time is written only for CAS statements. 
So if I do this when one statement is CAS and another is not:

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS; insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(9ms elapsed)
{code}

It will basically take into account not the time of whole batch but only of 
statements which are CAS. So it will leave out another one from the elapsed 
time computation.

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>




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

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

[jira] [Commented] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic commented on CASSANDRA-18861:
---

examples of the output:

{code}
cassandra@cqlsh> list USERS ;

 name  | super | datacenters
---+---+-
 cassandra |  True | ALL

(1 rows, 12ms elapsed)
{code}

{code}
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1;
cassandra@cqlsh> update myks.mytb SET name = 'stefan' WHERE id = 1 IF exists;

 [applied]
---
  True

(36ms elapsed)
{code}

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 
'joe'); APPLY BATCH;
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS ; APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(8ms elapsed)
{code}

It is interesting to see that elapsed time is written only for CAS statements. 
So if I do this when one statement is CAS and another is not:

{code}
cassandra@cqlsh> BEGIN BATCH insert into myks.mytb (id, name) VALUES (1, 'joe') 
IF NOT EXISTS; insert into myks.mytb (id, name) VALUES (1, 'joe'); APPLY BATCH;

 [applied] | id | name
---++--
 False |  1 |  joe

(9ms elapsed)
{code}

It will basically take into account not the time of whole batch but only of 
statements which are CAS. So it will leave out another one from the elapsed 
time computation.

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>




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

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

[jira] [Commented] (CASSANDRA-18861) add time elapsed for simple CQL statement in the cql shell

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic commented on CASSANDRA-18861:
---

[~brandon.williams] what do you think about this? (1)

Seeing an example in the PR, I think it makes sense to add. Not every time a 
user wants to have TRACING ON and this gives a quick feedback how long it takes 
and it does not pollute the output a lot / feels natural. I am wondering if we 
want to hide it behind some flag but I can not think of a scenario when a user 
explicitly does not want to see that. 

(1) https://github.com/apache/cassandra/pull/2698#issue-1900888369

> add time elapsed for simple CQL statement in the cql shell
> --
>
> Key: CASSANDRA-18861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>




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

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

[jira] [Commented] (CASSANDRA-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl

[Ahmed ELJAMI (Jira)]

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

Ahmed ELJAMI commented on CASSANDRA-16999:
--

Hi,

Would this fix be included in the next release of Cassandra 4.0.12 ?

Greetings,

 

> system.peers and system.peers_v2 do not contain the native_transport and/or 
> native_transport_port_ssl
> -
>
> Key: CASSANDRA-16999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16999
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Other
>Reporter: Steve Lacerda
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> system.peers_v2 includes a “native_port” but has no notion of 
> native_transport_port vs. native_transport_port_ssl.  Given this limited 
> information, there’s no clear way for the driver to know that different ports 
> are being used for SSL vs. non-SSL or which of those two ports is identified 
> by “native_port”.
>  
> The issue we ran into is that the java driver, since it has no notion of the 
> transport port SSL, the driver was only using the contact points and was not 
> load balancing.
>  
> The customer had both set:
> native_transport_port: 9042
> native_transport_port_ssl: 9142
>  
> They were attempting to connect to 9142, but that was failing. They could 
> only use 9042, and so their applications load balancing was failing. We found 
> that any node that was a contact point was connecting, but the other nodes 
> were never acting as coordinators.
>  
> There are still issues in the driver, for which I have created JAVA-2967, 
> which also refers to JAVA-2638, but the system.peers and system.peers_v2 
> tables should both contain native_transport_port and 
> native_transport_port_ssl.
>  
>  



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

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

[jira] [Commented] (CASSANDRA-18830) Set io.netty.transport.noNative to false for in-jvm dtests

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic commented on CASSANDRA-18830:
---

[~brandon.williams] this is quite easy one. There is also ML thread linked for 
the reference. It should go to 5.0 as well as to trunk. Patch is for trunk only 
but I do not expect it to behave differently from 5.0 as 5.0 is basically a 
subset of trunk. 

> Set io.netty.transport.noNative to false for in-jvm dtests
> --
>
> Key: CASSANDRA-18830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18830
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> This ticket was created as a reaction to (1).
> (1) https://lists.apache.org/thread/p42yksvo6t0dy67wmnl2bzpnggo9gpp9



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

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

[jira] [Commented] (CASSANDRA-18161) Test Failure: org.apache.cassandra.transport.CQLConnectionTest.handleCorruptionOfLargeMessageFrame

[Jacek Lewandowski (Jira)]

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

Jacek Lewandowski commented on CASSANDRA-18161:
---

https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/903/workflows/0dceaede-a0ee-4bbf-af12-d97ad99e6bd1/jobs/30926/tests

> Test Failure: 
> org.apache.cassandra.transport.CQLConnectionTest.handleCorruptionOfLargeMessageFrame
> --
>
> Key: CASSANDRA-18161
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18161
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> Flaky.
> {noformat}
> junit.framework.AssertionFailedError
>   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:491)
>   at 
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:450)
>   at 
> org.apache.cassandra.transport.CQLConnectionTest.handleCorruptionOfLargeMessageFrame(CQLConnectionTest.java:221)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}



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

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

[jira] [Commented] (CASSANDRA-18856) Test failure: rebuild_test.TestRebuild.test_resumable_rebuild

[Berenguer Blasi (Jira)]

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

Berenguer Blasi commented on CASSANDRA-18856:
-

Seen 
[here|https://app.circleci.com/pipelines/github/bereng/cassandra/1077/workflows/1fbaf716-e378-494d-900e-7ca1e12cc621/jobs/29640/tests#failed-test-0]

> Test failure: rebuild_test.TestRebuild.test_resumable_rebuild
> -
>
> Key: CASSANDRA-18856
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18856
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Streaming
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> https://app.circleci.com/pipelines/github/driftx/cassandra/1294/workflows/04464235-3bcf-433e-ae81-206aa2c9c874/jobs/54042/tests
> {quote}
> failed on teardown with "Unexpected error found in node logs (see stdout for 
> full details). Errors: [[node3] 'ERROR 
> [Stream-Deserializer-/127.0.0.2:7000-d94b6b54] 2023-09-15 16:04:30,685 
> CassandraEntireSSTableStreamReader.java:146 - [Stream 
> 8d7c61b0-53e1-11ee-a721-a91a3065a930] Error while reading sstable from stream 
> for table = ks.cf\njava.nio.channels.ClosedChannelException: null\n\tat 
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>  
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:139)\n\tat
>  
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.write(SSTableZeroCopyWriter.java:218)\n\tat
>  
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.writeComponent(SSTableZeroCopyWriter.java:207)\n\tat
>  
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:124)\n\tat
>  
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:87)\n\tat
>  
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:50)\n\tat
>  
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)\n\tat
>  
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)\n\tat
>  
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>  
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
>  java.base/java.lang.Thread.run(Thread.java:833)', [node3] 'ERROR 
> [Stream-Deserializer-/127.0.0.2:7000-6f7e3946] 2023-09-15 16:04:30,687 
> CassandraEntireSSTableStreamReader.java:146 - [Stream 
> 8d7c61b0-53e1-11ee-a721-a91a3065a930] Error while reading sstable from stream 
> for table = ks.cf\njava.nio.channels.ClosedChannelException: null\n\tat 
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>  
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:139)\n\tat
>  
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.write(SSTableZeroCopyWriter.java:218)\n\tat
>  
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.writeComponent(SSTableZeroCopyWriter.java:207)\n\tat
>  
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:124)\n\tat
>  
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:87)\n\tat
>  
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:50)\n\tat
>  
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)\n\tat
>  
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)\n\tat
>  
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>  
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
>  java.base/java.lang.Thread.run(Thread.java:833)']"
> {quote}
> This is probably similar to CASSANDRA-18815



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

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

[jira] [Updated] (CASSANDRA-18830) Set io.netty.transport.noNative to false for in-jvm dtests

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-18830:
--
Status: Needs Committer  (was: Patch Available)

> Set io.netty.transport.noNative to false for in-jvm dtests
> --
>
> Key: CASSANDRA-18830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18830
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> This ticket was created as a reaction to (1).
> (1) https://lists.apache.org/thread/p42yksvo6t0dy67wmnl2bzpnggo9gpp9



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

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

[jira] [Updated] (CASSANDRA-18830) Set io.netty.transport.noNative to false for in-jvm dtests

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-18830:
--
Test and Documentation Plan: CI
 Status: Patch Available  (was: In Progress)

> Set io.netty.transport.noNative to false for in-jvm dtests
> --
>
> Key: CASSANDRA-18830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18830
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> This ticket was created as a reaction to (1).
> (1) https://lists.apache.org/thread/p42yksvo6t0dy67wmnl2bzpnggo9gpp9



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

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

[jira] [Comment Edited] (CASSANDRA-18830) Set io.netty.transport.noNative to false for in-jvm dtests

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-18830 at 9/22/23 7:08 AM:


I was repeating both just gossiper as well as "loop everything test", 100x each

j11 jvm dtest repeat 
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3123/workflows/d9d7d011-55b4-4e8f-aa8c-b163d0c9/jobs/115329
j11 jvm dtest vnode repeat 
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3123/workflows/d9d7d011-55b4-4e8f-aa8c-b163d0c9/jobs/115328

j17 jvm dtest repeat 
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3123/workflows/bb3ee9e7-ed9c-42da-9c1a-44a57883864e/jobs/115326
j17 jvm dtest vnode repeat 
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3123/workflows/bb3ee9e7-ed9c-42da-9c1a-44a57883864e/jobs/115327

j17 pre-commit 
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3194/workflows/093e3e36-ddaa-4fe2-bd0b-70b912044bc2
j11 pre-commit 
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3194/workflows/e89f4179-39ce-4c72-b61b-ff434790a19a



was (Author: smiklosovic):
I was repeating both just gossiper as well as "loop everything test", 100x each

j11 jvm dtest repeat 
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3123/workflows/d9d7d011-55b4-4e8f-aa8c-b163d0c9/jobs/115329
j11 jvm dtest vnode repeat 
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3123/workflows/d9d7d011-55b4-4e8f-aa8c-b163d0c9/jobs/115328

j17 jvm dtest repeat 
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3123/workflows/bb3ee9e7-ed9c-42da-9c1a-44a57883864e/jobs/115326
j17 jvm dtest vnode repeat 
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3123/workflows/bb3ee9e7-ed9c-42da-9c1a-44a57883864e/jobs/115327


> Set io.netty.transport.noNative to false for in-jvm dtests
> --
>
> Key: CASSANDRA-18830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18830
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> This ticket was created as a reaction to (1).
> (1) https://lists.apache.org/thread/p42yksvo6t0dy67wmnl2bzpnggo9gpp9



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

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

[jira] [Commented] (CASSANDRA-18871) JMH benchmark improvements

[Jacek Lewandowski (Jira)]

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

Jacek Lewandowski commented on CASSANDRA-18871:
---

 Run progress: 15.48% complete, ETA 2 days, 15:45:16 ...

> JMH benchmark improvements
> --
>
> Key: CASSANDRA-18871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18871
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build, Legacy/Tools
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.1
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> 1. CASSANDRA-12586  introduced {{build-jmh}} task which builds uber jar for 
> JMH benchmarks which is then not used with {{ant microbench}} task. It is 
> used though by the {{test/bin/jmh}} script. 
> In fact, I have no idea why we should use uber jar if JMH can perfectly run 
> with a regular classpath. Maybe that had something to do with older JMH 
> version which was used that time. Building uber jars takes time and is 
> annoying. Since it seems to be redundant anyway, I'm going to remove it and 
> fix {{test/bin/jmh}} to use a regular classpath. 
> 2. I'll add support for async profiler in benchmarks. That is, the 
> {{microbench}} target automatically fetches the async profiler binaries and 
> adds the necessary args for JMH ({{-prof asyc...}} in particular) whenever we 
> run {{microbench-with-profiler}} task. If no additional properties are 
> provided some default options will be applied (defined in the script, can be 
> negotiated). Otherwise, whatever is passed to the {{profiler.opts}} property 
> will be added as profiler options after library path and target directory 
> definition.
> 3. If someone wants to see any additional improvements, please comment on the 
> ticket.



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

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

[jira] [Updated] (CASSANDRA-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apache.cass

[Jacek Lewandowski (Jira)]

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

Jacek Lewandowski updated CASSANDRA-18747:
--
Component/s: Cluster/Schema

> Test failure: Fix assertion error AssertionError: Unknown keyspace 
> system_auth\n\tat 
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat 
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for 
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11 
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread 
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
>  Unknown keyspace system_auth\n\tat 
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat 
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat 
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>  
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
>  org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat 
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat 
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>  
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>  
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>  
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>  
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>  
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
>  java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in 
> node logs (see stdout for full details). Errors: [[node2] 'ERROR 
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445 
> JVMStabilityInspector.java:70 - Exception in thread 
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
>  Unknown keyspace system_auth\n\tat 
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat 
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat 
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>  
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
>  org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat 
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat 
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>  
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>  
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>  
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>  
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>  
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
>  java.base/java.lang.Thread.run(Thread.java:829)']{code}
> Example failures:
> test_failed_snitch_update_property_file_snitch - 
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2475/workflows/2086619e-0f21-464b-a866-84aca516b5e5/jobs/36716/tests]
> test_gcgs_validation - 
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1666/testReport/junit/dtest.materialized_views_test/TestMaterializedViews/test_gcgs_validation/]



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

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

[jira] [Updated] (CASSANDRA-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apache.cass

[Jacek Lewandowski (Jira)]

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

Jacek Lewandowski updated CASSANDRA-18747:
--
Test and Documentation Plan: run regression tests
 Status: Patch Available  (was: In Progress)

> Test failure: Fix assertion error AssertionError: Unknown keyspace 
> system_auth\n\tat 
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat 
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for 
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11 
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread 
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
>  Unknown keyspace system_auth\n\tat 
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat 
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat 
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>  
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
>  org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat 
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat 
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>  
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>  
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>  
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>  
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>  
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
>  java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in 
> node logs (see stdout for full details). Errors: [[node2] 'ERROR 
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445 
> JVMStabilityInspector.java:70 - Exception in thread 
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
>  Unknown keyspace system_auth\n\tat 
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat 
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat 
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>  
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
>  org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat 
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat 
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>  
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>  
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>  
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>  
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>  
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
>  java.base/java.lang.Thread.run(Thread.java:829)']{code}
> Example failures:
> test_failed_snitch_update_property_file_snitch - 
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2475/workflows/2086619e-0f21-464b-a866-84aca516b5e5/jobs/36716/tests]
> test_gcgs_validation - 
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1666/testReport/junit/dtest.materialized_views_test/TestMaterializedViews/test_gcgs_validation/]



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

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