[
https://issues.apache.org/jira/browse/CASSANDRA-11332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189031#comment-15189031
]
Sylvain Lebresne commented on CASSANDRA-11332:
----------------------------------------------
bq. I can't think of any reason for a node to connect to itself
There is quite a few places where we don't special case the local case and just
go through {{MessagingService}} even for localhost out of simplicity. Of the
top of my head I believe that's at least the case for truncation, repair and
most of Paxos messages, but I'm sure I'm missing some. And {{MessagingService}}
don't special case the local host either.
I'll note that afaict normal writes and schema both do special case the local
host so I'm not sure why you can reproduce with just adding a keyspace and
doing a few writes (unless those write include LWT in which that's definitively
due to Paxos), but I'm sure I'm forgotting something that is not special cases
and I'm not surprised at all.
Now, we could modify {{MessagingService}} I suppose to special case local
messages, though we still want sending to be non-blocking so we'll still need a
specific thread with a queue, and we probably still want to preserve the
protection we have like dropping messages too old (which, while I'm fine
implementing that solution, make me uncomfortable doing it on an old branch).
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?)
but we could also fix it so it recognize that both broadcast and listen
addresses mean the same thing.
> 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)
