[jira] [Updated] (CASSANDRA-15687) Regression in traceOutgoingMessage printing message size in tracing

[Dinesh Joshi (Jira)]

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

Dinesh Joshi updated CASSANDRA-15687:
-
  Since Version: 4.0
Source Control Link: 
https://github.com/apache/cassandra/commit/0a860b9b3e66be443b2236454c0f8c97c936a6dc
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed. Thanks for the patch [~jmeredithco]!

> Regression in traceOutgoingMessage printing message size in tracing
> ---
>
> Key: CASSANDRA-15687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15687
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Tracing
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-rc
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The internode messaging refactor (CASSANDRA-15066) introduced a tiny 
> regression to tracing. Previously CASSANDRA-13028 had changed the message 
> emitted by traceOutgoingMessage to include the number of bytes.
> {code}
> "Sending %s message to %s"
> {code}
> to
> {code}
> "Sending %s message to %s message size %d bytes"
> {code}
> But the change was dropped during the refactor, it's easy to put it back.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[cassandra] branch trunk updated: Fix regression with traceOutgoingMessage printing message size.

[djoshi]

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

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


The following commit(s) were added to refs/heads/trunk by this push:
 new 0a860b9  Fix regression with traceOutgoingMessage printing message 
size.
0a860b9 is described below

commit 0a860b9b3e66be443b2236454c0f8c97c936a6dc
Author: Jon Meredith 
AuthorDate: Tue Jan 17 18:49:39 2017 -0500

Fix regression with traceOutgoingMessage printing message size.

Patch by Jon Meredith; Reviewed by Dinesh Joshi for CASSANDRA-15687
---
 CHANGES.txt   | 1 +
 src/java/org/apache/cassandra/net/OutboundConnection.java | 4 ++--
 src/java/org/apache/cassandra/tracing/Tracing.java| 5 +++--
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/CHANGES.txt b/CHANGES.txt
index 2537584..c43414d 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0-alpha4
+ * Fix regression with traceOutgoingMessage printing message size 
(CASSANDRA-15687)
  * Ensure repaired data tracking reads a consistent amount of data across 
replicas (CASSANDRA-15601)
  * Fix CQLSH to avoid arguments being evaluated (CASSANDRA-15660)
  * Correct Visibility and Improve Safety of Methods in LatencyMetrics 
(CASSANDRA-15597)
diff --git a/src/java/org/apache/cassandra/net/OutboundConnection.java 
b/src/java/org/apache/cassandra/net/OutboundConnection.java
index 9661e8e..0503259 100644
--- a/src/java/org/apache/cassandra/net/OutboundConnection.java
+++ b/src/java/org/apache/cassandra/net/OutboundConnection.java
@@ -795,7 +795,7 @@ public class OutboundConnection
 out = new DataOutputBufferFixed(sending.buffer);
 }
 
-Tracing.instance.traceOutgoingMessage(next, 
settings.connectTo);
+Tracing.instance.traceOutgoingMessage(next, 
messageSize, settings.connectTo);
 Message.serializer.serialize(next, out, 
messagingVersion);
 
 if (sending.length() != sendingBytes + messageSize)
@@ -963,7 +963,7 @@ public class OutboundConnection
 if (messageSize > 
DatabaseDescriptor.getInternodeMaxMessageSizeInBytes())
 throw new Message.OversizedMessageException(messageSize);
 
-Tracing.instance.traceOutgoingMessage(send, 
established.settings.connectTo);
+Tracing.instance.traceOutgoingMessage(send, messageSize, 
established.settings.connectTo);
 Message.serializer.serialize(send, out, 
established.messagingVersion);
 
 if (out.position() != messageSize)
diff --git a/src/java/org/apache/cassandra/tracing/Tracing.java 
b/src/java/org/apache/cassandra/tracing/Tracing.java
index 5891981..311685b 100644
--- a/src/java/org/apache/cassandra/tracing/Tracing.java
+++ b/src/java/org/apache/cassandra/tracing/Tracing.java
@@ -273,7 +273,7 @@ public abstract class Tracing implements 
ExecutorLocal
 /**
  * Record any tracing data, if enabled on this message.
  */
-public void traceOutgoingMessage(Message message, InetAddressAndPort 
sendTo)
+public void traceOutgoingMessage(Message message, int serializedSize, 
InetAddressAndPort sendTo)
 {
 try
 {
@@ -281,7 +281,8 @@ public abstract class Tracing implements 
ExecutorLocal
 if (sessionId == null)
 return;
 
-String logMessage = String.format("Sending %s message to %s", 
message.verb(), sendTo);
+String logMessage = String.format("Sending %s message to %s 
message size %d bytes", message.verb(), sendTo,
+  serializedSize);
 
 TraceState state = get(sessionId);
 if (state == null) // session may have already finished; see 
CASSANDRA-5668


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

[jira] [Updated] (CASSANDRA-15687) Regression in traceOutgoingMessage printing message size in tracing

[Dinesh Joshi (Jira)]

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

Dinesh Joshi updated CASSANDRA-15687:
-
Status: Ready to Commit  (was: Review In Progress)

+1

> Regression in traceOutgoingMessage printing message size in tracing
> ---
>
> Key: CASSANDRA-15687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15687
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Tracing
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-rc
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The internode messaging refactor (CASSANDRA-15066) introduced a tiny 
> regression to tracing. Previously CASSANDRA-13028 had changed the message 
> emitted by traceOutgoingMessage to include the number of bytes.
> {code}
> "Sending %s message to %s"
> {code}
> to
> {code}
> "Sending %s message to %s message size %d bytes"
> {code}
> But the change was dropped during the refactor, it's easy to put it back.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15710) DOC - Add cqlsh Python 3 support in NEWS.txt and tools section of website

[Dinesh Joshi (Jira)]

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

Dinesh Joshi updated CASSANDRA-15710:
-
  Fix Version/s: 4.0
Source Control Link: 
https://github.com/apache/cassandra/commit/b18900a1f269e7eae88f1e84867bb2d780cde94e
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> DOC - Add cqlsh Python 3 support in NEWS.txt and tools section of website
> -
>
> Key: CASSANDRA-15710
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15710
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/NEWS.txt
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0
>
> Attachments: 15710-trunk.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h2. Background
> I found out by accident that CASSANDRA-10190 is not documented in 
> {{NEWS.txt}}.
> h2. Scope
> * {{NEWS.txt}} - Add info on Python 3 support for cqlsh.
> * Docs - include new {{--python}} option



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[cassandra] branch trunk updated: Update NEWS.txt with Python 3 support for CQLSH

[djoshi]

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

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


The following commit(s) were added to refs/heads/trunk by this push:
 new b18900a  Update NEWS.txt with Python 3 support for CQLSH
b18900a is described below

commit b18900a1f269e7eae88f1e84867bb2d780cde94e
Author: Erick Ramirez 
AuthorDate: Fri Apr 17 22:44:52 2020 -0700

Update NEWS.txt with Python 3 support for CQLSH

Patch by Erick Ramirez; Reviewed by David Capwell and Dinesh Joshi for 
CASSANDRA-15710
---
 NEWS.txt   | 3 +++
 doc/source/tools/cqlsh.rst | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/NEWS.txt b/NEWS.txt
index 2f65586..83719f7 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -110,6 +110,9 @@ New features
   specifying replication_factor: 3 translates to three replicas in every
   datacenter. This auto-expansion will _only add_ datacenters for safety.
   See CASSANDRA-14303 for more details.
+- Added Python 3 support so cqlsh and cqlshlib is now compatible with 
Python 2.7 and Python 3.6.
+  Added --python option to cqlsh so users can specify the path to their 
chosen Python interpreter.
+  See CASSANDRA-10190 for details.
 
 Upgrading
 -
diff --git a/doc/source/tools/cqlsh.rst b/doc/source/tools/cqlsh.rst
index 45e2db8..b800b88 100644
--- a/doc/source/tools/cqlsh.rst
+++ b/doc/source/tools/cqlsh.rst
@@ -100,6 +100,9 @@ Options:
 ``--connect-timeout``
   Specify the connection timeout in seconds (defaults to 2s)
 
+``--python /path/to/python``
+  Specify the full path to Python interpreter to override default on systems 
with multiple interpreters installed
+
 ``--request-timeout``
   Specify the request timeout in seconds (defaults to 10s)
 


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

[jira] [Updated] (CASSANDRA-15710) DOC - Add cqlsh Python 3 support in NEWS.txt and tools section of website

[Dinesh Joshi (Jira)]

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

Dinesh Joshi updated CASSANDRA-15710:
-
Reviewers: David Capwell, Dinesh Joshi  (was: David Capwell, Dinesh Joshi, 
Jon Haddad, Patrick Bannister)

> DOC - Add cqlsh Python 3 support in NEWS.txt and tools section of website
> -
>
> Key: CASSANDRA-15710
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15710
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/NEWS.txt
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
>  Labels: pull-request-available
> Attachments: 15710-trunk.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h2. Background
> I found out by accident that CASSANDRA-10190 is not documented in 
> {{NEWS.txt}}.
> h2. Scope
> * {{NEWS.txt}} - Add info on Python 3 support for cqlsh.
> * Docs - include new {{--python}} option



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15710) DOC - Add cqlsh Python 3 support in NEWS.txt and tools section of website

[Dinesh Joshi (Jira)]

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

Dinesh Joshi updated CASSANDRA-15710:
-
Status: Ready to Commit  (was: Review In Progress)

+1

> DOC - Add cqlsh Python 3 support in NEWS.txt and tools section of website
> -
>
> Key: CASSANDRA-15710
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15710
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/NEWS.txt
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
>  Labels: pull-request-available
> Attachments: 15710-trunk.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h2. Background
> I found out by accident that CASSANDRA-10190 is not documented in 
> {{NEWS.txt}}.
> h2. Scope
> * {{NEWS.txt}} - Add info on Python 3 support for cqlsh.
> * Docs - include new {{--python}} option



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15657) Improve zero-copy-streaming containment check by using file sections

[Dinesh Joshi (Jira)]

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

Dinesh Joshi commented on CASSANDRA-15657:
--

[~jasonstack], sorry I thought [~tjake] was looking at this. I can take a look 
over the weekend if [~tjake] doesn't get to it first.

> Improve zero-copy-streaming containment check by using file sections
> 
>
> Key: CASSANDRA-15657
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15657
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Streaming and Messaging
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0
>
>
> Currently zero copy streaming is only enabled for leveled-compaction strategy 
> and it checks if all keys in the sstables are included in the transferred 
> ranges.
> This is very inefficient. The containment check can be improved by checking 
> if transferred sections (the transferred file positions) cover entire sstable.
> I also enabled ZCS for all compaction strategies since the new containment 
> check is very fast..



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15623) When running CQLSH with STDIN input, exit with error status code if script fails

[Dinesh Joshi (Jira)]

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

Dinesh Joshi updated CASSANDRA-15623:
-
Source Control Link: 
https://github.com/apache/cassandra/commit/a738c580224e340f011ffa174a9f1259521120cd
  (was: 
https://github.com/apache/cassandra/commit/c4db3f89a9a07c45c78da9b5b3f802a6f8b51531)

> When running CQLSH with STDIN input, exit with error status code if script 
> fails
> 
>
> Key: CASSANDRA-15623
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15623
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Tools
>Reporter: Jacob Becker
>Assignee: Jacob Becker
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 3.0.21, 3.11.7, 4.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Assuming CASSANDRA-6344 is in place for years and considering that scripts 
> submitted with the `-e` option behave in a similar fashion, it is very 
> surprising that scripts submitted to STDIN (i.e. piped in) always exit with a 
> zero code, regardless of errors. I believe this should be fixed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15623) When running CQLSH with STDIN input, exit with error status code if script fails

[Dinesh Joshi (Jira)]

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

Dinesh Joshi edited comment on CASSANDRA-15623 at 4/18/20, 5:31 AM:


Committed to 3.0, 3.11 and 4.0. Thanks for the patch [~plastikat]!


was (Author: djoshi3):
Committed. Thanks for the patch [~plastikat]!

> When running CQLSH with STDIN input, exit with error status code if script 
> fails
> 
>
> Key: CASSANDRA-15623
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15623
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Tools
>Reporter: Jacob Becker
>Assignee: Jacob Becker
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 3.0.21, 3.11.7, 4.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Assuming CASSANDRA-6344 is in place for years and considering that scripts 
> submitted with the `-e` option behave in a similar fashion, it is very 
> surprising that scripts submitted to STDIN (i.e. piped in) always exit with a 
> zero code, regardless of errors. I believe this should be fixed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15623) When running CQLSH with STDIN input, exit with error status code if script fails

[Dinesh Joshi (Jira)]

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

Dinesh Joshi updated CASSANDRA-15623:
-
  Fix Version/s: 4.0
 3.11.7
 3.0.21
  Since Version: 3.0.21
Source Control Link: 
https://github.com/apache/cassandra/commit/c4db3f89a9a07c45c78da9b5b3f802a6f8b51531
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed. Thanks for the patch [~plastikat]!

> When running CQLSH with STDIN input, exit with error status code if script 
> fails
> 
>
> Key: CASSANDRA-15623
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15623
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Tools
>Reporter: Jacob Becker
>Assignee: Jacob Becker
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 3.0.21, 3.11.7, 4.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Assuming CASSANDRA-6344 is in place for years and considering that scripts 
> submitted with the `-e` option behave in a similar fashion, it is very 
> surprising that scripts submitted to STDIN (i.e. piped in) always exit with a 
> zero code, regardless of errors. I believe this should be fixed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15623) When running CQLSH with STDIN input, exit with error status code if script fails

[Dinesh Joshi (Jira)]

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

Dinesh Joshi updated CASSANDRA-15623:
-
Status: Ready to Commit  (was: Review In Progress)

+1

> When running CQLSH with STDIN input, exit with error status code if script 
> fails
> 
>
> Key: CASSANDRA-15623
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15623
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Tools
>Reporter: Jacob Becker
>Assignee: Jacob Becker
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Assuming CASSANDRA-6344 is in place for years and considering that scripts 
> submitted with the `-e` option behave in a similar fashion, it is very 
> surprising that scripts submitted to STDIN (i.e. piped in) always exit with a 
> zero code, regardless of errors. I believe this should be fixed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
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-3.11' into trunk

[djoshi]

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

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

commit 6ee67a64eaf7df2c29398b3c456f9255e7007987
Merge: c4db3f8 9b940a5
Author: Dinesh A. Joshi 
AuthorDate: Fri Apr 17 22:15:02 2020 -0700

Merge branch 'cassandra-3.11' into trunk

 CHANGES.txt  | 1 +
 bin/cqlsh.py | 7 +--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --cc CHANGES.txt
index 4586c71,cd69117..2537584
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,54 -1,9 +1,55 @@@
 -3.11.7
 +4.0-alpha4
 + * Ensure repaired data tracking reads a consistent amount of data across 
replicas (CASSANDRA-15601)
 + * Fix CQLSH to avoid arguments being evaluated (CASSANDRA-15660)
 + * Correct Visibility and Improve Safety of Methods in LatencyMetrics 
(CASSANDRA-15597)
 + * Allow cqlsh to run with Python2.7/Python3.6+ 
(CASSANDRA-15659,CASSANDRA-15573)
 + * Improve logging around incremental repair (CASSANDRA-15599)
 + * Do not check cdc_raw_directory filesystem space if CDC disabled 
(CASSANDRA-15688)
 + * Replace array iterators with get by index (CASSANDRA-15394)
 + * Minimize BTree iterator allocations (CASSANDRA-15389)
 + * Add client request size server metrics (CASSANDRA-15704)
 + * Add additional logging around FileUtils and compaction leftover cleanup 
(CASSANDRA-15705)
 + * Mark system_views/system_virtual_schema as non-alterable keyspaces in 
cqlsh (CASSANDRA-15711)
 + * Fail incremental repair if an old version sstable is involved 
(CASSANDRA-15612)
 + * Fix overflows on StreamingTombstoneHistogramBuilder produced by large 
deletion times (CASSANDRA-14773)
 + * Mark system_views/system_virtual_schema as system keyspaces in cqlsh 
(CASSANDRA-15706)
 + * Avoid unnecessary collection/iterator allocations during btree 
construction (CASSANDRA-15390)
 + * Repair history tables should have TTL and TWCS (CASSANDRA-12701)
 + * Fix cqlsh erroring out on Python 3.7 due to webbrowser module being absent 
(CASSANDRA-15572)
 + * Fix IMH#acquireCapacity() to return correct Outcome when endpoint reserve 
runs out (CASSANDRA-15607)
 + * Fix nodetool describering output (CASSANDRA-15682)
 + * Only track ideal CL failure when request CL met (CASSANDRA-15696)
 + * Fix flaky CoordinatorMessagingTest and docstring in OutboundSink and 
ConsistentSession (CASSANDRA-15672)
 + * Fix force compaction of wrapping ranges (CASSANDRA-15664)
 + * Expose repair streaming metrics (CASSANDRA-15656)
 + * Set now in seconds in the future for validation repairs (CASSANDRA-15655)
 + * Emit metric on preview repair failure (CASSANDRA-15654)
 + * Use more appropriate logging levels (CASSANDRA-15661)
 + * Fixed empty check in TrieMemIndex due to potential state inconsistency in 
ConcurrentSkipListMap (CASSANDRA-15526)
 + * Added UnleveledSSTables global and table level metric (CASSANDRA-15620)
 + * Added Virtual Table exposing Cassandra relevant system properties 
(CASSANDRA-15616, CASSANDRA-15643)
 + * Improve the algorithmic token allocation in case racks = RF 
(CASSANDRA-15600)
 + * Fix ConnectionTest.testAcquireReleaseOutbound (CASSANDRA-15308)
 + * Include finalized pending sstables in preview repair (CASSANDRA-15553)
 + * Reverted to the original behavior of CLUSTERING ORDER on CREATE TABLE 
(CASSANDRA-15271)
 + * Correct inaccurate logging message (CASSANDRA-15549)
 + * Unset GREP_OPTIONS (CASSANDRA-14487)
 + * Update to Python driver 3.21 for cqlsh (CASSANDRA-14872)
 + * Fix missing Keyspaces in cqlsh describe output (CASSANDRA-15576)
 + * Fix multi DC nodetool status output (CASSANDRA-15305)
 + * updateCoordinatorWriteLatencyTableMetric can produce misleading metrics 
(CASSANDRA-15569)
 + * Make cqlsh and cqlshlib Python 2 & 3 compatible (CASSANDRA-10190)
 + * Improve the description of nodetool listsnapshots command (CASSANDRA-14587)
 + * allow embedded cassandra launched from a one-jar or uno-jar 
(CASSANDRA-15494)
 + * Update hppc library to version 0.8.1 (CASSANDRA-12995)
 + * Limit the dependencies used by UDFs/UDAs (CASSANDRA-14737)
 + * Make native_transport_max_concurrent_requests_in_bytes updatable 
(CASSANDRA-15519)
 + * Cleanup and improvements to IndexInfo/ColumnIndex (CASSANDRA-15469)
 + * Potential Overflow in DatabaseDescriptor Functions That Convert Between 
KB/MB & Bytes (CASSANDRA-15470)
 +Merged from 3.11:
   * Allow sstableloader to use SSL on the native port (CASSANDRA-14904)
  Merged from 3.0:
 -===
 -3.0.21
+  * cqlsh return non-zero status when STDIN CQL fails (CASSANDRA-15623)
   * Don't skip sstables in slice queries based only on local min/max/deletion 
timestamp (CASSANDRA-15690)
   * Memtable memory allocations may deadlock (CASSANDRA-15367)
   * Run evictFromMembership in GossipStage (CASSANDRA-15592)
diff --cc bin/cqlsh.py
index 272bf40,2e5e2d4..310a265
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@@ -537,9 -546,12 +537,13 @@@ class Shell(cmd.Cmd)
  self.empty_lines = 0
  self.statement_error = False
   

[cassandra] branch cassandra-3.0 updated (092915a -> a738c58)

[djoshi]

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

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


from 092915a  Don't skip sstables with partition deletes
 add a738c58  cqlsh return non-zero status when STDIN CQL fails

No new revisions were added by this update.

Summary of changes:
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 8 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)


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

[cassandra] branch cassandra-3.11 updated (d6beb01 -> 9b940a5)

[djoshi]

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

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


from d6beb01  Merge branch 'cassandra-3.0' into cassandra-3.11
 add a738c58  cqlsh return non-zero status when STDIN CQL fails
 add 9b940a5  Merge branch 'cassandra-3.0' into cassandra-3.11

No new revisions were added by this update.

Summary of changes:
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 8 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)


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

[cassandra] branch trunk updated (c4db3f8 -> 6ee67a6)

[djoshi]

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

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


from c4db3f8  Generate compiler options file to support Java11 in IDEA.
 add a738c58  cqlsh return non-zero status when STDIN CQL fails
 add 9b940a5  Merge branch 'cassandra-3.0' into cassandra-3.11
 new 6ee67a6  Merge branch 'cassandra-3.11' into trunk

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


Summary of changes:
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 7 +--
 2 files changed, 6 insertions(+), 2 deletions(-)


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

[jira] [Updated] (CASSANDRA-15738) Generate compiler options file to support Java11 in IDEA.

[Dinesh Joshi (Jira)]

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

Dinesh Joshi updated CASSANDRA-15738:
-
  Since Version: 4.0
Source Control Link: 
https://github.com/apache/cassandra/commit/c4db3f89a9a07c45c78da9b5b3f802a6f8b51531
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed. Thank you for the patch [~jmeredithco].

> Generate compiler options file to support Java11 in IDEA.
> -
>
> Key: CASSANDRA-15738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15738
> Project: Cassandra
>  Issue Type: Bug
>  Components: Build
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-rc
>
>
> The change to JMX in CASSANDRA-15653 prevents the generated IDEA project from 
> compiling under JDK11.
> Fix by adding options for a module (named after the checkout dir)
> {code}
> 
> 
>   
> 
>   
> 
>   
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[cassandra] branch trunk updated: Generate compiler options file to support Java11 in IDEA.

[djoshi]

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

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


The following commit(s) were added to refs/heads/trunk by this push:
 new c4db3f8  Generate compiler options file to support Java11 in IDEA.
c4db3f8 is described below

commit c4db3f89a9a07c45c78da9b5b3f802a6f8b51531
Author: Jon Meredith 
AuthorDate: Fri Apr 17 14:17:49 2020 -0600

Generate compiler options file to support Java11 in IDEA.

The change to JMX in CASSANDRA-15653 prevents the IDEA project from
compiling under JDK11.  This change adds the required compiler flag
when the project is upgraded from Java1.8 to Java11.

Patch by Jon Meredith; Reviewed by Dinesh Joshi for CASSANDRA-15738
---
 build.xml | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/build.xml b/build.xml
index cdc3c64..5752b2d 100644
--- a/build.xml
+++ b/build.xml
@@ -2136,6 +2136,13 @@
match="name=VM_PARAMETERS 
value=(.*)"
replace="name=VM_PARAMETERS value=\1 
${java11-jvmargs}"
byline="true"/>
+
+  
   
 
   


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

[jira] [Updated] (CASSANDRA-15738) Generate compiler options file to support Java11 in IDEA.

[Dinesh Joshi (Jira)]

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

Dinesh Joshi updated CASSANDRA-15738:
-
Status: Ready to Commit  (was: Review In Progress)

+1

> Generate compiler options file to support Java11 in IDEA.
> -
>
> Key: CASSANDRA-15738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15738
> Project: Cassandra
>  Issue Type: Bug
>  Components: Build
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-rc
>
>
> The change to JMX in CASSANDRA-15653 prevents the generated IDEA project from 
> compiling under JDK11.
> Fix by adding options for a module (named after the checkout dir)
> {code}
> 
> 
>   
> 
>   
> 
>   
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15738) Generate compiler options file to support Java11 in IDEA.

[Dinesh Joshi (Jira)]

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

Dinesh Joshi updated CASSANDRA-15738:
-
Reviewers: Dinesh Joshi, Dinesh Joshi  (was: Dinesh Joshi)
   Dinesh Joshi, Dinesh Joshi
   Status: Review In Progress  (was: Patch Available)

> Generate compiler options file to support Java11 in IDEA.
> -
>
> Key: CASSANDRA-15738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15738
> Project: Cassandra
>  Issue Type: Bug
>  Components: Build
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-rc
>
>
> The change to JMX in CASSANDRA-15653 prevents the generated IDEA project from 
> compiling under JDK11.
> Fix by adding options for a module (named after the checkout dir)
> {code}
> 
> 
>   
> 
>   
> 
>   
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 4/18/20, 2:06 AM:
---

Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
the problem conversion explained below, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already have it actually 
>with Integer and String parameters, just they are not many so it didn't byte 
>us up to now. Not sure whether this was considered when the Config class was 
>built or not.

So the issue with int parameters in Config in my solution is:
Currently in trunk, when we parse to int variable, If a parameter is commented 
in the cassandra.yaml, this is observed as null and it will raise an exception 
in some cases. (i.e. commitlog_sync_period_in_ms) But if it is not commented, 
just not assigned a value, then this is considered as 0 (as we parse to int). 
The situation is different with String, Integer. They will be in both cases 
null. No differentiator. But currently we don't have many parameters being 
Integer and String and it didn't byte us.
Now with the units attached to the parameters' values in the cassandra.yaml 
file, we need to parse strings with snakeyaml and then convert to the proper 
int values in Config.  

A way to cope with this issue is to make the users use "". In this way, if we 
have a parameter not commented, but not also having an assigned value in 
cassandra.yaml, we can identify it by checking a string for being empty. If the 
parameter is commented or not presented, it will be null. But this would be one 
more new thing for the users to consider. That's why I came back to snakeyaml 
again and tried to think of a different way utilizing it. Unfortunately, up to 
now I didn't find any different solution. Also, the links to the examples in 
the official snakeyaml documentation are broken. Not sure whether there they 
had some interesting stuff. Maybe something with customized constructor but 
also, I try to make as less as possible disruptive changes in the codebase in 
order not to mess up something with the Config which might be extremely 
unpleasant.

I will be happy to hear an experienced opinion here. Does anyone know a better 
solution? Or are we ok to introduce  "" in the yaml for empty 
parameters/Strings recognition?

[Part1|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-2] 
(This part was already revised by [~dcapwell] but I paste the explanation again 
here for completeness).
 - New cassandra.yaml ---> currently cassandra-new.yaml in the branch as I 
wanted to test the backward compatibility on the old version (will have to 
rename properly also these yaml files with version probably)
reorganization of the file renames to make the names more consistent
- Backward compatibility with the old names - my approach is:
Cassandra comes with the new version of the yaml to ensure any new builds will 
be using it
During load of the yaml file I check whether old names are identified(means 
someone upgraded to 4 and wants to still use the old yaml). If this is the 
case, we load the values from the old yaml to the new variables (the already 
renamed parameters). Also, there is a warning to the user that there is new 
cassandra.yaml version and he/she can consider an update. 

[Part2|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3] 
- units added to the values in the cassandra.yaml file. Parsing and unit 
conversion in place. One unit test added, should be further developed. 

[DTests|https://github.com/ekaterinadimitrova2/cassandra-dtest] updated 
accordingly for v.4

[Part3|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] 
- SysProperties class, accessors, hope I didn't miss anything... most of them 
are actually just using System.getProperty method.
TO DO: Extract the parser/converter in a separate class from Config

[~mck]? [~dcapwell]? [~benedict]?  Anyone else any thoughts here?

NOTE: The branches are not fully cleaned, this is still work in progress but we 
need to take a decision on the String issue first, I think.


was (Author: e.dimitrova):
Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
the problem conversion explained below, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings 

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 4/18/20, 2:04 AM:
---

Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
the problem conversion explained below, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already have it actually 
>with Integer and String parameters, just they are not many so it didn't byte 
>us up to now. Not sure whether this was considered when the Config class was 
>built or not.

So the issue with int parameters in Config in my solution is:
Currently in trunk, when we parse to int variable, If a parameter is commented 
in the cassandra.yaml, this is observed as null and it will raise an exception 
in some cases. (i.e. commitlog_sync_period_in_ms) But if it is not commented, 
just not assigned a value, then this is considered as 0 (as we parse to int). 
The situation is different with String, Integer. They will be in both cases 
null. No differentiator. But currently we don't have many parameters being 
Integer and String and it didn't byte us.
Now with the units attached to the parameters' values in the cassandra.yaml 
file, we need to parse strings with snakeyaml and then convert to the proper 
int values in Config.  

A way to cope with this issue is to make the users use "". In this way, if we 
have a parameter not commented, but not also having an assigned value in 
cassandra.yaml, we can identify it by checking a string for being empty. If the 
parameter is commented or not presented, it will be null. But this would be one 
more new thing for the users to consider. That's why I came back to snakeyaml 
again and tried to think of a different way utilizing it. Unfortunately, up to 
now I didn't find any different solution. Also, the links to the examples in 
the official snakeyaml documentation are broken. Not sure whether there they 
had some interesting stuff. Maybe something with customized constructor but 
also, I try to make as less as possible disruptive changes in the codebase in 
order not to mess up something with the Config which might be extremely 
unpleasant.

I will be happy to hear an experienced opinion here. Does anyone know a better 
solution? Or are we ok to introduce  "" in the yaml for empty 
parameters/Strings recognition?

[Part1|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-2] 
(This part was already revised by [~dcapwell] but I paste the explanation again 
here for completeness).
 - New cassandra.yaml ---> currently cassandra-new.yaml in the branch as I 
wanted to test the backward compatibility on the old version (will have to 
rename properly also these yaml files with version probably)
reorganization of the file renames to make the names more consistent
- Backward compatibility with the old names - my approach is:
Cassandra comes with the new version of the yaml to ensure any new builds will 
be using it
During load of the yaml file I check whether old names are identified(means 
someone upgraded to 4 and wants to still use the old yaml). If this is the 
case, we load the values from the old yaml to the new variables (the already 
renamed parameters). Also, there is a warning to the user that there is new 
cassandra.yaml version and he/she can consider an update. 

[Part2|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3] 
- units added to the values in the cassandra.yaml file. Parsing and unit 
conversion in place. One unit test added, should be further developed. 

[DTests|https://github.com/ekaterinadimitrova2/cassandra-dtest] updated 
accordingly for v.4

[Part3|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] 
- SysProperties class, accessors, hope I didn't miss anything... most of them 
are actually just using System.getProperty method.
TO DO: Extract the parser/converter in a separate class from Config

[~mck]? [~dcapwell]? [~benedict]?  Anyone else any thoughts here?

NOTE: The branches are not fully cleared, this is still work in progress but we 
need to take a decision on the String issue first, I think.


was (Author: e.dimitrova):
Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
the problem conversion explained below, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings 

[jira] [Updated] (CASSANDRA-15727) Internode messaging connection setup between 4.0 and legacy SSL 3.0 fails if initial connection version incorrect

[Jon Meredith (Jira)]

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

Jon Meredith updated CASSANDRA-15727:
-
Description: 
This was discovered while testing upgrading an SSL enabled cluster from 3.0 to 
4.0.  The 3.0 cluster was configured to only listen on the ssl storage port. 
When the upgraded 4.0 node started it received a gossip messsage that triggered 
a shadow round before it had correctly set the messaging versions for the other 
endpoints.

Sending the message created the connection, but because the endpoint defaulted 
to {{VERSION_40}} the initial connect attempt was to the regular 
{{storage_port}}.  The 3.0 node was only listening on the {{ssl_storage_port}}, 
so the connection was refused and the {{OutboundConnection.onFailure}} handler 
was called.  As the shadow
gossip round had queued up a message, the {{hasPending}} branch was followed 
and the connection was rescheduled, however the port is never recalculated as 
the original settings are used so it always fails.

Meanwhile, the node discovered information about peers through inbound 
connection and gossip updating the messaging version for the endpoint which 
could have been used to make a valid connection.

  was:
This was discovered while testing upgrading an SSL enabled cluster from 3.0 to 
4.0.  The 3.0 cluster was configured to only listen on the ssl storage port. 
When the upgraded 4.0 node started it received a gossip messsage that triggered 
a shadow round before it had correctly set the messaging versions for the other 
endpoints.

Sending the message created the connection, but because the endpoint defaulted 
to {code}VERSION_40{code} the initial connect attempt was to the regular 
{code}storage_port{code}.  The 3.0 node was only listening on the 
{code}ssl_storage_port{code}, so the connection was refused and the 
{code}OutboundCOnnection.onFailure{code} handler was called.  As the shadow
gossip round had queued up a message, the {code}hasPending{code} branch was 
followed and the connection was rescheduled, however the port is never 
recalculated as the original settings are used so it always fails.

Meanwhile, the node discovered information about peers through inbound 
connection and gossip updating the messaging version for the endpoint which 
could have been used to make a valid connection.


> Internode messaging connection setup between 4.0 and legacy SSL 3.0 fails if 
> initial connection version incorrect
> -
>
> Key: CASSANDRA-15727
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15727
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-beta
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This was discovered while testing upgrading an SSL enabled cluster from 3.0 
> to 4.0.  The 3.0 cluster was configured to only listen on the ssl storage 
> port. When the upgraded 4.0 node started it received a gossip messsage that 
> triggered a shadow round before it had correctly set the messaging versions 
> for the other endpoints.
> Sending the message created the connection, but because the endpoint 
> defaulted to {{VERSION_40}} the initial connect attempt was to the regular 
> {{storage_port}}.  The 3.0 node was only listening on the 
> {{ssl_storage_port}}, so the connection was refused and the 
> {{OutboundConnection.onFailure}} handler was called.  As the shadow
> gossip round had queued up a message, the {{hasPending}} branch was followed 
> and the connection was rescheduled, however the port is never recalculated as 
> the original settings are used so it always fails.
> Meanwhile, the node discovered information about peers through inbound 
> connection and gossip updating the messaging version for the endpoint which 
> could have been used to make a valid connection.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15727) Internode messaging connection setup between 4.0 and legacy SSL 3.0 fails if initial connection version incorrect

[Jon Meredith (Jira)]

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

Jon Meredith commented on CASSANDRA-15727:
--

Committed fix for test failure - 
[Java8|https://app.circleci.com/pipelines/github/jonmeredith/cassandra/339/workflows/def20a38-cd04-4a7b-bfc6-7f15b3c1abd9]
 
[Java11|https://app.circleci.com/pipelines/github/jonmeredith/cassandra/339/workflows/8e63bc9c-7941-4bd6-af2f-e3a604181a7e]

> Internode messaging connection setup between 4.0 and legacy SSL 3.0 fails if 
> initial connection version incorrect
> -
>
> Key: CASSANDRA-15727
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15727
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-beta
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This was discovered while testing upgrading an SSL enabled cluster from 3.0 
> to 4.0.  The 3.0 cluster was configured to only listen on the ssl storage 
> port. When the upgraded 4.0 node started it received a gossip messsage that 
> triggered a shadow round before it had correctly set the messaging versions 
> for the other endpoints.
> Sending the message created the connection, but because the endpoint 
> defaulted to {code}VERSION_40{code} the initial connect attempt was to the 
> regular {code}storage_port{code}.  The 3.0 node was only listening on the 
> {code}ssl_storage_port{code}, so the connection was refused and the 
> {code}OutboundCOnnection.onFailure{code} handler was called.  As the shadow
> gossip round had queued up a message, the {code}hasPending{code} branch was 
> followed and the connection was rescheduled, however the port is never 
> recalculated as the original settings are used so it always fails.
> Meanwhile, the node discovered information about peers through inbound 
> connection and gossip updating the messaging version for the endpoint which 
> could have been used to make a valid connection.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15727) Internode messaging connection setup between 4.0 and legacy SSL 3.0 fails if initial connection version incorrect

[Jon Meredith (Jira)]

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

Jon Meredith commented on CASSANDRA-15727:
--

Looks like I have a test failure to deal with..

{code}
[junit-timeout] Testsuite: org.apache.cassandra.net.ConnectionTest Tests run: 
13, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 77.412 sec
[junit-timeout] 
[junit-timeout] Testcase: 
testPendingOutboundConnectionUpdatesMessageVersionOnReconnectAttempt(org.apache.cassandra.net.ConnectionTest):
Caused an ERROR
[junit-timeout] Local endpoint port 7011 doesn't match YAML configured port 
7016 or legacy SSL port 7015
[junit-timeout] org.apache.cassandra.exceptions.ConfigurationException: Local 
endpoint port 7011 doesn't match YAML configured port 7016 or legacy SSL port 
7015
[junit-timeout] at 
org.apache.cassandra.net.InboundConnectionSettings.withDefaults(InboundConnectionSettings.java:172)
[junit-timeout] at 
org.apache.cassandra.net.InboundSockets.addBindings(InboundSockets.java:190)
[junit-timeout] at 
org.apache.cassandra.net.InboundSockets.bindings(InboundSockets.java:184)
[junit-timeout] at 
org.apache.cassandra.net.InboundSockets.(InboundSockets.java:168)
[junit-timeout] at 
org.apache.cassandra.net.ConnectionTest.testPendingOutboundConnectionUpdatesMessageVersionOnReconnectAttempt(ConnectionTest.java:586)
{code}

> Internode messaging connection setup between 4.0 and legacy SSL 3.0 fails if 
> initial connection version incorrect
> -
>
> Key: CASSANDRA-15727
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15727
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-beta
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This was discovered while testing upgrading an SSL enabled cluster from 3.0 
> to 4.0.  The 3.0 cluster was configured to only listen on the ssl storage 
> port. When the upgraded 4.0 node started it received a gossip messsage that 
> triggered a shadow round before it had correctly set the messaging versions 
> for the other endpoints.
> Sending the message created the connection, but because the endpoint 
> defaulted to {code}VERSION_40{code} the initial connect attempt was to the 
> regular {code}storage_port{code}.  The 3.0 node was only listening on the 
> {code}ssl_storage_port{code}, so the connection was refused and the 
> {code}OutboundCOnnection.onFailure{code} handler was called.  As the shadow
> gossip round had queued up a message, the {code}hasPending{code} branch was 
> followed and the connection was rescheduled, however the port is never 
> recalculated as the original settings are used so it always fails.
> Meanwhile, the node discovered information about peers through inbound 
> connection and gossip updating the messaging version for the endpoint which 
> could have been used to make a valid connection.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15738) Generate compiler options file to support Java11 in IDEA.

[Jon Meredith (Jira)]

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

Jon Meredith commented on CASSANDRA-15738:
--

PR https://github.com/apache/cassandra/pull/545 / Commit 
https://github.com/apache/cassandra/pull/545/commits/9bc5dedde44db1376c860edf332d48e56e74b0d9

> Generate compiler options file to support Java11 in IDEA.
> -
>
> Key: CASSANDRA-15738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15738
> Project: Cassandra
>  Issue Type: Bug
>  Components: Build
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-rc
>
>
> The change to JMX in CASSANDRA-15653 prevents the generated IDEA project from 
> compiling under JDK11.
> Fix by adding options for a module (named after the checkout dir)
> {code}
> 
> 
>   
> 
>   
> 
>   
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15738) Generate compiler options file to support Java11 in IDEA.

[Jon Meredith (Jira)]

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

Jon Meredith updated CASSANDRA-15738:
-
Test and Documentation Plan: 
To test,

Either a clean checkout or remove the {{.idea}} directory, then under Java8 and 
Java11 run {{ant generate-idea-files}} then load the project and compile.

Under Java11, check {{Preferences}} -> {{Build, Execution, Deployment}} -> 
{{Java Compiler}} and there should be an entry under {{Additional command line 
parameters:}} you should see

{code}
--add-exports java.rmi/sun.rmi.registry=ALL-UNNAMED
{code}

Under Java8, no {{.idea/compiler.xml}} file should be generated.
 Status: Patch Available  (was: Open)

> Generate compiler options file to support Java11 in IDEA.
> -
>
> Key: CASSANDRA-15738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15738
> Project: Cassandra
>  Issue Type: Bug
>  Components: Build
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-rc
>
>
> The change to JMX in CASSANDRA-15653 prevents the generated IDEA project from 
> compiling under JDK11.
> Fix by adding options for a module (named after the checkout dir)
> {code}
> 
> 
>   
> 
>   
> 
>   
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15738) Generate compiler options file to support Java11 in IDEA.

[Jon Meredith (Jira)]

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

Jon Meredith updated CASSANDRA-15738:
-
 Bug Category: Parent values: Code(13163)
   Complexity: Low Hanging Fruit
Discovered By: User Report
Fix Version/s: 4.0-rc
 Severity: Low
   Status: Open  (was: Triage Needed)

> Generate compiler options file to support Java11 in IDEA.
> -
>
> Key: CASSANDRA-15738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15738
> Project: Cassandra
>  Issue Type: Bug
>  Components: Build
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-rc
>
>
> The change to JMX in CASSANDRA-15653 prevents the generated IDEA project from 
> compiling under JDK11.
> Fix by adding options for a module (named after the checkout dir)
> {code}
> 
> 
>   
> 
>   
> 
>   
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Created] (CASSANDRA-15738) Generate compiler options file to support Java11 in IDEA.

[Jon Meredith (Jira)]

Jon Meredith created CASSANDRA-15738:


 Summary: Generate compiler options file to support Java11 in IDEA.
 Key: CASSANDRA-15738
 URL: https://issues.apache.org/jira/browse/CASSANDRA-15738
 Project: Cassandra
  Issue Type: Bug
  Components: Build
Reporter: Jon Meredith
Assignee: Jon Meredith


The change to JMX in CASSANDRA-15653 prevents the generated IDEA project from 
compiling under JDK11.

Fix by adding options for a module (named after the checkout dir)

{code}


  

  

  
{code}




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 4/17/20, 10:51 PM:


Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
the problem conversion explained below, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already have it actually 
>with Integer and String parameters, just they are not many so it didn't byte 
>us up to now. Not sure whether this was considered when the Config class was 
>built or not.

So the issue with int parameters in Config in my solution is:
Currently in trunk, when we parse to int variable, If a parameter is commented 
in the cassandra.yaml, this is observed as null and it will raise an exception 
in some cases. (i.e. commitlog_sync_period_in_ms) But if it is not commented, 
just not assigned a value, then this is considered as 0 (as we parse to int). 
The situation is different with String, Integer. They will be in both cases 
null. No differentiator. But currently we don't have many parameters being 
Integer and String and it didn't byte us.
Now with the units attached to the parameters in the cassandra.yaml file, we 
need to parse strings with snakeyaml and then convert to the proper int values 
in Config.  

A way to cope with this issue is to make the users use "". In this way, if we 
have a parameter not commented, but not also having an assigned value in 
cassandra.yaml, we can identify it by checking a string for being empty. If the 
parameter is commented or not presented, it will be null. But this would be one 
more new thing for the users to consider. That's why I came back to snakeyaml 
again and tried to think of a different way utilizing it. Unfortunately, up to 
now I didn't find any different solution. Also, the links to the examples in 
the official snakeyaml documentation are broken. Not sure whether there they 
had some interesting stuff. Maybe something with customized constructor but 
also, I try to make as less as possible disruptive changes in the codebase in 
order not to mess up something with the Config which might be extremely 
unpleasant.

I will be happy to hear an experienced opinion here. Does anyone know a better 
solution? Or are we ok to introduce  "" in the yaml for empty 
parameters/Strings recognition?

[Part1|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-2] 
(This part was already revised by [~dcapwell] but I paste the explanation again 
here for completeness).
 - New cassandra.yaml ---> currently cassandra-new.yaml in the branch as I 
wanted to test the backward compatibility on the old version (will have to 
rename properly also these yaml files with version probably)
reorganization of the file renames to make the names more consistent
- Backward compatibility with the old names - my approach is:
Cassandra comes with the new version of the yaml to ensure any new builds will 
be using it
During load of the yaml file I check whether old names are identified(means 
someone upgraded to 4 and wants to still use the old yaml). If this is the 
case, we load the values from the old yaml to the new variables (the already 
renamed parameters). Also, there is a warning to the user that there is new 
cassandra.yaml version and he/she can consider an update. 

[Part2|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3] 
- units added to the values in the cassandra.yaml file. Parsing and unit 
conversion in place. One unit test added, should be further developed. 

[DTests|https://github.com/ekaterinadimitrova2/cassandra-dtest] updated 
accordingly for v.4

[Part3|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] 
- SysProperties class, accessors, hope I didn't miss anything... most of them 
are actually just using System.getProperty method.
TO DO: Extract the parser/converter in a separate class from Config

[~mck]? [~dcapwell]? [~benedict]?  Anyone else any thoughts here?

NOTE: The branches are not fully cleared, this is still work in progress but we 
need to take a decision on the String issue first, I think.


was (Author: e.dimitrova):
Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
the problem conversion explained below, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the 

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 4/17/20, 10:50 PM:


Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
the problem conversion explained below, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already have it actually 
>with Integer and String parameters, just they are not many so it didn't byte 
>us up to now. Not sure whether this was considered when the Config class was 
>built or not.

So the issue with int parameters in Config in my solution is:
Currently in trunk, when we parse to int variable, If a parameter is commented 
in the cassandra.yaml, this is observed as null and it will raise an exception 
in some cases. (i.e. commitlog_sync_period_in_ms) But if it is not commented, 
just not assigned a value, then this is considered as 0 (as we parse to int). 
The situation is different with String, Integer. They will be in both cases 
null. No differentiator. But currently we don't have many parameters being 
Integer and String and it didn't byte us.
Now with the units attached to the parameters in the cassandra.yaml file, we 
need to parse strings with snakeyaml and then convert to the proper int values 
in Config.  

A way to cope with this issue is to make the users use "". In this way, if we 
have a parameter not commented, but not also having an assigned value in 
cassandra.yaml, we can identify it by checking a string for being empty. If the 
parameter is commented or not presented, it will be null. But this would be one 
more new thing for the users to consider. That's why I came back to snakeyaml 
again and tried to think of a different way utilizing it. Unfortunately, up to 
now I didn't find any different solution. Also, the links to the examples in 
the official snakeyaml documentation are broken. Not sure whether there they 
had some interesting stuff. Maybe something with customized constructor but 
also, I try to make as less as possible disruptive changes in the codebase in 
order not to mess up something with the Config which might be extremely 
unpleasant.

I will be happy to hear an experienced opinion here. Does anyone know a better 
solution? Or are we ok to introduce  "" in the yaml for empty 
parameters/Strings recognition?

[Part1|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-2] 
(This part was already revised by [~dcapwell] but I paste the explanation again 
here for completeness).
 - New cassandra.yaml ---> currently cassandra-new.yaml in the branch as I 
wanted to test the backward compatibility on the old version (will have to 
rename properly also these yaml files with version probably)
reorganization of the file renames to make the names more consistent
- Backward compatibility with the old names - my approach is:
Cassandra comes with the new version of the yaml to ensure any new builds will 
be using it
During load of the yaml file I check whether old names are identified(means 
someone upgraded to 4 and wants to still use the old yaml). If this is the 
case, we load the values from the old yaml to the new variables (the already 
renamed parameters). Also, there is a warning to the user that there is new 
cassandra.yaml version and he/she can consider an update. 

[Part2|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3] 
- units added to the values in the cassandra.yaml file. Parsing and unit 
conversion in place. One unit test added, should be further developed. 

[DTests|https://github.com/ekaterinadimitrova2/cassandra-dtest] updated 
accordingly for v.4

[Part3|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] 
- SysProperties class, accessors, hope I didn't miss anything... most of them 
are actually just using System.getProperty method.
TO DO: Extract the parser/converter in a separate class from Config

[~mck]? [~dcapwell]? [~benedict]?  Anyone else any thoughts here?

NOTE: The branches are not fully cleared, this is still work in progress


was (Author: e.dimitrova):
Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
the problem conversion explained below, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already 

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 4/17/20, 10:46 PM:


Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
the problem conversion explained below, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already have it actually 
>with Integer and String parameters, just they are not many so it didn't byte 
>us up to now. Not sure whether this was considered when the Config class was 
>built or not.

So the issue with int parameters in Config in my solution is:
Currently in trunk, when we parse to int variable, If a parameter is commented 
in the cassandra.yaml, this is observed as null and it will raise an exception 
in some cases. (i.e. commitlog_sync_period_in_ms) But if it is not commented, 
just not assigned a value, then this is considered as 0 (as we parse to int). 
The situation is different with String, Integer. They will be in both cases 
null. No differentiator. But currently we don't have many parameters being 
Integer and String and it didn't byte us.
Now with the units attached to the parameters in the cassandra.yaml file, we 
need to parse strings with snakeyaml and then convert to the proper int values 
in Config.  

A way to cope with this issue is to make the users use "". In this way, if we 
have a parameter not commented, but not also having an assigned value in 
cassandra.yaml, we can identify it by checking a string for being empty. If the 
parameter is commented or not presented, it will be null. But this would be one 
more new thing for the users to consider. That's why I came back to snakeyaml 
again and tried to think of a different way utilizing it. Unfortunately, up to 
now I didn't find any different solution. Also, the links to the examples in 
the official snakeyaml documentation are broken. Not sure whether there they 
had some interesting stuff. Maybe something with customized constructor but 
also, I try to make as less as possible disruptive changes in the codebase in 
order not to mess up something with the Config which might be extremely 
unpleasant.

I will be happy to hear an experienced opinion here. Does anyone know a better 
solution? Or are we ok to introduce  "" in the yaml for empty 
parameters/Strings recognition?

[Part1|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-2] 
(This part was already revised by [~dcapwell] but I paste the explanation again 
here for completeness).
 - New cassandra.yaml ---> currently cassandra-new.yaml in the branch as I 
wanted to test the backward compatibility on the old version (will have to 
rename properly also these yaml files with version probably)
reorganization of the file renames to make the names more consistent
- Backward compatibility with the old names - my approach is:
Cassandra comes with the new version of the yaml to ensure any new builds will 
be using it
During load of the yaml file I check whether old names are identified(means 
someone upgraded to 4 and wants to still use the old yaml). If this is the 
case, we load the values from the old yaml to the new variables (the already 
renamed parameters). Also, there is a warning to the user that there is new 
cassandra.yaml version and he/she can consider an update. 

[Part2|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3] 
- units added to the values in the cassandra.yaml file. Parsing and unit 
conversion in place. One unit test added, should be further developed. 

[DTests|https://github.com/ekaterinadimitrova2/cassandra-dtest] updated 
accordingly for v.4

[Part3|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] 
- SysProperties class, accessors, hope I didn't miss anything... most of them 
are actually just using 
TO DO: Extract the parser/converter in a separate class from Config

[~mck]? [~dcapwell]? [~benedict]?  Anyone else any thoughts here?

NOTE: The branches are not fully cleared, this is still work in progress


was (Author: e.dimitrova):
Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
this conversion, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already have it actually 
>with Integer and String 

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 4/17/20, 10:45 PM:


Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
this conversion, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already have it actually 
>with Integer and String parameters, just they are not many so it didn't byte 
>us up to now. Not sure whether this was considered when the Config class was 
>built or not.

So the issue with int parameters in Config in my solution is:
Currently in trunk, when we parse to int variable, If a parameter is commented 
in the cassandra.yaml, this is observed as null and it will raise an exception 
in some cases. (i.e. commitlog_sync_period_in_ms) But if it is not commented, 
just not assigned a value, then this is considered as 0 (as we parse to int). 
The situation is different with String, Integer. They will be in both cases 
null. No differentiator. But currently we don't have many parameters being 
Integer and String and it didn't byte us.
Now with the units attached to the parameters in the cassandra.yaml file, we 
need to parse strings with snakeyaml and then convert to the proper int values 
in Config.  

A way to cope with this issue is to make the users use "". In this way, if we 
have a parameter not commented, but not also having an assigned value in 
cassandra.yaml, we can identify it by checking a string for being empty. If the 
parameter is commented or not presented, it will be null. But this would be one 
more new thing for the users to consider. That's why I came back to snakeyaml 
again and tried to think of a different way utilizing it. Unfortunately, up to 
now I didn't find any different solution. Also, the links to the examples in 
the official snakeyaml documentation are broken. Not sure whether there they 
had some interesting stuff. Maybe something with customized constructor but 
also, I try to make as less as possible disruptive changes in the codebase in 
order not to mess up something with the Config which might be extremely 
unpleasant.

I will be happy to hear an experienced opinion here. Does anyone know a better 
solution? Or are we ok to introduce  "" in the yaml for empty 
parameters/Strings recognition?

[Part1|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-2] 
(This part was already revised by [~dcapwell] but I paste the explanation again 
here for completeness).
 - New cassandra.yaml ---> currently cassandra-new.yaml in the branch as I 
wanted to test the backward compatibility on the old version (will have to 
rename properly also these yaml files with version probably)
reorganization of the file renames to make the names more consistent
- Backward compatibility with the old names - my approach is:
Cassandra comes with the new version of the yaml to ensure any new builds will 
be using it
During load of the yaml file I check whether old names are identified(means 
someone upgraded to 4 and wants to still use the old yaml). If this is the 
case, we load the values from the old yaml to the new variables (the already 
renamed parameters). Also, there is a warning to the user that there is new 
cassandra.yaml version and he/she can consider an update. 

[Part2|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3] 
- units added to the values in the cassandra.yaml file. Parsing and unit 
conversion in place. One unit test added, should be further developed. 

[DTests|https://github.com/ekaterinadimitrova2/cassandra-dtest] updated 
accordingly for v.4

[Part3|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] 
- SysProperties class, accessors, hope I didn't miss anything... most of them 
are actually just using 
TO DO: Extract the parser/converter in a separate class from Config

[~mck]? [~dcapwell]? [~benedict]?  Anyone else any thoughts here?

NOTE: The branches are not fully cleared, this is still work in progress


was (Author: e.dimitrova):
Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
this conversion, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already have it actually 
>with Integer and String parameters, just they are not 

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 4/17/20, 10:44 PM:


Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
this conversion, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already have it actually 
>with Integer and String parameters, just they are not many so it didn't byte 
>us up to now. Not sure whether this was considered when the Config class was 
>built or not.

So the issue with int parameters in Config in my solution is:
Currently in trunk, when we parse to int variable, If a parameter is commented 
in the cassandra.yaml, this is observed as null and it will raise an exception 
in some cases. (i.e. commitlog_sync_period_in_ms) But if it is not commented, 
just not assigned a value, then this is considered as 0 (as we parse to int). 
The situation is different with String, Integer. They will be in both cases 
null. No differentiator. But we don't have many parameters being Integer and 
String and it didn't byte us.
Now with the units attached to the parameters in the cassandra.yaml file, we 
need to parse strings with snakeyaml and then convert to the proper int values 
in Config.  

A way to cope with this issue is to make the users use "". In this way, if we 
have a parameter not commented, but not also having an assigned value in 
cassandra.yaml, we can identify it by checking a string for being empty. If the 
parameter is commented or not presented, it will be null. But this would be one 
more new thing for the users to consider. That's why I came back to snakeyaml 
again and tried to think of a different way utilizing it. Unfortunately, up to 
now I didn't find any different solution. Also, the links to the examples in 
the official snakeyaml documentation are broken. Not sure whether there they 
had some interesting stuff. Maybe something with customized constructor but 
also, I try to make as less as possible disruptive changes in the codebase in 
order not to mess up something with the Config which might be extremely 
unpleasant.

I will be happy to hear an experienced opinion here. Does anyone know a better 
solution? Or are we ok to introduce  "" in the yaml for empty 
parameters/Strings recognition?

[Part1|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-2] 
(This part was already revised by [~dcapwell] but I paste the explanation again 
here for completeness).
 - New cassandra.yaml ---> currently cassandra-new.yaml in the branch as I 
wanted to test the backward compatibility on the old version (will have to 
rename properly also these yaml files with version probably)
reorganization of the file renames to make the names more consistent
- Backward compatibility with the old names - my approach is:
Cassandra comes with the new version of the yaml to ensure any new builds will 
be using it
During load of the yaml file I check whether old names are identified(means 
someone upgraded to 4 and wants to still use the old yaml). If this is the 
case, we load the values from the old yaml to the new variables (the already 
renamed parameters). Also, there is a warning to the user that there is new 
cassandra.yaml version and he/she can consider an update. 

[Part2|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3] 
- units added to the values in the cassandra.yaml file. Parsing and unit 
conversion in place. One unit test added, should be further developed. 

[DTests|https://github.com/ekaterinadimitrova2/cassandra-dtest] updated 
accordingly for v.4

[Part3|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] 
- SysProperties class, accessors, hope I didn't miss anything... most of them 
are actually just using 
TO DO: Extract the parser/converter in a separate class from Config

[~mck]? [~dcapwell]? [~benedict]?  Anyone else any thoughts here?

NOTE: The branches are not fully cleared, this is still work in progress


was (Author: e.dimitrova):
Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
this conversion, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already have it actually 
>with Integer and String parameters, just they are not many so 

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 4/17/20, 10:43 PM:


Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
this conversion, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already have it actually 
>with Integer and String parameters, just they are not many so it didn't byte 
>us up to now. Not sure whether this was considered when the Config class was 
>built or not.

So the issue with int parameters in Config in my solution is:
Currently in trunk, when we parse to int variable, If a parameter is commented 
in the cassandra.yaml, this is observed as null and it will raise an exception 
in some cases. (i.e. commitlog_sync_period_in_ms) But if it is not commented, 
just not assigned a value, then this is considered as 0 (as we parse to int). 
The situation is different with String, Integer. They will be in both cases 
null. No differentiator. But we don't have many parameters being Integer and 
String and it didn't byte us.
Now with the units attached to the parameters in the cassandra.yaml file, we 
need to parse strings with snakeyaml and then convert to the proper int values 
in Config.  

A way to cope with this issue is to make the users use "". In this way, if we 
have a parameter not commented, but not also having an assigned value in 
cassandra.yaml, we can identify it by checking a string for being empty. If the 
parameter is commented or not presented, it will be null. But this would be one 
more new thing for the users to consider. That's why I came back to snakeyaml 
again and tried to think of a different way utilizing it. Unfortunately, up to 
now I didn't find any different solution. Also, the links to the examples in 
the official snakeyaml documentation are broken. Not sure whether there they 
had some interesting stuff. Maybe something with customized constructor but 
also, I try to make as less as possible disruptive changes in the codebase in 
order not to mess up something with the Config which might be extremely 
unpleasant.

I will be happy to hear an experienced opinion here. Does anyone know a better 
solution? Or are we ok to introduce  "" in the yaml for empty 
parameters/Strings recognition?

[Part1|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-2] 
(This part was already revised by [~dcapwell]David but I paste the explanation 
again here for completeness).
 - New cassandra.yaml ---> currently cassandra-new.yaml in the branch as I 
wanted to test the backward compatibility on the old version (will have to 
rename properly also these yaml files with version probably)
reorganization of the file renames to make the names more consistent
- Backward compatibility with the old names - my approach is:
Cassandra comes with the new version of the yaml to ensure any new builds will 
be using it
During load of the yaml file I check whether old names are identified(means 
someone upgraded to 4 and wants to still use the old yaml). If this is the 
case, we load the values from the old yaml to the new variables (the already 
renamed parameters). Also, there is a warning to the user that there is new 
cassandra.yaml version and he/she can consider an update. 

[Part2|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3] 
- units added to the values in the cassandra.yaml file. Parsing and unit 
conversion in place. One unit test added, should be further developed. 

[DTests|https://github.com/ekaterinadimitrova2/cassandra-dtest] updated 
accordingly for v.4

[Part3|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] 
- SysProperties class, accessors, hope I didn't miss anything... most of them 
are actually just using 
TO DO: Extract the parser/converter in a separate class from Config

[~mck]? [~dcapwell]? [~benedict]?  Anyone else any thoughts here?


was (Author: e.dimitrova):
Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
this conversion, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already have it actually 
>with Integer and String parameters, just they are not many so it didn't byte 
>us up to now. Not sure whether this was considered 

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 4/17/20, 10:43 PM:


Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
this conversion, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already have it actually 
>with Integer and String parameters, just they are not many so it didn't byte 
>us up to now. Not sure whether this was considered when the Config class was 
>built or not.

So the issue with int parameters in Config in my solution is:
Currently in trunk, when we parse to int variable, If a parameter is commented 
in the cassandra.yaml, this is observed as null and it will raise an exception 
in some cases. (i.e. commitlog_sync_period_in_ms) But if it is not commented, 
just not assigned a value, then this is considered as 0 (as we parse to int). 
The situation is different with String, Integer. They will be in both cases 
null. No differentiator. But we don't have many parameters being Integer and 
String and it didn't byte us.
Now with the units attached to the parameters in the cassandra.yaml file, we 
need to parse strings with snakeyaml and then convert to the proper int values 
in Config.  

A way to cope with this issue is to make the users use "". In this way, if we 
have a parameter not commented, but not also having an assigned value in 
cassandra.yaml, we can identify it by checking a string for being empty. If the 
parameter is commented or not presented, it will be null. But this would be one 
more new thing for the users to consider. That's why I came back to snakeyaml 
again and tried to think of a different way utilizing it. Unfortunately, up to 
now I didn't find any different solution. Also, the links to the examples in 
the official snakeyaml documentation are broken. Not sure whether there they 
had some interesting stuff. Maybe something with customized constructor but 
also, I try to make as less as possible disruptive changes in the codebase in 
order not to mess up something with the Config which might be extremely 
unpleasant.

I will be happy to hear an experienced opinion here. Does anyone know a better 
solution? Or are we ok to introduce  "" in the yaml for empty 
parameters/Strings recognition?

[Part1|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-2] 
(This part was already revised by [~dcapwell]David but I paste the explanation 
again here for completeness).
 - New cassandra.yaml ---> currently cassandra-new.yaml in the branch as I 
wanted to test the backward compatibility on the old version (will have to 
rename properly also these yaml files with version probably)
reorganization of the file renames to make the names more consistent
- Backward compatibility with the old names - my approach is:
Cassandra comes with the new version of the yaml to ensure any new builds will 
be using it
During load of the yaml file I check whether old names are identified(means 
someone upgraded to 4 and wants to still use the old yaml). If this is the 
case, we load the values from the old yaml to the new variables (the already 
renamed parameters). Also, there is a warning to the user that there is new 
cassandra.yaml version and he/she can consider an update. 

[Part2|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3] 
- units added to the values in the cassandra.yaml file. Parsing and unit 
conversion in place. One unit test added, should be further developed. 

[DTests|https://github.com/ekaterinadimitrova2/cassandra-dtest] updated 
accordingly for v.4

[Part3|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] 
- SysProperties class, accessors, hope I didn't miss anything... most of them 
are actually just using 
TO DO: Extract the parser/converter in a separate class from Config

[~mck]? [~dcapwell]? [~benedict]?  Anyone else any thoughts here?

NOTE: The branches are not fully cleared, this is still work in progress


was (Author: e.dimitrova):
Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
this conversion, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already have it actually 
>with Integer and String parameters, just they are not many 

[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova commented on CASSANDRA-15234:
-

Done but with one caveat which was caught thankfully with the DTests. Unit 
tests were even on 100% green at some runs. (And my unit test was not covering 
this conversion, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who 
has the experience proves me wrong.
>From the DTest failures I realized that turning into Strings the values from 
>the YAML we hit one issue. To me it looks like we already have it actually 
>with Integer and String parameters, just they are not many so it didn't byte 
>us up to now. Not sure whether this was considered when the Config class was 
>built or not.

So the issue with int parameters in Config in my solution is:
Currently in trunk, when we parse to int variable, If a parameter is commented 
in the cassandra.yaml, this is observed as null and it will raise an exception 
in some cases. (i.e. commitlog_sync_period_in_ms) But if it is not commented, 
just not assigned a value, then this is considered as 0 (as we parse to int). 
The situation is different with String, Integer. They will be in both cases 
null. No differentiator. But we don't have many parameters being Integer and 
String and it didn't byte us.
Now with the units attached to the parameters in the cassandra.yaml file, we 
need to parse strings with snakeyaml and then convert to the proper int values 
in Config.  

A way to cope with this issue is to make the users use "". In this way, if we 
have a parameter not commented, but not also having an assigned value in 
cassandra.yaml, we can identify it by checking a string for being empty. If the 
parameter is commented or not presented, it will be null. But this would be one 
more new thing for the users to consider. That's why I came back to snakeyaml 
again and tried to think of a different way utilizing it. Unfortunately, up to 
now I didn't find any different solution. Also, the links to the examples in 
the official snakeyaml documentation are broken. Not sure whether there they 
had some interesting stuff. Maybe something with customized constructor but 
also, I try to make as less as possible disruptive changes in the codebase in 
order not to mess up something with the Config which might be extremely 
unpleasant.

I will be happy to hear an experienced opinion here. Does anyone know a better 
solution? Or are we ok to introduce  "" in the yaml for empty 
parameters/Strings recognition?

[Part1|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-2] 
(This part was already revised by [~dcapwell]David but I paste the explanation 
again here for completeness).
 - New cassandra.yaml ---> currently cassandra-new.yaml in the branch as I 
wanted to test the backward compatibility on the old version (will have to 
rename properly also these yaml files with version probably)
reorganization of the file renames to make the names more consistent
- Backward compatibility with the old names - my approach is:
Cassandra comes with the new version of the yaml to ensure any new builds will 
be using it
During load of the yaml file I check whether old names are identified(means 
someone upgraded to 4 and wants to still use the old yaml). If this is the 
case, we load the values from the old yaml to the new variables (the already 
renamed parameters). Also, there is a warning to the user that there is new 
cassandra.yaml version and he/she can consider an update. 
[Part2|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3] 
- units added to the values in the cassandra.yaml file. Parsing and unit 
conversion in place. One unit test added, should be further developed. 
[DTests|https://github.com/ekaterinadimitrova2/cassandra-dtest] updated 
accordingly for v.4
[Part3|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] 
- SysProperties class, accessors, hope I didn't miss anything... most of them 
are actually just using 
TO DO: Extract the parser/converter in a separate class from Config

[~mck]? [~dcapwell]? [~benedict]?  Anyone else any thoughts here?

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of 

[jira] [Comment Edited] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names

[Adam Holmberg (Jira)]

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

Adam Holmberg edited comment on CASSANDRA-15663 at 4/17/20, 5:46 PM:
-

I think it's still a good idea to get the Python driver updated for 4.0 
_somewhere_. Driver 3.23 has some unrelated updates for 4.0 (parsing transient 
replica options, for example). Does it make sense to just finish this 
independent of CASSANDRA-14825?


was (Author: aholmber):
I think it's still a good idea to get the Python driver updated for 4.0 
_somewhere_. There are some unrelated updates for 4.0 (parsing transient 
replica options, for example). Does it make sense to just finish this 
independent of CASSANDRA-14825?

> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 3.11.x, 4.0-alpha
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy', 
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
>  id text PRIMARY KEY,
>  data text,
>  etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
>  id text PRIMARY KEY,
>  data text,
>  etag text
> ) WITH [..]
> {code}
>  If you try to run {{CREATE TABLE test1.default [..]}} you will get an error 
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE 
> TABLE test1.[default]...)
> Oskar Liljeblad
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names

[Adam Holmberg (Jira)]

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

Adam Holmberg commented on CASSANDRA-15663:
---

I think it's still a good idea to get the Python driver updated for 4.0 
_somewhere_. There are some unrelated updates for 4.0 (parsing transient 
replica options, for example). Does it make sense to just finish this 
independent of CASSANDRA-14825?

> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 3.11.x, 4.0-alpha
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy', 
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
>  id text PRIMARY KEY,
>  data text,
>  etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
>  id text PRIMARY KEY,
>  data text,
>  etag text
> ) WITH [..]
> {code}
>  If you try to run {{CREATE TABLE test1.default [..]}} you will get an error 
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE 
> TABLE test1.[default]...)
> Oskar Liljeblad
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Created] (CASSANDRASC-15) Set up sidecar docs

[Jon Haddad (Jira)]

Jon Haddad created CASSANDRASC-15:
-

 Summary:  Set up sidecar docs
 Key: CASSANDRASC-15
 URL: https://issues.apache.org/jira/browse/CASSANDRASC-15
 Project: Sidecar for Apache Cassandra
  Issue Type: Improvement
  Components: Documentation
Reporter: Jon Haddad
Assignee: Jon Haddad


Sidecar lacks user and developer documentation.  We’ll set up both using 
asciidoctor and the gradle plugin to generate HTML and PDF docs, and provide 
initial documentation with code guidelines and user information.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Created] (CASSANDRASC-14) set up sidecar packaging

[Jon Haddad (Jira)]

Jon Haddad created CASSANDRASC-14:
-

 Summary: set up sidecar packaging
 Key: CASSANDRASC-14
 URL: https://issues.apache.org/jira/browse/CASSANDRASC-14
 Project: Sidecar for Apache Cassandra
  Issue Type: Improvement
  Components: Configuration
Reporter: Jon Haddad
Assignee: Jon Haddad


Sidecar will eventually need the ability to generate RPMs, DEB packages and 
Docker images.  Using the ospackage and jib Gradle plugins makes this pretty 
easy and will make adoption easier.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15729) Jenkins Test Results Report in plaintext for ASF ML

[Michael Semb Wever (Jira)]

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

Michael Semb Wever updated CASSANDRA-15729:
---
Summary: Jenkins Test Results Report in plaintext for ASF ML  (was: Jenkins 
Test Results Report in plaintext and emailable)

> Jenkins Test Results Report in plaintext for ASF ML
> ---
>
> Key: CASSANDRA-15729
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15729
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>  Labels: Jenkins
> Fix For: 4.0-beta
>
>
> The Jenkins pipeline builds now aggregate all test reports.
> For example: 
> - https://ci-cassandra.apache.org/job/Cassandra-trunk/68/testReport/
> - 
> https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-trunk/detail/Cassandra-trunk/68/tests
> But Jenkins can only keep a limited amount of build history, so those links 
> are not permanent, can't be used as references, and don't help for bisecting 
> and blame on regressions (and flakey tests) over a longer period of time.
> The builds@ ML can provide a permanent record of test results. 
> This was first brought up in these two threads: 
> - 
> https://lists.apache.org/thread.html/re8122e4fdd8629e7fbca2abf27d72054b3bc0e3690ece8b8e66f618b%40%3Cdev.cassandra.apache.org%3E
> - 
> https://lists.apache.org/thread.html/ra5f6aeea89546825fe7ccc4a80898c62f8ed57decabf709d81d9c720%40%3Cdev.cassandra.apache.org%3E
> An example plaintext report, to demonstrate feasibility, is available here: 
> https://lists.apache.org/thread.html/r80d13f7af706bf8dfbf2387fab46004c1fbd3917b7bc339c49e69aa8%40%3Cbuilds.cassandra.apache.org%3E
> Hurdles:
>  - the ASF mailing lists won't except html, attachments, or any message body 
> over 1MB.
>  - packages are used as a differentiator in the final aggregated report. The 
> cqlsh and dtests currently don't specify it. It needs to be added as a 
> "dot-separated" prefix to the testsuite and testcase name.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15709) SEPExecutorTest changingMaxWorkersMeetsConcurrencyGoalsTest failure

[Jon Meredith (Jira)]

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

Jon Meredith commented on CASSANDRA-15709:
--

I think it's good to merge, as long as you're happy with it and a +1 from a 
non-committer is acceptable.

It just needs these two commits merged (fixup on the second) and the commit 
message updated to record David as the reviewer and you as the merger.
04e45f97377026b92fc42c2dc85633d1c54eac67
596e924a35e5513d9b8e72329f4a897c9631bcb9

I'm happy to do the squash/fixup comments and force-push up to the review 
branch if you'd like

> SEPExecutorTest changingMaxWorkersMeetsConcurrencyGoalsTest failure
> ---
>
> Key: CASSANDRA-15709
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15709
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-alpha
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {code}
> [junit-timeout] Testsuite: org.apache.cassandra.concurrent.SEPExecutorTest
> [junit-timeout] Testsuite: org.apache.cassandra.concurrent.SEPExecutorTest 
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.656 sec
> [junit-timeout] 
> [junit-timeout] Testcase: 
> changingMaxWorkersMeetsConcurrencyGoalsTest(org.apache.cassandra.concurrent.SEPExecutorTest):
>FAILED
> [junit-timeout] expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: expected: but 
> was:
> [junit-timeout]   at 
> org.apache.cassandra.concurrent.SEPExecutorTest.assertMaxTaskConcurrency(SEPExecutorTest.java:180)
> [junit-timeout]   at 
> org.apache.cassandra.concurrent.SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest(SEPExecutorTest.java:110)
> [junit-timeout] 
> [junit-timeout] 
> [junit-timeout] Test org.apache.cassandra.concurrent.SEPExecutorTest FAILED
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15731) cassandra-stress fails when we specify a port per node

[Alan Boudreault (Jira)]

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

Alan Boudreault updated CASSANDRA-15731:

  Workflow: Cassandra Default Workflow  (was: Cassandra Bug Workflow)
Issue Type: New Feature  (was: Bug)

> cassandra-stress fails when we  specify a port per node
> ---
>
> Key: CASSANDRA-15731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15731
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Alan Boudreault
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> {code}
> $ ./tools/bin/cassandra-stress write n=10 -node 127.0.0.1:9046,127.0.0.1:9048
> ...
> java.lang.RuntimeException: java.lang.IllegalArgumentException: Failed to add 
> contact point: 127.0.0.1:9046
>   at 
> org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:148)
>   at 
> org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:116)
>   at 
> org.apache.cassandra.stress.settings.SettingsSchema.createKeySpaces(SettingsSchema.java:66)
>   at 
> org.apache.cassandra.stress.settings.StressSettings.maybeCreateKeyspaces(StressSettings.java:156)
>   at org.apache.cassandra.stress.StressAction.run(StressAction.java:56)
>   at org.apache.cassandra.stress.Stress.run(Stress.java:143)
>   at org.apache.cassandra.stress.Stress.main(Stress.java:62)
> Caused by: java.lang.IllegalArgumentException: Failed to add contact point: 
> 127.0.0.1:9046
>   at 
> com.datastax.driver.core.Cluster$Builder.addContactPoint(Cluster.java:922)
>   at 
> org.apache.cassandra.stress.util.JavaDriverClient.connect(JavaDriverClient.java:131)
>   at 
> org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:139)
>   ... 6 more
> Caused by: java.net.UnknownHostException: 127.0.0.1:9046: invalid IPv6 address
>   at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1341)
>   at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1298)
>   at 
> com.datastax.driver.core.Cluster$Builder.addContactPoint(Cluster.java:919)
>   ... 8 more
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15731) cassandra-stress fails when we specify a port per node

[Alan Boudreault (Jira)]

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

Alan Boudreault updated CASSANDRA-15731:

Fix Version/s: (was: 4.0-beta)
   4.x

> cassandra-stress fails when we  specify a port per node
> ---
>
> Key: CASSANDRA-15731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15731
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alan Boudreault
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> {code}
> $ ./tools/bin/cassandra-stress write n=10 -node 127.0.0.1:9046,127.0.0.1:9048
> ...
> java.lang.RuntimeException: java.lang.IllegalArgumentException: Failed to add 
> contact point: 127.0.0.1:9046
>   at 
> org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:148)
>   at 
> org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:116)
>   at 
> org.apache.cassandra.stress.settings.SettingsSchema.createKeySpaces(SettingsSchema.java:66)
>   at 
> org.apache.cassandra.stress.settings.StressSettings.maybeCreateKeyspaces(StressSettings.java:156)
>   at org.apache.cassandra.stress.StressAction.run(StressAction.java:56)
>   at org.apache.cassandra.stress.Stress.run(Stress.java:143)
>   at org.apache.cassandra.stress.Stress.main(Stress.java:62)
> Caused by: java.lang.IllegalArgumentException: Failed to add contact point: 
> 127.0.0.1:9046
>   at 
> com.datastax.driver.core.Cluster$Builder.addContactPoint(Cluster.java:922)
>   at 
> org.apache.cassandra.stress.util.JavaDriverClient.connect(JavaDriverClient.java:131)
>   at 
> org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:139)
>   ... 6 more
> Caused by: java.net.UnknownHostException: 127.0.0.1:9046: invalid IPv6 address
>   at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1341)
>   at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1298)
>   at 
> com.datastax.driver.core.Cluster$Builder.addContactPoint(Cluster.java:919)
>   ... 8 more
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15731) cassandra-stress fails when we specify a port per node

[Alan Boudreault (Jira)]

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

Alan Boudreault commented on CASSANDRA-15731:
-

Just a note to mention that the use of *-port* has a different purpose. It 
allows to specify the port for all nodes. With CASSANDRA-7544, I'd would have 
expected the support for cassandra-stress to support port per node as well. So 
something like this: *-node whitelist 127.0.0.1:9046,127.0.0.1:9048*. However, 
this is definitively not a urgent issue and I'm +1 to change the fixVersion to 
_4.x_. Thanks [~adelapena]

> cassandra-stress fails when we  specify a port per node
> ---
>
> Key: CASSANDRA-15731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15731
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alan Boudreault
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-beta
>
>
> {code}
> $ ./tools/bin/cassandra-stress write n=10 -node 127.0.0.1:9046,127.0.0.1:9048
> ...
> java.lang.RuntimeException: java.lang.IllegalArgumentException: Failed to add 
> contact point: 127.0.0.1:9046
>   at 
> org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:148)
>   at 
> org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:116)
>   at 
> org.apache.cassandra.stress.settings.SettingsSchema.createKeySpaces(SettingsSchema.java:66)
>   at 
> org.apache.cassandra.stress.settings.StressSettings.maybeCreateKeyspaces(StressSettings.java:156)
>   at org.apache.cassandra.stress.StressAction.run(StressAction.java:56)
>   at org.apache.cassandra.stress.Stress.run(Stress.java:143)
>   at org.apache.cassandra.stress.Stress.main(Stress.java:62)
> Caused by: java.lang.IllegalArgumentException: Failed to add contact point: 
> 127.0.0.1:9046
>   at 
> com.datastax.driver.core.Cluster$Builder.addContactPoint(Cluster.java:922)
>   at 
> org.apache.cassandra.stress.util.JavaDriverClient.connect(JavaDriverClient.java:131)
>   at 
> org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:139)
>   ... 6 more
> Caused by: java.net.UnknownHostException: 127.0.0.1:9046: invalid IPv6 address
>   at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1341)
>   at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1298)
>   at 
> com.datastax.driver.core.Cluster$Builder.addContactPoint(Cluster.java:919)
>   ... 8 more
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names

[Benjamin Lerer (Jira)]

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

Benjamin Lerer commented on CASSANDRA-15663:


[~Ge] I am currently reviewing CASSANDRA-14825 that should fix that problem 
as the code will not use the python driver anymore for DESCRIBE.

> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 3.11.x, 4.0-alpha
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy', 
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
>  id text PRIMARY KEY,
>  data text,
>  etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
>  id text PRIMARY KEY,
>  data text,
>  etag text
> ) WITH [..]
> {code}
>  If you try to run {{CREATE TABLE test1.default [..]}} you will get an error 
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE 
> TABLE test1.[default]...)
> Oskar Liljeblad
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15674) liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if IndexSummaryRedistribution gets interrupted

[Marcus Eriksson (Jira)]

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

Marcus Eriksson commented on CASSANDRA-15674:
-

The patch fixes the immediate bug, so +1, but we should really refactor how 
index summary redistribution uses transactions as it is quite broken (not 
really transactional at all), I'll create a new jira for that.

pushed a few updates 
[here|https://github.com/krummas/cassandra/commits/david/15674] - this cleans 
up the test a bit to avoid having to add the metric and the Listener interface 
to IndexSummaryRedistribution


> liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if 
> IndexSummaryRedistribution gets interrupted
> -
>
> Key: CASSANDRA-15674
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15674
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction, Observability/Metrics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> IndexSummaryRedistribution is a compaction task and as such extends Holder 
> and supports cancelation by throwing a CompactionInterruptedException.  The 
> issue is that IndexSummaryRedistribution tries to use transactions, but 
> mutates the sstable in-place; transaction is unable to roll back.
> This would be fine (only updates summary) if it wasn’t for the fact the task 
> attempts to also mutate the two metrics liveDiskSpaceUsed and 
> totalDiskSpaceUsed, since these can’t be rolled back any cancelation could 
> corrupt these metrics.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15709) SEPExecutorTest changingMaxWorkersMeetsConcurrencyGoalsTest failure

[Jira]

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

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

I can commit it if this is reviewed and ready.

> SEPExecutorTest changingMaxWorkersMeetsConcurrencyGoalsTest failure
> ---
>
> Key: CASSANDRA-15709
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15709
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-alpha
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {code}
> [junit-timeout] Testsuite: org.apache.cassandra.concurrent.SEPExecutorTest
> [junit-timeout] Testsuite: org.apache.cassandra.concurrent.SEPExecutorTest 
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.656 sec
> [junit-timeout] 
> [junit-timeout] Testcase: 
> changingMaxWorkersMeetsConcurrencyGoalsTest(org.apache.cassandra.concurrent.SEPExecutorTest):
>FAILED
> [junit-timeout] expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: expected: but 
> was:
> [junit-timeout]   at 
> org.apache.cassandra.concurrent.SEPExecutorTest.assertMaxTaskConcurrency(SEPExecutorTest.java:180)
> [junit-timeout]   at 
> org.apache.cassandra.concurrent.SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest(SEPExecutorTest.java:110)
> [junit-timeout] 
> [junit-timeout] 
> [junit-timeout] Test org.apache.cassandra.concurrent.SEPExecutorTest FAILED
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15731) cassandra-stress fails when we specify a port per node

[Jira]

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

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

If I'm right that syntax is not supported, and the {{-node}} option is meant to 
only accept addresses without port. It is only possible to specify a single 
common port with the {{-port}} option:
{code}
./tools/bin/cassandra-stress write n=10 -port native=9042 -node 
127.0.0.1,127.0.0.2
{code}
I think that being able to somehow specify per-node ports might be useful, but 
since it's a new feature it shouldn't be included in 4.0.

> cassandra-stress fails when we  specify a port per node
> ---
>
> Key: CASSANDRA-15731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15731
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alan Boudreault
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-beta
>
>
> {code}
> $ ./tools/bin/cassandra-stress write n=10 -node 127.0.0.1:9046,127.0.0.1:9048
> ...
> java.lang.RuntimeException: java.lang.IllegalArgumentException: Failed to add 
> contact point: 127.0.0.1:9046
>   at 
> org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:148)
>   at 
> org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:116)
>   at 
> org.apache.cassandra.stress.settings.SettingsSchema.createKeySpaces(SettingsSchema.java:66)
>   at 
> org.apache.cassandra.stress.settings.StressSettings.maybeCreateKeyspaces(StressSettings.java:156)
>   at org.apache.cassandra.stress.StressAction.run(StressAction.java:56)
>   at org.apache.cassandra.stress.Stress.run(Stress.java:143)
>   at org.apache.cassandra.stress.Stress.main(Stress.java:62)
> Caused by: java.lang.IllegalArgumentException: Failed to add contact point: 
> 127.0.0.1:9046
>   at 
> com.datastax.driver.core.Cluster$Builder.addContactPoint(Cluster.java:922)
>   at 
> org.apache.cassandra.stress.util.JavaDriverClient.connect(JavaDriverClient.java:131)
>   at 
> org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:139)
>   ... 6 more
> Caused by: java.net.UnknownHostException: 127.0.0.1:9046: invalid IPv6 address
>   at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1341)
>   at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1298)
>   at 
> com.datastax.driver.core.Cluster$Builder.addContactPoint(Cluster.java:919)
>   ... 8 more
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Assigned] (CASSANDRA-13606) Improve handling of 2i initialization failures

[Sergio Bossa (Jira)]

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

Sergio Bossa reassigned CASSANDRA-13606:


Assignee: (was: Sergio Bossa)

> Improve handling of 2i initialization failures
> --
>
> Key: CASSANDRA-13606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13606
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/2i Index
>Reporter: Sergio Bossa
>Priority: Normal
> Fix For: 4.0
>
>
> CASSANDRA-10130 fixes the 2i build management, but initialization failures 
> are still not properly handled, most notably because:
> * Initialization failures make the index non-queryable, but it can still be 
> written to.
> * Initialization failures can be recovered via full rebuilds.
> Both points above are probably suboptimal because the initialization logic 
> could be more complex than just an index build, hence it shouldn't be made 
> recoverable via a simple rebuild, and could cause the index to be fully 
> unavailable not just for reads, but for writes as well.
> So, we should better handle initialization failures by:
> * Allowing the index implementation to specify if unavailable for reads, 
> writes, or both. 
> * Providing a proper method to recover, distinct from index rebuilds.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-10130) Node failure during 2i update after streaming can have incomplete 2i when restarted

[Sergio Bossa (Jira)]

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

Sergio Bossa updated CASSANDRA-10130:
-
Reviewers: Paulo Motta, Sergio Bossa  (was: Paulo Motta)

> Node failure during 2i update after streaming can have incomplete 2i when 
> restarted
> ---
>
> Key: CASSANDRA-10130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10130
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Coordination
>Reporter: Yuki Morishita
>Assignee: Andres de la Peña
>Priority: Low
> Fix For: 4.0
>
>
> Since MV/2i update happens after SSTables are received, node failure during 
> MV/2i update can leave received SSTables live when restarted while MV/2i are 
> partially up to date.
> We can add some kind of tracking mechanism to automatically rebuild at the 
> startup, or at least warn user when the node restarts.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15533) Don't allocate unneeded MergeIterator in OnDiskToken#iterator

[Berenguer Blasi (Jira)]

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

Berenguer Blasi commented on CASSANDRA-15533:
-

Hi [~jrwest]  I fancied taking a look at this patch and I ended up reviewing 
it. Be advised I am ramping up on this codebase. LGTM I think you captured all 
the uses of the MergeIterator under the sasi package, I would only remove the 
unused imports left behind. My 2cts :)

> Don't allocate unneeded MergeIterator in OnDiskToken#iterator 
> --
>
> Key: CASSANDRA-15533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15533
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/SASI
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>
> When reviewing CASSANDRA-15392 it became apparent that the MergeIterator 
> allocated by OnDiskToken#iterator is rarely necessary and so we should avoid 
> allocating one when not needed and skip the MergeIterator pool when needed 
> because its unlikely to be sized correctly. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Assigned] (CASSANDRA-15730) Batch statement preparation fails if multiple tables and parameters are used

[Eduard Tudenhoefner (Jira)]

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

Eduard Tudenhoefner reassigned CASSANDRA-15730:
---

Assignee: Bryn Cooke

> Batch statement preparation fails if multiple tables and parameters are used
> 
>
> Key: CASSANDRA-15730
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15730
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Bryn Cooke
>Assignee: Bryn Cooke
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Batch statement preparation fails with an assertion error if multiple tables 
> and parameters are used.
> {{BEGIN BATCH }}
> {{ UPDATE tbl1 SET v1 = 1 WHERE k1 = ?}}
> {{ UPDATE tbl2 SET v2 = 2 WHERE k2 = ?}}
> {{APPLY BATCH}}
> The logic for affectsMultipleTables 
> [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144]
>  looks inverted
>  This later causes an assertion failure 
> [here|https://github.com/apache/cassandra/blob/24c8a21c1c131abd89c6b646343ff098d1b3263b/src/java/org/apache/cassandra/cql3/VariableSpecifications.java#L75]
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15730) Batch statement preparation fails if multiple tables and parameters are used

[Michael Semb Wever (Jira)]

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

Michael Semb Wever commented on CASSANDRA-15730:


||branch||circleci||jenkins||
|[trunk_15730|https://github.com/apache/cassandra/compare/trunk...BrynCooke:CASSANDRA-15730-trunk]|[circleci|https://circleci.com/gh/BrynCooke/workflows/cassandra/tree/CASSANDRA-15730-trunk]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/64/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/64]|

> Batch statement preparation fails if multiple tables and parameters are used
> 
>
> Key: CASSANDRA-15730
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15730
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Bryn Cooke
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Batch statement preparation fails with an assertion error if multiple tables 
> and parameters are used.
> {{BEGIN BATCH }}
> {{ UPDATE tbl1 SET v1 = 1 WHERE k1 = ?}}
> {{ UPDATE tbl2 SET v2 = 2 WHERE k2 = ?}}
> {{APPLY BATCH}}
> The logic for affectsMultipleTables 
> [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144]
>  looks inverted
>  This later causes an assertion failure 
> [here|https://github.com/apache/cassandra/blob/24c8a21c1c131abd89c6b646343ff098d1b3263b/src/java/org/apache/cassandra/cql3/VariableSpecifications.java#L75]
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15736) Fix Python SyntaxWarning: "is not" with a literal. Did you mean "!="

[Michael Semb Wever (Jira)]

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

Michael Semb Wever updated CASSANDRA-15736:
---
Source Control Link: 
https://github.com/apache/cassandra-dtest/commit/9ec133b2f728ef0dd9d5995af61a0ef61dc47525
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed as 9ec133b2f728ef0dd9d5995af61a0ef61dc47525

> Fix Python SyntaxWarning: "is not" with a literal. Did you mean "!="
> 
>
> Key: CASSANDRA-15736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15736
> Project: Cassandra
>  Issue Type: Task
>  Components: Test/dtest
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-alpha
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> With the upgrade to Python 3.8 there are SyntaxWarnings now showing up in the 
> tests, which should be fixed.
> {code}
> /home/cassandra/cassandra/cassandra-dtest/conftest.py:207: SyntaxWarning: "is 
> not" with a literal. Did you mean "!="?
>   if len(errors) is not 0:
> /home/cassandra/cassandra/cassandra-dtest/conftest.py:240: SyntaxWarning: "is 
> not" with a literal. Did you mean "!="?
>   if len(logs) is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:393: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   while attempt < 3 and ret_val is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:399: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   if ret_val is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:422: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   if ret_val is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:425: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   if ret_val is not 0:
> /home/cassandra/cassandra/cassandra-dtest/dtest_setup.py:124: SyntaxWarning: 
> "is not" with a literal. Did you mean "!="?
>   if len(filtered_errors) is not 0:
> /home/cassandra/cassandra/cassandra-dtest/dtest_setup.py:152: SyntaxWarning: 
> "is not" with a literal. Did you mean "!="?
>   if len(logs) is not 0:
> /home/cassandra/cassandra/cassandra-dtest/dtest_setup.py:286: SyntaxWarning: 
> "is not" with a literal. Did you mean "!="?
>   if len(errors) is not 0:
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[cassandra-dtest] branch master updated: Fix SyntaxWarnings with Python3.8

[mck]

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

mck pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git


The following commit(s) were added to refs/heads/master by this push:
 new 9ec133b  Fix SyntaxWarnings with Python3.8
9ec133b is described below

commit 9ec133b2f728ef0dd9d5995af61a0ef61dc47525
Author: Eduard Tudenhoefner 
AuthorDate: Thu Apr 16 10:18:29 2020 +0200

Fix SyntaxWarnings with Python3.8

 patch by Eduard Tudenhöfner; reviewed by Mick Semb Wever for 
CASSANDRA-15736
---
 conftest.py| 4 ++--
 dtest_setup.py | 6 +++---
 upgrade_tests/cql_tests.py | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/conftest.py b/conftest.py
index 0229ae0..7cc3acc 100644
--- a/conftest.py
+++ b/conftest.py
@@ -209,7 +209,7 @@ def check_logs_for_errors(dtest_setup):
 errors = []
 for node in dtest_setup.cluster.nodelist():
 errors = list(_filter_errors(dtest_setup, ['\n'.join(msg) for msg in 
node.grep_log_for_errors()]))
-if len(errors) is not 0:
+if len(errors) != 0:
 for error in errors:
 if isinstance(error, (bytes, bytearray)):
 error_str = error.decode("utf-8").strip()
@@ -242,7 +242,7 @@ def copy_logs(request, cluster, directory=None, name=None):
 os.mkdir(directory)
 logs = [(node.name, node.logfilename(), node.debuglogfilename(), 
node.gclogfilename(), node.compactionlogfilename())
 for node in list(cluster.nodes.values())]
-if len(logs) is not 0:
+if len(logs) != 0:
 basedir = str(int(time.time() * 1000)) + '_' + request.node.name
 logdir = os.path.join(directory, basedir)
 os.mkdir(logdir)
diff --git a/dtest_setup.py b/dtest_setup.py
index 107028d..abc50b5 100644
--- a/dtest_setup.py
+++ b/dtest_setup.py
@@ -121,7 +121,7 @@ class DTestSetup(object):
 
 for nodename, errors in list(errordata.items()):
 filtered_errors = list(self.__filter_errors(['\n'.join(msg) for 
msg in errors]))
-if len(filtered_errors) is not 0:
+if len(filtered_errors) != 0:
 reportable_errordata[nodename] = filtered_errors
 
 # no errors worthy of halting the test
@@ -149,7 +149,7 @@ class DTestSetup(object):
 logs = [(node.name, node.logfilename(), node.debuglogfilename(), 
node.gclogfilename(),
  node.compactionlogfilename())
 for node in self.cluster.nodelist()]
-if len(logs) is not 0:
+if len(logs) != 0:
 basedir = str(int(time.time() * 1000)) + '_' + str(id(self))
 logdir = os.path.join(directory, basedir)
 os.mkdir(logdir)
@@ -283,7 +283,7 @@ class DTestSetup(object):
 for node in self.cluster.nodelist():
 errors = list(self.__filter_errors(
 ['\n'.join(msg) for msg in node.grep_log_for_errors()]))
-if len(errors) is not 0:
+if len(errors) != 0:
 for error in errors:
 print("Unexpected error in {node_name} log, error: 
\n{error}".format(node_name=node.name, error=error))
 return True
diff --git a/upgrade_tests/cql_tests.py b/upgrade_tests/cql_tests.py
index d3475a3..4bb9630 100644
--- a/upgrade_tests/cql_tests.py
+++ b/upgrade_tests/cql_tests.py
@@ -1182,7 +1182,7 @@ class TestCQL(UpgradeTester):
 
 cursor.execute("DELETE FROM test WHERE k=2")
 
-assert_all(cursor, "SELECT k FROM test", [[k] for k in range(0, 5) 
if k is not 2], ignore_order=True)
+assert_all(cursor, "SELECT k FROM test", [[k] for k in range(0, 5) 
if k != 2], ignore_order=True)
 
 # Example from #3505
 cursor.execute("USE ks1")


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

[jira] [Updated] (CASSANDRA-15736) Fix Python SyntaxWarning: "is not" with a literal. Did you mean "!="

[Michael Semb Wever (Jira)]

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

Michael Semb Wever updated CASSANDRA-15736:
---
Reviewers: Michael Semb Wever, Michael Semb Wever  (was: Michael Semb Wever)
   Michael Semb Wever, Michael Semb Wever
   Status: Review In Progress  (was: Patch Available)

> Fix Python SyntaxWarning: "is not" with a literal. Did you mean "!="
> 
>
> Key: CASSANDRA-15736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15736
> Project: Cassandra
>  Issue Type: Task
>  Components: Test/dtest
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-alpha
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> With the upgrade to Python 3.8 there are SyntaxWarnings now showing up in the 
> tests, which should be fixed.
> {code}
> /home/cassandra/cassandra/cassandra-dtest/conftest.py:207: SyntaxWarning: "is 
> not" with a literal. Did you mean "!="?
>   if len(errors) is not 0:
> /home/cassandra/cassandra/cassandra-dtest/conftest.py:240: SyntaxWarning: "is 
> not" with a literal. Did you mean "!="?
>   if len(logs) is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:393: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   while attempt < 3 and ret_val is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:399: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   if ret_val is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:422: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   if ret_val is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:425: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   if ret_val is not 0:
> /home/cassandra/cassandra/cassandra-dtest/dtest_setup.py:124: SyntaxWarning: 
> "is not" with a literal. Did you mean "!="?
>   if len(filtered_errors) is not 0:
> /home/cassandra/cassandra/cassandra-dtest/dtest_setup.py:152: SyntaxWarning: 
> "is not" with a literal. Did you mean "!="?
>   if len(logs) is not 0:
> /home/cassandra/cassandra/cassandra-dtest/dtest_setup.py:286: SyntaxWarning: 
> "is not" with a literal. Did you mean "!="?
>   if len(errors) is not 0:
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15736) Fix Python SyntaxWarning: "is not" with a literal. Did you mean "!="

[Michael Semb Wever (Jira)]

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

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

> Fix Python SyntaxWarning: "is not" with a literal. Did you mean "!="
> 
>
> Key: CASSANDRA-15736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15736
> Project: Cassandra
>  Issue Type: Task
>  Components: Test/dtest
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-alpha
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> With the upgrade to Python 3.8 there are SyntaxWarnings now showing up in the 
> tests, which should be fixed.
> {code}
> /home/cassandra/cassandra/cassandra-dtest/conftest.py:207: SyntaxWarning: "is 
> not" with a literal. Did you mean "!="?
>   if len(errors) is not 0:
> /home/cassandra/cassandra/cassandra-dtest/conftest.py:240: SyntaxWarning: "is 
> not" with a literal. Did you mean "!="?
>   if len(logs) is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:393: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   while attempt < 3 and ret_val is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:399: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   if ret_val is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:422: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   if ret_val is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:425: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   if ret_val is not 0:
> /home/cassandra/cassandra/cassandra-dtest/dtest_setup.py:124: SyntaxWarning: 
> "is not" with a literal. Did you mean "!="?
>   if len(filtered_errors) is not 0:
> /home/cassandra/cassandra/cassandra-dtest/dtest_setup.py:152: SyntaxWarning: 
> "is not" with a literal. Did you mean "!="?
>   if len(logs) is not 0:
> /home/cassandra/cassandra/cassandra-dtest/dtest_setup.py:286: SyntaxWarning: 
> "is not" with a literal. Did you mean "!="?
>   if len(errors) is not 0:
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15734) cqlsh_tests.test_cqlsh.TestCqlsh.test_pycodestyle_compliance fails on trunk

[Michael Semb Wever (Jira)]

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

Michael Semb Wever updated CASSANDRA-15734:
---
Source Control Link: 
https://github.com/apache/cassandra/commit/1de8720b3255e6df4dc6ae747b098c50b1fe1bbc
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed as 1de8720b3255e6df4dc6ae747b098c50b1fe1bbc

> cqlsh_tests.test_cqlsh.TestCqlsh.test_pycodestyle_compliance fails on trunk
> ---
>
> Key: CASSANDRA-15734
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15734
> Project: Cassandra
>  Issue Type: Task
>  Components: Test/dtest
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-alpha
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This recently started to fail with Python 3.8 as can be seen 
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/73/testReport/junit/cqlsh_tests.test_cqlsh/TestCqlsh/test_pycodestyle_compliance/]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15734) cqlsh_tests.test_cqlsh.TestCqlsh.test_pycodestyle_compliance fails on trunk

[Michael Semb Wever (Jira)]

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

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

> cqlsh_tests.test_cqlsh.TestCqlsh.test_pycodestyle_compliance fails on trunk
> ---
>
> Key: CASSANDRA-15734
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15734
> Project: Cassandra
>  Issue Type: Task
>  Components: Test/dtest
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-alpha
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This recently started to fail with Python 3.8 as can be seen 
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/73/testReport/junit/cqlsh_tests.test_cqlsh/TestCqlsh/test_pycodestyle_compliance/]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[cassandra] branch trunk updated: Fix python codestyle warning (and failing test_pycodestyle_compliance)

[mck]

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

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


The following commit(s) were added to refs/heads/trunk by this push:
 new 1de8720  Fix python codestyle warning (and failing 
test_pycodestyle_compliance)
1de8720 is described below

commit 1de8720b3255e6df4dc6ae747b098c50b1fe1bbc
Author: Mick Semb Wever 
AuthorDate: Fri Apr 17 10:47:44 2020 +0200

Fix python codestyle warning (and failing test_pycodestyle_compliance)

 patch by Eduard Tudenhöfner; reviewed by Mick Semb Wever for 
CASSANDRA-15734
Co-authored-by: Eduard Tudenhöfner 
---
 pylib/cqlshlib/saferscanner.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/pylib/cqlshlib/saferscanner.py b/pylib/cqlshlib/saferscanner.py
index 75b5df7..8949321 100644
--- a/pylib/cqlshlib/saferscanner.py
+++ b/pylib/cqlshlib/saferscanner.py
@@ -98,5 +98,6 @@ class Py38SaferScanner(SaferScannerBase):
 self.p = p
 self.scanner = re.sre_compile.compile(p)
 
+
 SaferScanner = Py36SaferScanner if six.PY3 else Py2SaferScanner
 SaferScanner = Py38SaferScanner if version_info >= (3, 8) else SaferScanner


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

[jira] [Updated] (CASSANDRA-15734) cqlsh_tests.test_cqlsh.TestCqlsh.test_pycodestyle_compliance fails on trunk

[Michael Semb Wever (Jira)]

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

Michael Semb Wever updated CASSANDRA-15734:
---
Reviewers: Michael Semb Wever, Michael Semb Wever  (was: Michael Semb Wever)
   Michael Semb Wever, Michael Semb Wever
   Status: Review In Progress  (was: Patch Available)

> cqlsh_tests.test_cqlsh.TestCqlsh.test_pycodestyle_compliance fails on trunk
> ---
>
> Key: CASSANDRA-15734
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15734
> Project: Cassandra
>  Issue Type: Task
>  Components: Test/dtest
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-alpha
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This recently started to fail with Python 3.8 as can be seen 
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/73/testReport/junit/cqlsh_tests.test_cqlsh/TestCqlsh/test_pycodestyle_compliance/]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15736) Fix Python SyntaxWarning: "is not" with a literal. Did you mean "!="

[Eduard Tudenhoefner (Jira)]

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

Eduard Tudenhoefner commented on CASSANDRA-15736:
-

[Run with 
SyntaxWarnings|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/44/consoleText]
[Run without 
SyntaxWarnings|https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest/68/consoleText]

> Fix Python SyntaxWarning: "is not" with a literal. Did you mean "!="
> 
>
> Key: CASSANDRA-15736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15736
> Project: Cassandra
>  Issue Type: Task
>  Components: Test/dtest
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-alpha
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> With the upgrade to Python 3.8 there are SyntaxWarnings now showing up in the 
> tests, which should be fixed.
> {code}
> /home/cassandra/cassandra/cassandra-dtest/conftest.py:207: SyntaxWarning: "is 
> not" with a literal. Did you mean "!="?
>   if len(errors) is not 0:
> /home/cassandra/cassandra/cassandra-dtest/conftest.py:240: SyntaxWarning: "is 
> not" with a literal. Did you mean "!="?
>   if len(logs) is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:393: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   while attempt < 3 and ret_val is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:399: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   if ret_val is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:422: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   if ret_val is not 0:
> /home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:425: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   if ret_val is not 0:
> /home/cassandra/cassandra/cassandra-dtest/dtest_setup.py:124: SyntaxWarning: 
> "is not" with a literal. Did you mean "!="?
>   if len(filtered_errors) is not 0:
> /home/cassandra/cassandra/cassandra-dtest/dtest_setup.py:152: SyntaxWarning: 
> "is not" with a literal. Did you mean "!="?
>   if len(logs) is not 0:
> /home/cassandra/cassandra/cassandra-dtest/dtest_setup.py:286: SyntaxWarning: 
> "is not" with a literal. Did you mean "!="?
>   if len(errors) is not 0:
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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