[
https://issues.apache.org/jira/browse/CASSANDRA-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16092807#comment-16092807
]
Jan Karlsson edited comment on CASSANDRA-13639 at 7/19/17 8:54 AM:
-------------------------------------------------------------------
If SSL is enabled, {{SSTableLoader}} always uses the hostname no matter how
your routing is set up. If you have a second interface that you route all
{{SSTableLoader}} traffic from, it will still pick your first network interface
because it corresponds with your hostname. Thereby overriding any routing you
might have set up. This screams bug to me.
The correct behavior would be for {{SSTableLoader}} to use the normal routing
of the server. I am unclear why we set the from address specifically ourself
instead of leaving it blank. I can see that it might be useful to have it as a
command variable as well. However it is quite strange to set up a 'connect
from' address.
{code}
if (encryptionOptions != null && encryptionOptions.internode_encryption
!= EncryptionOptions.ServerEncryptionOptions.InternodeEncryption.none)
{
if (outboundBindAny)
return SSLFactory.getSocket(encryptionOptions, peer,
secureStoragePort);
else
return SSLFactory.getSocket(encryptionOptions, peer,
secureStoragePort, FBUtilities.getLocalAddress(), 0);
}{code}
I am a little unclear of why the code is the way it is. The method is only
called with {{outboundBindAny}} set to false. It seems to me that calling it
without the {{FBUtilities}} call would be the correct way of calling it.
was (Author: jan karlsson):
If SSL is enabled, {SSTableLoader} always uses the hostname no matter how your
routing is set up. If you have a second interface that you route all
{SSTableLoader} traffic from, it will still pick your first network interface
because it corresponds with your hostname. Thereby overriding any routing you
might have set up. This screams bug to me.
The correct behavior would be for {SSTableLoader} to use the normal routing of
the server. I am unclear why we set the from address specifically ourself
instead of leaving it blank. I can see that it might be useful to have it as a
command variable as well. However it is quite strange to set up a 'connect
from' address.
{code}
if (encryptionOptions != null && encryptionOptions.internode_encryption
!= EncryptionOptions.ServerEncryptionOptions.InternodeEncryption.none)
{
if (outboundBindAny)
return SSLFactory.getSocket(encryptionOptions, peer,
secureStoragePort);
else
return SSLFactory.getSocket(encryptionOptions, peer,
secureStoragePort, FBUtilities.getLocalAddress(), 0);
}{code}
I am a little unclear of why the code is the way it is. The method is only
called with {outboundBindAny} set to false. It seems to me that calling it
without the {FBUtilities} call would be the correct way of calling it.
> 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
> 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
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
