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

Brandon Williams updated CASSANDRA-11332:
-----------------------------------------
    Description: 
I tested this with both the simple snitch and PFS.  It's quite easy to repro, 
setup a cluster, start it.  Mine looks like this:

{noformat}
tcp        0      0 10.208.8.123:48003      10.208.8.63:7000        ESTABLISHED 
26254/java
tcp        0      0 10.208.8.123:7000       10.208.8.63:40215       ESTABLISHED 
26254/java
tcp        0      0 10.208.8.123:55559      10.208.35.225:7000      ESTABLISHED 
26254/java
tcp        0      0 10.208.8.123:33498      10.208.8.63:7000        ESTABLISHED 
26254/java
tcp        0      0 10.208.8.123:7000       10.208.35.225:52530     ESTABLISHED 
26254/java
tcp        0      0 10.208.8.123:7000       10.208.35.225:53674     ESTABLISHED 
26254/java
tcp        0      0 10.208.8.123:40846      10.208.35.225:7000      ESTABLISHED 
26254/java
tcp        0      0 10.208.8.123:7000       10.208.8.63:48880       ESTABLISHED 
26254/java
{noformat}

No problems so far.  Now create a keyspace using NTS with an rf of 3, and 
perform some writes.  Now it looks like this:

{noformat}
tcp        0      0 10.208.8.123:48003      10.208.8.63:7000        ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:7000       10.208.8.123:35024      ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:35024      10.208.8.123:7000       ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:47212      10.208.8.123:7000       ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:7000       10.208.8.63:40215       ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:55559      10.208.35.225:7000      ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:33498      10.208.8.63:7000        ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:7000       10.208.35.225:52530     ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:7000       10.208.35.225:53674     ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:7000       10.208.8.123:47212      ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:40846      10.208.35.225:7000      ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:7000       10.208.8.63:48880       ESTABLISHED 
26254/java  
{noformat}

I can't think of any reason for a node to connect to itself, and this can cause 
problems with PFS where you might only define the broadcast addresses, but now 
you need the internal addresses too because the node will need to look itself 
up when connecting to itself.

  was:
I tested this with both the simple snitch and PFS.  It's quite easy to repro, 
setup a cluster, start it.  Mine looks like this:

{noformat}
tcp        0      0 10.208.8.123:48003      10.208.8.63:7000        ESTABLISHED 
26254/java
tcp        0      0 10.208.8.123:7000       10.208.8.63:40215       ESTABLISHED 
26254/java
tcp        0      0 10.208.8.123:55559      10.208.35.225:7000      ESTABLISHED 
26254/java
tcp        0      0 10.208.8.123:33498      10.208.8.63:7000        ESTABLISHED 
26254/java
tcp        0      0 10.208.8.123:7000       10.208.35.225:52530     ESTABLISHED 
26254/java
tcp        0      0 10.208.8.123:7000       10.208.35.225:53674     ESTABLISHED 
26254/java
tcp        0      0 10.208.8.123:40846      10.208.35.225:7000      ESTABLISHED 
26254/java
tcp        0      0 10.208.8.123:7000       10.208.8.63:48880       ESTABLISHED 
26254/java
{noformat}

No problems so far.  Now create a keyspace using NTS with an rf of 3, and 
perform some writes.  Now it looks like this:

{noformat}
tcp        0      0 10.208.8.123:48003      10.208.8.63:7000        ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:7000       10.208.8.123:35024      ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:35024      10.208.8.123:7000       ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:47212      10.208.8.123:7000       ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:7000       10.208.8.63:40215       ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:55559      10.208.35.225:7000      ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:33498      10.208.8.63:7000        ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:7000       10.208.35.225:52530     ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:7000       10.208.35.225:53674     ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:7000       10.208.8.123:47212      ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:40846      10.208.35.225:7000      ESTABLISHED 
26254/java      
tcp        0      0 10.208.8.123:7000       10.208.8.63:48880       ESTABLISHED 
26254/java  
{noformat}

I can't think of any reason for a node to connect to itself, and this can cause 
problems with PFS where you might only define the broadcast addresses, but now 
you need the internal addresses to because the node will need to look itself up 
when connecting to itself.


> nodes connect to themselves when NTS is used
> --------------------------------------------
>
>                 Key: CASSANDRA-11332
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11332
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Brandon Williams
>             Fix For: 2.1.x
>
>
> I tested this with both the simple snitch and PFS.  It's quite easy to repro, 
> setup a cluster, start it.  Mine looks like this:
> {noformat}
> tcp        0      0 10.208.8.123:48003      10.208.8.63:7000        
> ESTABLISHED 26254/java
> tcp        0      0 10.208.8.123:7000       10.208.8.63:40215       
> ESTABLISHED 26254/java
> tcp        0      0 10.208.8.123:55559      10.208.35.225:7000      
> ESTABLISHED 26254/java
> tcp        0      0 10.208.8.123:33498      10.208.8.63:7000        
> ESTABLISHED 26254/java
> tcp        0      0 10.208.8.123:7000       10.208.35.225:52530     
> ESTABLISHED 26254/java
> tcp        0      0 10.208.8.123:7000       10.208.35.225:53674     
> ESTABLISHED 26254/java
> tcp        0      0 10.208.8.123:40846      10.208.35.225:7000      
> ESTABLISHED 26254/java
> tcp        0      0 10.208.8.123:7000       10.208.8.63:48880       
> ESTABLISHED 26254/java
> {noformat}
> No problems so far.  Now create a keyspace using NTS with an rf of 3, and 
> perform some writes.  Now it looks like this:
> {noformat}
> tcp        0      0 10.208.8.123:48003      10.208.8.63:7000        
> ESTABLISHED 26254/java      
> tcp        0      0 10.208.8.123:7000       10.208.8.123:35024      
> ESTABLISHED 26254/java      
> tcp        0      0 10.208.8.123:35024      10.208.8.123:7000       
> ESTABLISHED 26254/java      
> tcp        0      0 10.208.8.123:47212      10.208.8.123:7000       
> ESTABLISHED 26254/java      
> tcp        0      0 10.208.8.123:7000       10.208.8.63:40215       
> ESTABLISHED 26254/java      
> tcp        0      0 10.208.8.123:55559      10.208.35.225:7000      
> ESTABLISHED 26254/java      
> tcp        0      0 10.208.8.123:33498      10.208.8.63:7000        
> ESTABLISHED 26254/java      
> tcp        0      0 10.208.8.123:7000       10.208.35.225:52530     
> ESTABLISHED 26254/java      
> tcp        0      0 10.208.8.123:7000       10.208.35.225:53674     
> ESTABLISHED 26254/java      
> tcp        0      0 10.208.8.123:7000       10.208.8.123:47212      
> ESTABLISHED 26254/java      
> tcp        0      0 10.208.8.123:40846      10.208.35.225:7000      
> ESTABLISHED 26254/java      
> tcp        0      0 10.208.8.123:7000       10.208.8.63:48880       
> ESTABLISHED 26254/java  
> {noformat}
> I can't think of any reason for a node to connect to itself, and this can 
> cause problems with PFS where you might only define the broadcast addresses, 
> but now you need the internal addresses too because the node will need to 
> look itself up when connecting to itself.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to