[
https://issues.apache.org/jira/browse/CASSANDRA-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565346#comment-16565346
]
Jan Karlsson edited comment on CASSANDRA-13639 at 8/1/18 1:56 PM:
------------------------------------------------------------------
I apologize for my long absence but I have time look into this now.
{quote}If outboundBindAny would be set to true, then the SSL Socket would be
bound to any local address, which is most likely not what we want, so not sure
why we would ever want to set outboundBindAny to true anyway.
{quote}
I actually believe the contrary. Having the SSL Socket bound to the address
which is specified by your operating system's routing is precisely what we
want. It seens fishy that we always pick the local address and ignore the
routing of the operating system.
{quote}I agree with [[email protected]] here because I think having a cmd line
parameter seems to be better. Something like {{--localOutboundAddressSSL-}} or
{{-sslLocalOutboundAddress}}, which defaults to
{{FBUtilities.getLocalAddress()}}.
{quote}
I can see the point of adding a flag for the simple fact that we would not
break backward compatibility, but we should also consider that picking the
first interface no matter what routing is set up seems like faulty behavior.
If we choose to go this route to keep backwards compatibility, we should
describe this behavior in the documentation. The error I received was rather
strange when I hit this issue locally on my machine and required me to dig
quite deep to find the root cause.
was (Author: jan karlsson):
I apologize for my long absence but I have time look into this now.
{quote}If outboundBindAny would be set to true, then the SSL Socket would be
bound to any local address, which is most likely not what we want, so not sure
why we would ever want to set outboundBindAny to true anyway.
{quote}
I actually believe the contrary. Having the SSL Socket bound to the local
address which is specified by your operating system's routing is precisely what
we want. It seens fishy that we always pick the local address and ignore the
routing of the operating system.
{quote}I agree with [[email protected]] here because I think having a cmd line
parameter seems to be better. Something like {{--localOutboundAddressSSL-}} or
{{-sslLocalOutboundAddress}}, which defaults to
{{FBUtilities.getLocalAddress()}}.
{quote}
I can see the point of adding a flag for the simple fact that we would not
break backward compatibility, but we should also consider that picking the
first interface no matter what routing is set up seems like faulty behavior.
If we choose to go this route to keep backwards compatibility, we should
describe this behavior in the documentation. The error I received was rather
strange when I hit this issue locally on my machine and required me to dig
quite deep to find the root cause.
> SSTableLoader always uses hostname to stream files from
> -------------------------------------------------------
>
> Key: CASSANDRA-13639
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13639
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Reporter: Jan Karlsson
> Assignee: Jan Karlsson
> Priority: Major
> Fix For: 4.x
>
> Attachments: 13639-trunk
>
>
> I stumbled upon an issue where SSTableLoader was ignoring our routing by
> using the wrong interface to send the SSTables to the other nodes. Looking at
> the code, it seems that we are using FBUtilities.getLocalAddress() to fetch
> out the hostname, even if the yaml file specifies a different host. I am not
> sure why we call this function instead of using the routing by leaving it
> blank, perhaps someone could enlighten me.
> This behaviour comes from the fact that we use a default created
> DatabaseDescriptor which does not set the values for listenAddress and
> listenInterface. This causes the aforementioned function to retrieve the
> hostname at all times, even if it is not the interface used in the yaml file.
> I propose we break out the function that handles listenAddress and
> listenInterface and call it so that listenAddress or listenInterface is
> getting populated in the DatabaseDescriptor.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
