[
https://issues.apache.org/jira/browse/CASSANDRA-11332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189577#comment-15189577
]
Brandon Williams commented on CASSANDRA-11332:
----------------------------------------------
bq. But truth is, I'm not sure I understand the concrete consequence this has
for PropertyFileSnitch (that is, have you noticed a genuine bug due to this?)
Yes, I actually saw someone using PFS get bitten by this. If your nodes always
use BCA, you'd think you only need BCA IPs in the property file. But since the
node connects to itself on listen_address, now you need to have that internal
IP in the file as well or have a default, or it will complain about not being
able to find it when it connects to itself. Since the property file should be
the same everywhere, now you have to add *all* the internal listen_address IPs
to the property file in addition to the BCAs (setting a default isn't viable in
a multi-dc configuration.) GPFS gets around this by pure luck since we're
pulling it via gossip for the endpoint.
> 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)
