[jira] [Updated] (CASSANDRA-15912) Occasional NEW_NODE event sent instead of NODE_UP in dTest
[ https://issues.apache.org/jira/browse/CASSANDRA-15912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke updated CASSANDRA-15912: --- Component/s: Messaging/Client > Occasional NEW_NODE event sent instead of NODE_UP in dTest > -- > > Key: CASSANDRA-15912 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15912 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Bryn Cooke >Priority: Normal > > A new test for topology events in CASSANDRA-15677 is occasionally failing due > to a NEW_NODE event sent instead of NODE_UP. > For instance: > [https://app.circleci.com/pipelines/github/jasonstack/cassandra/231/workflows/cdf55335-c876-450b-8bf9-1d778a2df806/jobs/2240] > > Previously topology events were not been sent at all, so it is possible that > this is a long standing bug. > -- 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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150167#comment-17150167
]
Bryn Cooke commented on CASSANDRA-15677:
Created CASSANDRA-15912
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15912) Occasional NEW_NODE event sent instead of NODE_UP in dTest
Bryn Cooke created CASSANDRA-15912: -- Summary: Occasional NEW_NODE event sent instead of NODE_UP in dTest Key: CASSANDRA-15912 URL: https://issues.apache.org/jira/browse/CASSANDRA-15912 Project: Cassandra Issue Type: Bug Reporter: Bryn Cooke A new test for topology events in CASSANDRA-15677 is occasionally failing due to a NEW_NODE event sent instead of NODE_UP. For instance: [https://app.circleci.com/pipelines/github/jasonstack/cassandra/231/workflows/cdf55335-c876-450b-8bf9-1d778a2df806/jobs/2240] Previously topology events were not been sent at all, so it is possible that this is a long standing bug. -- 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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149607#comment-17149607
]
Bryn Cooke commented on CASSANDRA-15677:
[~brandon.williams] It looks like we are getting occasional NEW_NODE events
rather than NODE_UP with the modified dTest
[https://app.circleci.com/pipelines/github/jasonstack/cassandra/231/workflows/cdf55335-c876-450b-8bf9-1d778a2df806/jobs/2240]
This feels like a separate issue, but do we reopen this ticket?
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryn Cooke updated CASSANDRA-15677:
---
Test and Documentation Plan:
Added a new in-jvm-dtests
Updated existing python dTests
was:Added a new in-jvm-dtest
Status: Patch Available (was: In Progress)
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17141912#comment-17141912
]
Bryn Cooke commented on CASSANDRA-15677:
I've created a PR for the dTests
https://github.com/apache/cassandra-dtest/pull/79
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140750#comment-17140750
]
Bryn Cooke commented on CASSANDRA-15677:
It looks like the ADD/REMOVE events are actually a java driver bug that has
been fixed.
[https://github.com/datastax/java-driver/blob/3.x/driver-core/src/main/java/com/datastax/driver/core/Cluster.java#L2738]
Updating the driver version makes them go away.
Here is another PR that adds more tests and bumps the driver:
[https://github.com/apache/cassandra/pull/647]
I think we are safe to modify the python dTests to bring them in line with
current functionality, and I'll create a PR for them on Monday.
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140680#comment-17140680
]
Bryn Cooke commented on CASSANDRA-15677:
Quick update.
It looks like the behaviour since
https://issues.apache.org/jira/browse/CASSANDRA-10052 has changed.
Pre-11052 when the node was dropped the events received for
test_restart_node_localhost had the wrong node listed.
On trunk the events received are for the correct node. So on the face of it is
looks like something has been fixed since 10052 that means that is it now OK to
receive events when running on the same interface.
However, when testing using the in-jvm dTests decommissioning a node still
produces extra remove and add events for nodes that should not have been
affected. This probably related to the original problem in 10052 in some way.
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139261#comment-17139261
]
Bryn Cooke edited comment on CASSANDRA-15677 at 6/18/20, 2:05 PM:
--
-This comment seems to indicate that the existing behaviour was a workaround to
the drivers not distinguishing nodes by address and socket:
https://issues.apache.org/jira/browse/CASSANDRA-10052?focusedCommentId=14725534=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14725534-
-It looks like the Java driver no longer has this issue, at least I don't see
any calls to Host#getListenAddress or Host#getBroadcastAddress. Everything
seems to be using address and port.-
[~aboudreault] -how do things look like on the other drivers?-
-Edit:-
-Just had a look at the python driver and Endpoint was added to the Python
driver here:
[https://github.com/datastax/python-driver/blob/c88255f202a21bbbae35f16e603b0f10f2f2cf36/cassandra/connection.py#L116]-
-Node.js has Host support here:
[https://github.com/datastax/nodejs-driver/blob/master/lib/host.js#L41]-
-C# has
[https://github.com/datastax/csharp-driver/blob/master/src/Cassandra/Host.cs#L78]-
-CPP has [https://github.com/datastax/cpp-driver/blob/master/src/host.hpp#L92]-
-So I think all of the drivers can now distinguish between nodes based on node
and port. But it would probably be best for one of the driver devs to weigh in.-
Ignore this. I misread Tyler's comment.
was (Author: bryncooke):
This comment seems to indicate that the existing behaviour was a workaround to
the drivers not distinguishing nodes by address and socket:
https://issues.apache.org/jira/browse/CASSANDRA-10052?focusedCommentId=14725534=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14725534
It looks like the Java driver no longer has this issue, at least I don't see
any calls to Host#getListenAddress or Host#getBroadcastAddress. Everything
seems to be using address and port.
[~aboudreault] how do things look like on the other drivers?
Edit:
Just had a look at the python driver and Endpoint was added to the Python
driver here:
[https://github.com/datastax/python-driver/blob/c88255f202a21bbbae35f16e603b0f10f2f2cf36/cassandra/connection.py#L116]
Node.js has Host support here:
[https://github.com/datastax/nodejs-driver/blob/master/lib/host.js#L41]
C# has
[https://github.com/datastax/csharp-driver/blob/master/src/Cassandra/Host.cs#L78]
CPP has [https://github.com/datastax/cpp-driver/blob/master/src/host.hpp#L92]
So I think all of the drivers can now distinguish between nodes based on node
and port. But it would probably be best for one of the driver devs to weigh in.
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139261#comment-17139261
]
Bryn Cooke edited comment on CASSANDRA-15677 at 6/18/20, 12:01 PM:
---
This comment seems to indicate that the existing behaviour was a workaround to
the drivers not distinguishing nodes by address and socket:
https://issues.apache.org/jira/browse/CASSANDRA-10052?focusedCommentId=14725534=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14725534
It looks like the Java driver no longer has this issue, at least I don't see
any calls to Host#getListenAddress or Host#getBroadcastAddress. Everything
seems to be using address and port.
[~aboudreault] how do things look like on the other drivers?
Edit:
Just had a look at the python driver and Endpoint was added to the Python
driver here:
[https://github.com/datastax/python-driver/blob/c88255f202a21bbbae35f16e603b0f10f2f2cf36/cassandra/connection.py#L116]
Node.js has Host support here:
[https://github.com/datastax/nodejs-driver/blob/master/lib/host.js#L41]
C# has
[https://github.com/datastax/csharp-driver/blob/master/src/Cassandra/Host.cs#L78]
CPP has [https://github.com/datastax/cpp-driver/blob/master/src/host.hpp#L92]
So I think all of the drivers can now distinguish between nodes based on node
and port. But it would probably be best for one of the driver devs to weigh in.
was (Author: bryncooke):
This comment seems to indicate that the existing behaviour was a workaround to
the drivers not distinguishing nodes by address and socket.
https://issues.apache.org/jira/browse/CASSANDRA-10052?focusedCommentId=14725534=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14725534
It looks like the Java driver no longer has this issue, at least I don't see
any calls to Host#getListenAddress or Host#getBroadcastAddress. Everything
seems to be using address and port.
[~aboudreault] how do things look like on the other drivers?
Edit:
Just had a look at the python driver and Endpoint was added to the Python
driver here:
[https://github.com/datastax/python-driver/blob/c88255f202a21bbbae35f16e603b0f10f2f2cf36/cassandra/connection.py#L116]
Node.js has Host support here:
[https://github.com/datastax/nodejs-driver/blob/master/lib/host.js#L41]
C# has
[https://github.com/datastax/csharp-driver/blob/master/src/Cassandra/Host.cs#L78]
CPP has [https://github.com/datastax/cpp-driver/blob/master/src/host.hpp#L92]
So I think all of the drivers can now distinguish between nodes based on node
and port. But it would probably be best for one of the driver devs to weigh in.
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139261#comment-17139261
]
Bryn Cooke edited comment on CASSANDRA-15677 at 6/18/20, 9:56 AM:
--
This comment seems to indicate that the existing behaviour was a workaround to
the drivers not distinguishing nodes by address and socket.
https://issues.apache.org/jira/browse/CASSANDRA-10052?focusedCommentId=14725534=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14725534
It looks like the Java driver no longer has this issue, at least I don't see
any calls to Host#getListenAddress or Host#getBroadcastAddress. Everything
seems to be using address and port.
[~aboudreault] how do things look like on the other drivers?
Edit:
Just had a look at the python driver and Endpoint was added to the Python
driver here:
[https://github.com/datastax/python-driver/blob/c88255f202a21bbbae35f16e603b0f10f2f2cf36/cassandra/connection.py#L116]
Node.js has Host support here:
[https://github.com/datastax/nodejs-driver/blob/master/lib/host.js#L41]
C# has
[https://github.com/datastax/csharp-driver/blob/master/src/Cassandra/Host.cs#L78]
CPP has [https://github.com/datastax/cpp-driver/blob/master/src/host.hpp#L92]
So I *think* all of the drivers can now distinguish between nodes based on node
and port. But it would probably be best for one of the driver devs to weigh in.
was (Author: bryncooke):
This comment seems to indicate that the existing behaviour was a workaround to
the drivers not distinguishing nodes by address and socket.
https://issues.apache.org/jira/browse/CASSANDRA-10052?focusedCommentId=14725534=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14725534
It looks like the Java driver no longer has this issue, at least I don't see
any calls to Host#getListenAddress or Host#getBroadcastAddress. Everything
seems to be using address and port.
[~aboudreault] how do things look like on the other drivers?
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139261#comment-17139261
]
Bryn Cooke edited comment on CASSANDRA-15677 at 6/18/20, 9:56 AM:
--
This comment seems to indicate that the existing behaviour was a workaround to
the drivers not distinguishing nodes by address and socket.
https://issues.apache.org/jira/browse/CASSANDRA-10052?focusedCommentId=14725534=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14725534
It looks like the Java driver no longer has this issue, at least I don't see
any calls to Host#getListenAddress or Host#getBroadcastAddress. Everything
seems to be using address and port.
[~aboudreault] how do things look like on the other drivers?
Edit:
Just had a look at the python driver and Endpoint was added to the Python
driver here:
[https://github.com/datastax/python-driver/blob/c88255f202a21bbbae35f16e603b0f10f2f2cf36/cassandra/connection.py#L116]
Node.js has Host support here:
[https://github.com/datastax/nodejs-driver/blob/master/lib/host.js#L41]
C# has
[https://github.com/datastax/csharp-driver/blob/master/src/Cassandra/Host.cs#L78]
CPP has [https://github.com/datastax/cpp-driver/blob/master/src/host.hpp#L92]
So I think all of the drivers can now distinguish between nodes based on node
and port. But it would probably be best for one of the driver devs to weigh in.
was (Author: bryncooke):
This comment seems to indicate that the existing behaviour was a workaround to
the drivers not distinguishing nodes by address and socket.
https://issues.apache.org/jira/browse/CASSANDRA-10052?focusedCommentId=14725534=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14725534
It looks like the Java driver no longer has this issue, at least I don't see
any calls to Host#getListenAddress or Host#getBroadcastAddress. Everything
seems to be using address and port.
[~aboudreault] how do things look like on the other drivers?
Edit:
Just had a look at the python driver and Endpoint was added to the Python
driver here:
[https://github.com/datastax/python-driver/blob/c88255f202a21bbbae35f16e603b0f10f2f2cf36/cassandra/connection.py#L116]
Node.js has Host support here:
[https://github.com/datastax/nodejs-driver/blob/master/lib/host.js#L41]
C# has
[https://github.com/datastax/csharp-driver/blob/master/src/Cassandra/Host.cs#L78]
CPP has [https://github.com/datastax/cpp-driver/blob/master/src/host.hpp#L92]
So I *think* all of the drivers can now distinguish between nodes based on node
and port. But it would probably be best for one of the driver devs to weigh in.
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139261#comment-17139261
]
Bryn Cooke commented on CASSANDRA-15677:
This comment seems to indicate that the existing behaviour was a workaround to
the drivers not distinguishing nodes by address and socket.
https://issues.apache.org/jira/browse/CASSANDRA-10052?focusedCommentId=14725534=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14725534
It looks like the Java driver no longer has this issue, at least I don't see
any calls to Host#getListenAddress or Host#getBroadcastAddress. Everything
seems to be using address and port.
[~aboudreault] how do things look like on the other drivers?
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130402#comment-17130402
]
Bryn Cooke edited comment on CASSANDRA-15677 at 6/10/20, 9:03 AM:
--
It's 0.0.2 on trunk, which has the changes needed.
It looks like only 65de93d4fe2b48565955ae7e49adbadf510ed3c5 was taken from the
PR?
3fe0b77b985d76e1456241e56b4b92a965926d72 is needed as well at minimum.
TIL that github PRs do not display ordered by commit and instead in
chronological order:
[https://help.github.com/en/github/committing-changes-to-your-project/why-are-my-commits-in-the-wrong-order]
My local git log looks like this:
{noformat}
commit 5356c267de3bb1306f52c05a8afbb01dafddf28e (HEAD -> CASSANDRA-15677,
origin/CASSANDRA-15677)
Author: bryn
Date: Mon Jun 8 11:02:42 2020 +0100CASSANDRA-15677 Add shutdown to JMX
thread pool to avoid metaspace errors associated with thread leaks.
There are still other thread shutdown issues remaining, but this seems to
be the most serious one.
commit 65de93d4fe2b48565955ae7e49adbadf510ed3c5
Author: Alan Boudreault
Date: Mon Mar 30 14:27:55 2020 -0400CASSANDRA-15677 Make sure topology
events are sent to clients when using a single network interface
commit 3fe0b77b985d76e1456241e56b4b92a965926d72
Author: bryn
Date: Wed May 20 16:16:33 2020 +0100CASSANDRA-15677 Add the ability to
run dTests on the same interface.
commit 7bbc97e5835b64c49fd418581f5a45429c1806b1
Merge: 69ea5ffdbc 04b0049831
Author: Alex Petrov
Date: Fri Jun 5 19:34:13 2020 +0200Merge branch 'cassandra-3.11' into
trunk
{noformat}
was (Author: bryncooke):
It's 0.0.2 on trunk, which has the changes needed.
It looks like only 65de93d4fe2b48565955ae7e49adbadf510ed3c5 was taken from the
PR?
3fe0b77b985d76e1456241e56b4b92a965926d72 is needed as well at minimum.
TIL that github PRs do not display ordered by commit and instead in
chronological order:
[https://help.github.com/en/github/committing-changes-to-your-project/why-are-my-commits-in-the-wrong-order]
My local git log looks like this:
{noformat}
commit 5356c267de3bb1306f52c05a8afbb01dafddf28e (HEAD -> CASSANDRA-15677,
origin/CASSANDRA-15677)
Author: bryn
Date: Mon Jun 8 11:02:42 2020 +0100CASSANDRA-15677 Add shutdown to JMX
thread pool to avoid metaspace errors associated with thread leaks.
There are still other thread shutdown issues remaining, but this seems to
be the most serious one.
commit 65de93d4fe2b48565955ae7e49adbadf510ed3c5
Author: Alan Boudreault
Date: Mon Mar 30 14:27:55 2020 -0400CASSANDRA-15677 Make sure topology
events are sent to clients when using a single network interface
commit 3fe0b77b985d76e1456241e56b4b92a965926d72
Author: bryn
Date: Wed May 20 16:16:33 2020 +0100CASSANDRA-15677 Add the ability to
run dTests on the same interface.
commit 7bbc97e5835b64c49fd418581f5a45429c1806b1
Merge: 69ea5ffdbc 04b0049831
Author: Alex Petrov
Date: Fri Jun 5 19:34:13 2020 +0200Merge branch 'cassandra-3.11' into
trunk
{noformat}
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CASSANDRA-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130402#comment-17130402
]
Bryn Cooke commented on CASSANDRA-15677:
It's 0.0.2 on trunk, which has the changes needed.
It looks like only 65de93d4fe2b48565955ae7e49adbadf510ed3c5 was taken from the
PR?
3fe0b77b985d76e1456241e56b4b92a965926d72 is needed as well at minimum.
TIL that github PRs do not display ordered by commit and instead in
chronological order:
[https://help.github.com/en/github/committing-changes-to-your-project/why-are-my-commits-in-the-wrong-order]
My local git log looks like this:
{noformat}
commit 5356c267de3bb1306f52c05a8afbb01dafddf28e (HEAD -> CASSANDRA-15677,
origin/CASSANDRA-15677)
Author: bryn
Date: Mon Jun 8 11:02:42 2020 +0100CASSANDRA-15677 Add shutdown to JMX
thread pool to avoid metaspace errors associated with thread leaks.
There are still other thread shutdown issues remaining, but this seems to
be the most serious one.
commit 65de93d4fe2b48565955ae7e49adbadf510ed3c5
Author: Alan Boudreault
Date: Mon Mar 30 14:27:55 2020 -0400CASSANDRA-15677 Make sure topology
events are sent to clients when using a single network interface
commit 3fe0b77b985d76e1456241e56b4b92a965926d72
Author: bryn
Date: Wed May 20 16:16:33 2020 +0100CASSANDRA-15677 Add the ability to
run dTests on the same interface.
commit 7bbc97e5835b64c49fd418581f5a45429c1806b1
Merge: 69ea5ffdbc 04b0049831
Author: Alex Petrov
Date: Fri Jun 5 19:34:13 2020 +0200Merge branch 'cassandra-3.11' into
trunk
{noformat}
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129739#comment-17129739
]
Bryn Cooke commented on CASSANDRA-15677:
Without Alan's change the decommissioned node is never reported to have left
the cluster because the topology event is never sent. I verified that the test
failed without his change.
That being said, if there is a more targeted way of testing this functionality
then it would be better. I could take another look if you feel this is likely
to be possible without large refactoring.
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129677#comment-17129677
]
Bryn Cooke commented on CASSANDRA-15677:
I've added links to the ticket.
I'm new to this so if I need to run more tests then I can do so.
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryn Cooke updated CASSANDRA-15677:
---
Test and Documentation Plan: Added a new in-jvm-dtest
Status: Patch Available (was: In Progress)
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128367#comment-17128367
]
Bryn Cooke commented on CASSANDRA-15677:
Looks like dtest-api got bumped recently. I've created a new PR and will move
to review after CI tests complete.
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113044#comment-17113044
]
Bryn Cooke commented on CASSANDRA-15677:
[~dcapwell] I think that I'll need a bump to cassandra-in-jvm-dtest-api to make
this happen. I need
[https://github.com/apache/cassandra-in-jvm-dtest-api/commit/326045f699791686efa1ecf43b7353397c956494]
Is cassandra-in-jvm-dtest-api in a position to create a new release? If so I
could create a PR to handle the changes on the C* side.
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1791#comment-1791
]
Bryn Cooke commented on CASSANDRA-15677:
I'm having a go at this.
The dtest code needs tweaking to allow tests on the same interface.
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15730) Batch statement preparation fails if multiple tables and parameters are used
[
https://issues.apache.org/jira/browse/CASSANDRA-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryn Cooke updated CASSANDRA-15730:
---
Description:
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]
was:
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]
> 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: 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-15730) Batch statement preparation fails if multiple tables and parameters are used
[
https://issues.apache.org/jira/browse/CASSANDRA-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryn Cooke updated CASSANDRA-15730:
---
Description:
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]
was:
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]
> 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: 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-15730) Batch statement preparation fails if multiple tables and parameters are used
[
https://issues.apache.org/jira/browse/CASSANDRA-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryn Cooke updated CASSANDRA-15730:
---
Description:
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]
was:
Currently affectsMultipleTables is true if all statements in a batch are for
the same table
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144]
This later causes an assertion failure
[here|https://github.com/apache/cassandra/blob/24c8a21c1c131abd89c6b646343ff098d1b3263b/src/java/org/apache/cassandra/cql3/VariableSpecifications.java#L75]
> 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: 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-15730) Batch statement preparation fails if multiple tables and parameters are used
[ https://issues.apache.org/jira/browse/CASSANDRA-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke updated CASSANDRA-15730: --- Summary: Batch statement preparation fails if multiple tables and parameters are used (was: Logic for determining if all statements in a batch are for the same table is inverted) > 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 > > Currently affectsMultipleTables is true if all statements in a batch are for > the same table > [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144] > > 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-15730) Logic for determining if all statements in a batch are for the same table is inverted
[ https://issues.apache.org/jira/browse/CASSANDRA-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke updated CASSANDRA-15730: --- Description: Currently affectsMultipleTables is true if all statements in a batch are for the same table [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144] This later causes an assertion failure [here|https://github.com/apache/cassandra/blob/24c8a21c1c131abd89c6b646343ff098d1b3263b/src/java/org/apache/cassandra/cql3/VariableSpecifications.java#L75] was: Currently affectsMultipleTables is true if all statements in a batch are for the same table [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144] This later causes an assertion failure [here|https://github.com/apache/cassandra/blob/24c8a21c1c131abd89c6b646343ff098d1b3263b/src/java/org/apache/cassandra/cql3/VariableSpecifications.java#L75] > Logic for determining if all statements in a batch are for the same table is > inverted > - > > Key: CASSANDRA-15730 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15730 > Project: Cassandra > Issue Type: Bug >Reporter: Bryn Cooke >Priority: Normal > > Currently affectsMultipleTables is true if all statements in a batch are for > the same table > [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144] > > 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-15730) Logic for determining if all statements in a batch are for the same table is inverted
[ https://issues.apache.org/jira/browse/CASSANDRA-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke updated CASSANDRA-15730: --- Description: Currently affectsMultipleTables is true if all statements in a batch are for the same table [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144] This later causes an assertion failure [here|https://github.com/apache/cassandra/blob/24c8a21c1c131abd89c6b646343ff098d1b3263b/src/java/org/apache/cassandra/cql3/VariableSpecifications.java#L75] was: Currently affectsMultipleTables is true if all statements in a batch are for the same table [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144] This later causes an assertion failure [here|#L75]] > Logic for determining if all statements in a batch are for the same table is > inverted > - > > Key: CASSANDRA-15730 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15730 > Project: Cassandra > Issue Type: Bug >Reporter: Bryn Cooke >Priority: Normal > > Currently affectsMultipleTables is true if all statements in a batch are for > the same table > [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144] > > 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-15730) Logic for determining if all statements in a batch are for the same table is inverted
[ https://issues.apache.org/jira/browse/CASSANDRA-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke updated CASSANDRA-15730: --- Description: Currently affectsMultipleTables is true if all statements in a batch are for the same table [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144] This later causes an assertion failure [here|#L75]] was: Currently affectsMultipleTables is true if all statements in a batch are for the same table [here|[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144]][ |https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144] This later causes an assertion failure [here|[https://github.com/apache/cassandra/blob/24c8a21c1c131abd89c6b646343ff098d1b3263b/src/java/org/apache/cassandra/cql3/VariableSpecifications.java#L75]] > Logic for determining if all statements in a batch are for the same table is > inverted > - > > Key: CASSANDRA-15730 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15730 > Project: Cassandra > Issue Type: Bug >Reporter: Bryn Cooke >Priority: Normal > > Currently affectsMultipleTables is true if all statements in a batch are for > the same table > [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144] > > This later causes an assertion failure [here|#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] [Created] (CASSANDRA-15730) Logic for determining if all statements in a batch are for the same table is inverted
Bryn Cooke created CASSANDRA-15730: -- Summary: Logic for determining if all statements in a batch are for the same table is inverted Key: CASSANDRA-15730 URL: https://issues.apache.org/jira/browse/CASSANDRA-15730 Project: Cassandra Issue Type: Bug Reporter: Bryn Cooke Currently affectsMultipleTables is true if all statements in a batch are for the same table [here|[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144]][ |https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L144] 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] [Created] (CASSANDRA-12360) Unable to parse negative dates
Bryn Cooke created CASSANDRA-12360:
--
Summary: Unable to parse negative dates
Key: CASSANDRA-12360
URL: https://issues.apache.org/jira/browse/CASSANDRA-12360
Project: Cassandra
Issue Type: Bug
Reporter: Bryn Cooke
{code}
cqlsh:date_test> DESC test;
CREATE TABLE date_test.test (
date timestamp PRIMARY KEY
) ...
cqlsh:date_test> INSERT INTO test (date) VALUES ('-0407-12-27T00:00:00Z');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Unable to
coerce '-0407-12-27T00:00:00Z' to a formatted date (long)"
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10536) Batch statements with multiple updates to partition error when table is indexed
[
https://issues.apache.org/jira/browse/CASSANDRA-10536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14960425#comment-14960425
]
Bryn Cooke commented on CASSANDRA-10536:
Just to add, the following updates cannot be combined in to a single statement,
so this cannot be worked around:
{noformat}
CREATE TABLE foo (a int, b int, c int, d int, PRIMARY KEY ((a, b), c));
CREATE INDEX ON foo(d);
{noformat}
and batch updates
{noformat}
BEGIN BATCH
UPDATE foo SET d = 0 WHERE a = 0 AND b = 0 AND C = 0;
UPDATE foo SET d = 0 WHERE a = 0 AND b = 0 AND C = 1;
APPLY BATCH
{noformat}
> Batch statements with multiple updates to partition error when table is
> indexed
> ---
>
> Key: CASSANDRA-10536
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10536
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.0 rc2
>
>
> If a {{BATCH}} statement contains multiple {{UPDATE}} statements that update
> the same partition, and a secondary index exists on that table, the batch
> statement will error:
> {noformat}
> ServerError: message="java.lang.IllegalStateException: An update should not be written
> again once it has been read">
> {noformat}
> with the following traceback in the logs:
> {noformat}
> ERROR 20:53:46 Unexpected exception during request
> java.lang.IllegalStateException: An update should not be written again once
> it has been read
> at
> org.apache.cassandra.db.partitions.PartitionUpdate.assertNotBuilt(PartitionUpdate.java:504)
> ~[main/:na]
> at
> org.apache.cassandra.db.partitions.PartitionUpdate.add(PartitionUpdate.java:535)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.UpdateStatement.addUpdateForKey(UpdateStatement.java:96)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:667)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.BatchStatement.getMutations(BatchStatement.java:234)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:335)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:321)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:316)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:205)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:471)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:448)
> ~[main/:na]
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
> ~[main/:na]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
> [main/:na]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
> [main/:na]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_45]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> [main/:na]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> This is due to {{SecondaryIndexManager.validate()}} triggering a build of the
> {{PartitionUpdate}} (stacktrace from debugging the build() call):
> {noformat}
> at
> org.apache.cassandra.db.partitions.PartitionUpdate.build(PartitionUpdate.java:571)
> [main/:na]
> at
> org.apache.cassandra.db.partitions.PartitionUpdate.maybeBuild(PartitionUpdate.java:561)
> [main/:na]
> at
> org.apache.cassandra.db.partitions.PartitionUpdate.iterator(PartitionUpdate.java:418)
> [main/:na]
> at
> org.apache.cassandra.index.internal.CassandraIndex.validateRows(CassandraIndex.java:560)
> [main/:na]
> at
>
[jira] [Created] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
Bryn Cooke created CASSANDRA-10411: -- Summary: Add/drop multiple columns in one ALTER TABLE statement Key: CASSANDRA-10411 URL: https://issues.apache.org/jira/browse/CASSANDRA-10411 Project: Cassandra Issue Type: New Feature Reporter: Bryn Cooke Currently it is only possible to add one column at a time in an alter table statement. It would be great if we could add multiple columns at a time. The primary reason for this is that adding each column individually seems to take a significant amount of time (at least on my development machine), I know all the columns I want to add, but don't know them until after the initial table is created. As a secondary consideration it brings CQL slightly closer to SQL where most databases can handle adding multiple columns in one statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9459) SecondaryIndex API redesign
[ https://issues.apache.org/jira/browse/CASSANDRA-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588157#comment-14588157 ] Bryn Cooke commented on CASSANDRA-9459: --- It would be great if we could use CQL inside our custom secondary index implementations as it would vastly increase the readability of our code rather than generating slice queries manually. It's almost possible in Cassandra 2.x, but I forget the exact reason it didn't work. Something about the table meta data not being available during CQL validation. SecondaryIndex API redesign --- Key: CASSANDRA-9459 URL: https://issues.apache.org/jira/browse/CASSANDRA-9459 Project: Cassandra Issue Type: Improvement Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe Fix For: 3.0 beta 1 For some time now the index subsystem has been a pain point and in large part this is due to the way that the APIs and principal classes have grown organically over the years. It would be a good idea to conduct a wholesale review of the area and see if we can come up with something a bit more coherent. A few starting points: * There's a lot in AbstractPerColumnSecondaryIndex its subclasses which could be pulled up into SecondaryIndexSearcher (note that to an extent, this is done in CASSANDRA-8099). * SecondayIndexManager is overly complex and several of its functions should be simplified/re-examined. The handling of which columns are indexed and index selection on both the read and write paths are somewhat dense and unintuitive. * The SecondaryIndex class hierarchy is rather convoluted and could use some serious rework. There are a number of outstanding tickets which we should be able to roll into this higher level one as subtasks (but I'll defer doing that until getting into the details of the redesign): * CASSANDRA-7771 * CASSANDRA-8103 * CASSANDRA-9041 * CASSANDRA-4458 * CASSANDRA-8505 Whilst they're not hard dependencies, I propose that this be done on top of both CASSANDRA-8099 and CASSANDRA-6717. The former largely because the storage engine changes may facilitate a friendlier index API, but also because of the changes to SIS mentioned above. As for 6717, the changes to schema tables there will help facilitate CASSANDRA-7771. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8143) Partitioner should not be accessed through StorageService
[ https://issues.apache.org/jira/browse/CASSANDRA-8143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14388678#comment-14388678 ] Bryn Cooke commented on CASSANDRA-8143: --- If the partitioner could be defined at the column family level then the location of data can be tuned to the dataset. Combined with custom secondary index implementations this could be a very powerful feature as you could effectively tune data locality and do local reads where appropriate. Support would need to be all the way up to the CQL level though. Partitioner should not be accessed through StorageService - Key: CASSANDRA-8143 URL: https://issues.apache.org/jira/browse/CASSANDRA-8143 Project: Cassandra Issue Type: Bug Reporter: Branimir Lambov Assignee: Branimir Lambov Priority: Minor Fix For: 3.0 The configured partitioner is no longer the only partitioner in use in the database, as e.g. index tables use LocalPartitioner. To make sure the correct partitioner is used for each table, accesses of StorageService.getPartitioner() should be replaced with retrieval of the CFS-specific partitioner. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-9041) Allow a PerRowSecondaryIndex to perform it's index operation before the underlying data has been mutated
Bryn Cooke created CASSANDRA-9041: - Summary: Allow a PerRowSecondaryIndex to perform it's index operation before the underlying data has been mutated Key: CASSANDRA-9041 URL: https://issues.apache.org/jira/browse/CASSANDRA-9041 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Bryn Cooke The current PerRowSecondaryIndex receives its index event after the call to BTree.update. This means that it is impossible to write an index that eagerly removes stale index entries. It would be great to have some sort of preIndex method that gets called with the key and column family. In addition a postIndex method that is guaranteed to get called regardless if the actual BTree operation succeeds or not would allow cleanup in the event of error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9041) Allow a PerRowSecondaryIndex to perform its index operation before the underlying data has been mutated
[ https://issues.apache.org/jira/browse/CASSANDRA-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke updated CASSANDRA-9041: -- Summary: Allow a PerRowSecondaryIndex to perform its index operation before the underlying data has been mutated (was: Allow a PerRowSecondaryIndex to perform it's index operation before the underlying data has been mutated) Allow a PerRowSecondaryIndex to perform its index operation before the underlying data has been mutated --- Key: CASSANDRA-9041 URL: https://issues.apache.org/jira/browse/CASSANDRA-9041 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Bryn Cooke The current PerRowSecondaryIndex receives its index event after the call to BTree.update. This means that it is impossible to write an index that eagerly removes stale index entries. It would be great to have some sort of preIndex method that gets called with the key and column family. In addition a postIndex method that is guaranteed to get called regardless if the actual BTree operation succeeds or not would allow cleanup in the event of error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
