[jira] [Comment Edited] (CASSANDRA-15339) Make available the known JMX endpoints across the cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-15339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16939641#comment-16939641
]
Michael Semb Wever edited comment on CASSANDRA-15339 at 9/27/19 8:36 PM:
-
wip…
|| branch || circleci || asf jenkins testall || asf jenkins dtests ||
|
[trunk_15339|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15339]
|
[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15339]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/50//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/50/]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/684//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/684]
|
was (Author: mck):
wip…
|| branch || circleci || asf jenkins testall || asf jenkins dtests ||
|
[trunk_15339|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15339]
|
[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15339]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/49//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/49/]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/683//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/683]
|
> Make available the known JMX endpoints across the cluster
> -
>
> Key: CASSANDRA-15339
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15339
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> With the addition of multiple nodes running on the same server using
> different ports: CASSANDRA-7544 ; it becomes more difficult for third-party
> tools to easily connect to all nodes based on the jmx connection details to
> just one node.
> By adding jmx host and port to gossip, and saving it in {{system.peers_v2}},
> the list of all jmx endpoints in a cluster can be fetch after just the
> initial successful jmx connection and the
> {{StorageServiceMBean.getJmxEndpoints()}} method.
--
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-15339) Make available the known JMX endpoints across the cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-15339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16939641#comment-16939641
]
Michael Semb Wever commented on CASSANDRA-15339:
wip…
|| branch || circleci || asf jenkins testall || asf jenkins dtests ||
|
[trunk_15339|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15339]
|
[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15339]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/49//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/49/]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/683//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/683]
|
> Make available the known JMX endpoints across the cluster
> -
>
> Key: CASSANDRA-15339
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15339
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> With the addition of multiple nodes running on the same server using
> different ports: CASSANDRA-7544 ; it becomes more difficult for third-party
> tools to easily connect to all nodes based on the jmx connection details to
> just one node.
> By adding jmx host and port to gossip, and saving it in {{system.peers_v2}},
> the list of all jmx endpoints in a cluster can be fetch after just the
> initial successful jmx connection and the
> {{StorageServiceMBean.getJmxEndpoints()}} method.
--
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-15339) Make available the known JMX endpoints across the cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-15339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15339:
---
Change Category: Operability
Complexity: Normal
Status: Open (was: Triage Needed)
> Make available the known JMX endpoints across the cluster
> -
>
> Key: CASSANDRA-15339
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15339
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> With the addition of multiple nodes running on the same server using
> different ports: CASSANDRA-7544 ; it becomes more difficult for third-party
> tools to easily connect to all nodes based on the jmx connection details to
> just one node.
> By adding jmx host and port to gossip, and saving it in {{system.peers_v2}},
> the list of all jmx endpoints in a cluster can be fetch after just the
> initial successful jmx connection and the
> {{StorageServiceMBean.getJmxEndpoints()}} method.
--
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-15339) Make available the known JMX endpoints across the cluster
Michael Semb Wever created CASSANDRA-15339:
--
Summary: Make available the known JMX endpoints across the cluster
Key: CASSANDRA-15339
URL: https://issues.apache.org/jira/browse/CASSANDRA-15339
Project: Cassandra
Issue Type: Improvement
Components: Cluster/Gossip
Reporter: Michael Semb Wever
Assignee: Michael Semb Wever
With the addition of multiple nodes running on the same server using different
ports: CASSANDRA-7544 ; it becomes more difficult for third-party tools to
easily connect to all nodes based on the jmx connection details to just one
node.
By adding jmx host and port to gossip, and saving it in {{system.peers_v2}},
the list of all jmx endpoints in a cluster can be fetch after just the initial
successful jmx connection and the {{StorageServiceMBean.getJmxEndpoints()}}
method.
--
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-15338) Fix flakey testMessagePurging - org.apache.cassandra.net.ConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15338:
--
Description:
Example failure:
[https://circleci.com/gh/dcapwell/cassandra/11#artifacts/containers/1]
{code:java}
Testcase: testMessagePurging(org.apache.cassandra.net.ConnectionTest): FAILED
expected:<0> but was:<1>
junit.framework.AssertionFailedError: expected:<0> but was:<1>
at
org.apache.cassandra.net.ConnectionTest.lambda$testMessagePurging$38(ConnectionTest.java:625)
at
org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:258)
at
org.apache.cassandra.net.ConnectionTest.testManual(ConnectionTest.java:231)
at
org.apache.cassandra.net.ConnectionTest.testMessagePurging(ConnectionTest.java:584){code}
Looking closer at
org.apache.cassandra.net.OutboundConnection.Delivery#stopAndRun it seems that
the run method is called before
org.apache.cassandra.net.OutboundConnection.Delivery#doRun which may lead to a
test race condition where the CountDownLatch completes before executing
was:
Example failure:
[https://circleci.com/gh/dcapwell/cassandra/11#artifacts/containers/1]
Testcase: testMessagePurging(org.apache.cassandra.net.ConnectionTest): FAILED
expected:<0> but was:<1>
junit.framework.AssertionFailedError: expected:<0> but was:<1>
at
org.apache.cassandra.net.ConnectionTest.lambda$testMessagePurging$38(ConnectionTest.java:625)
at
org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:258)
at org.apache.cassandra.net.ConnectionTest.testManual(ConnectionTest.java:231)
at
org.apache.cassandra.net.ConnectionTest.testMessagePurging(ConnectionTest.java:584)
Looking closer at
org.apache.cassandra.net.OutboundConnection.Delivery#stopAndRun it seems that
the run method is called before
org.apache.cassandra.net.OutboundConnection.Delivery#doRun which may lead to a
test race condition where the CountDownLatch completes before executing
> Fix flakey testMessagePurging - org.apache.cassandra.net.ConnectionTest
> ---
>
> Key: CASSANDRA-15338
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15338
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
>
> Example failure:
> [https://circleci.com/gh/dcapwell/cassandra/11#artifacts/containers/1]
>
> {code:java}
> Testcase: testMessagePurging(org.apache.cassandra.net.ConnectionTest): FAILED
> expected:<0> but was:<1>
> junit.framework.AssertionFailedError: expected:<0> but was:<1>
> at
> org.apache.cassandra.net.ConnectionTest.lambda$testMessagePurging$38(ConnectionTest.java:625)
> at
> org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:258)
> at
> org.apache.cassandra.net.ConnectionTest.testManual(ConnectionTest.java:231)
> at
> org.apache.cassandra.net.ConnectionTest.testMessagePurging(ConnectionTest.java:584){code}
>
> Looking closer at
> org.apache.cassandra.net.OutboundConnection.Delivery#stopAndRun it seems that
> the run method is called before
> org.apache.cassandra.net.OutboundConnection.Delivery#doRun which may lead to
> a test race condition where the CountDownLatch completes before executing
--
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-15338) Fix flakey testMessagePurging - org.apache.cassandra.net.ConnectionTest
David Capwell created CASSANDRA-15338: - Summary: Fix flakey testMessagePurging - org.apache.cassandra.net.ConnectionTest Key: CASSANDRA-15338 URL: https://issues.apache.org/jira/browse/CASSANDRA-15338 Project: Cassandra Issue Type: Bug Components: Test/unit Reporter: David Capwell Example failure: [https://circleci.com/gh/dcapwell/cassandra/11#artifacts/containers/1] Testcase: testMessagePurging(org.apache.cassandra.net.ConnectionTest): FAILED expected:<0> but was:<1> junit.framework.AssertionFailedError: expected:<0> but was:<1> at org.apache.cassandra.net.ConnectionTest.lambda$testMessagePurging$38(ConnectionTest.java:625) at org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:258) at org.apache.cassandra.net.ConnectionTest.testManual(ConnectionTest.java:231) at org.apache.cassandra.net.ConnectionTest.testMessagePurging(ConnectionTest.java:584) Looking closer at org.apache.cassandra.net.OutboundConnection.Delivery#stopAndRun it seems that the run method is called before org.apache.cassandra.net.OutboundConnection.Delivery#doRun which may lead to a test race condition where the CountDownLatch completes before executing -- 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-15337) Document usage of Ec2Snitch for multiple regions cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-15337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serban Teodorescu updated CASSANDRA-15337:
--
Description:
Ec2MultiRegionSnitch was (probably) done because it was not possible in AWS to
have intra-region VPC peering. This changed pin 2017, see [AWS
announcement|https://aws.amazon.com/about-aws/whats-new/2017/11/announcing-support-for-inter-region-vpc-peering/]
(and extended with 9 more regions in 2018, see
[link|https://aws.amazon.com/about-aws/whats-new/2018/02/inter-region-vpc-peering-is-now-available-in-nine-additional-aws-regions/]):
{quote}Inter-Region VPC Peering allows VPC resources like EC2 instances[...]
running in different AWS regions to communicate with each other using private
IP addresses, without requiring gateways, VPN connections or separate network
appliances.
{quote}
Since the datacenter/rack names are loaded in Ec2Snitch using AWS API there is
no reason why this snitch would not work in a multi-datacenter setup. I tested
and used this in a production environment. So the documentation should be
changed to include this usage.
Proposed change:
[https://github.com/apache/cassandra/compare/trunk...serban21:15337-trunk]
was:
Ec2MultiRegionSnitch was (probably) done because it was not possible in AWS to
have intra-region VPC peering. This changed pin 2017, see [AWS
announcement|https://aws.amazon.com/about-aws/whats-new/2017/11/announcing-support-for-inter-region-vpc-peering/]
(and extended with 9 more regions in 2018, see
[link|https://aws.amazon.com/about-aws/whats-new/2018/02/inter-region-vpc-peering-is-now-available-in-nine-additional-aws-regions/]):
{quote}Inter-Region VPC Peering allows VPC resources like EC2 instances[...]
running in different AWS regions to communicate with each other using private
IP addresses, without requiring gateways, VPN connections or separate network
appliances.
{quote}
Since the datacenter/rack names are loaded in Ec2Snitch using AWS API there is
no reason why this snitch would not work in a multi-datacenter setup. I tested
and used this in a production environment. So the documentation should be
changed to include this usage.
> Document usage of Ec2Snitch for multiple regions cluster
>
>
> Key: CASSANDRA-15337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15337
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Serban Teodorescu
>Assignee: Serban Teodorescu
>Priority: Normal
>
> Ec2MultiRegionSnitch was (probably) done because it was not possible in AWS
> to have intra-region VPC peering. This changed pin 2017, see [AWS
> announcement|https://aws.amazon.com/about-aws/whats-new/2017/11/announcing-support-for-inter-region-vpc-peering/]
> (and extended with 9 more regions in 2018, see
> [link|https://aws.amazon.com/about-aws/whats-new/2018/02/inter-region-vpc-peering-is-now-available-in-nine-additional-aws-regions/]):
> {quote}Inter-Region VPC Peering allows VPC resources like EC2 instances[...]
> running in different AWS regions to communicate with each other using private
> IP addresses, without requiring gateways, VPN connections or separate network
> appliances.
> {quote}
> Since the datacenter/rack names are loaded in Ec2Snitch using AWS API there
> is no reason why this snitch would not work in a multi-datacenter setup. I
> tested and used this in a production environment. So the documentation should
> be changed to include this usage.
> Proposed change:
> [https://github.com/apache/cassandra/compare/trunk...serban21:15337-trunk]
--
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-15337) Document usage of Ec2Snitch for multiple regions cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-15337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serban Teodorescu reassigned CASSANDRA-15337:
-
Assignee: Serban Teodorescu
> Document usage of Ec2Snitch for multiple regions cluster
>
>
> Key: CASSANDRA-15337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15337
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Serban Teodorescu
>Assignee: Serban Teodorescu
>Priority: Normal
>
> Ec2MultiRegionSnitch was (probably) done because it was not possible in AWS
> to have intra-region VPC peering. This changed pin 2017, see [AWS
> announcement|https://aws.amazon.com/about-aws/whats-new/2017/11/announcing-support-for-inter-region-vpc-peering/]
> (and extended with 9 more regions in 2018, see
> [link|https://aws.amazon.com/about-aws/whats-new/2018/02/inter-region-vpc-peering-is-now-available-in-nine-additional-aws-regions/]):
> {quote}Inter-Region VPC Peering allows VPC resources like EC2 instances[...]
> running in different AWS regions to communicate with each other using private
> IP addresses, without requiring gateways, VPN connections or separate network
> appliances.
> {quote}
> Since the datacenter/rack names are loaded in Ec2Snitch using AWS API there
> is no reason why this snitch would not work in a multi-datacenter setup. I
> tested and used this in a production environment. So the documentation should
> be changed to include this usage.
--
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-15337) Document usage of Ec2Snitch for multiple regions cluster
Serban Teodorescu created CASSANDRA-15337:
-
Summary: Document usage of Ec2Snitch for multiple regions cluster
Key: CASSANDRA-15337
URL: https://issues.apache.org/jira/browse/CASSANDRA-15337
Project: Cassandra
Issue Type: Improvement
Components: Documentation/Website
Reporter: Serban Teodorescu
Ec2MultiRegionSnitch was (probably) done because it was not possible in AWS to
have intra-region VPC peering. This changed pin 2017, see [AWS
announcement|https://aws.amazon.com/about-aws/whats-new/2017/11/announcing-support-for-inter-region-vpc-peering/]
(and extended with 9 more regions in 2018, see
[link|https://aws.amazon.com/about-aws/whats-new/2018/02/inter-region-vpc-peering-is-now-available-in-nine-additional-aws-regions/]):
{quote}Inter-Region VPC Peering allows VPC resources like EC2 instances[...]
running in different AWS regions to communicate with each other using private
IP addresses, without requiring gateways, VPN connections or separate network
appliances.
{quote}
Since the datacenter/rack names are loaded in Ec2Snitch using AWS API there is
no reason why this snitch would not work in a multi-datacenter setup. I tested
and used this in a production environment. So the documentation should be
changed to include this usage.
--
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-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
[
https://issues.apache.org/jira/browse/CASSANDRA-15263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16939183#comment-16939183
]
feroz shaik commented on CASSANDRA-15263:
-
I figured out that the app deletes using : "DELETE FROM \"sal_purge\" USING
TIMESTAMP ? WHERE key=? AND column1=?;"; is actually causing range bound
tombstones. I used sstabledump to know that.
"rows" : [
{
"type" : "range_tombstone_bound",
"start" : {
"type" : "inclusive",
"clustering" : [
"15e0088cdb99f399290e531a452e4c2c32d547a852607cb2819ff8fbd565ed53", "*" ],
"deletion_info" : \{ "marked_deleted" : "2019-09-27T06:20:16.04Z",
"local_delete_time" : "2019-09-27T06:38:02Z" }
}
},
But other problems i have is that the sstabledump is erroring out with below
which may be another problem.bug itself:
Exception in thread "main" java.lang.NullPointerException
at org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:156)
at org.apache.cassandra.db.marshal.UTF8Type.toJSONString(UTF8Type.java:66)
at
org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:347)
at
org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:244)
at
org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:211)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
at org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:101)
at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:240)
My main point of concern now is that I cannot reproduce the error on my lab by
cqlsh driver with CL-all.
[~benedict] - since we know this is for sure a bug , when can we expect any
fix/patch for this? Kindly let us know.
> LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
> ---
>
> Key: CASSANDRA-15263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15263
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: feroz shaik
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Labels: 2.1.16, 3.11.4
> Attachments: sample.system.log, schema.txt,
> sstabledump_sal_purge_d03.json, sstablemetadata_sal_purge_d03,
> stack_trace.txt, system.log, system.log, system.log, system.log,
> system_latest.log
>
>
> We have hit a problem today while upgrading from 2.1.16 to 3.11.4.
> we encountered this as soon as the first node started up with 3.11.4
> The full error stack is attached - [^stack_trace.txt]
>
> The below errors continued in the log file as long as the process was up.
> ERROR [Native-Transport-Requests-12] 2019-08-06 03:00:47,135
> ErrorMessage.java:384 - Unexpected exception during request
> java.lang.NullPointerException: null
> ERROR [Native-Transport-Requests-8] 2019-08-06 03:00:48,778
> ErrorMessage.java:384 - Unexpected exception during request
> java.lang.NullPointerException: null
> ERROR [Native-Transport-Requests-13] 2019-08-06 03:00:57,454
>
> The nodetool version says 3.11.4 and the no of connections on native por t-
> 9042 was similar to other nodes. The exceptions were scary that we had to
> call off the change. Any help and insights to this problem from the community
> is appreciated.
--
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-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16939184#comment-16939184 ] null commented on CASSANDRA-10190: -- Thanks for working on this, I can't believe cqlsh is limited to Python 2.7, seems crazy when 1st January 2020 isn't too far away. How far away are you from a working cqlsh on Python 3.x? thanks again for your great work on this :) > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Fix For: 4.0, 4.0-alpha > > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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
