[
https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706907#comment-17706907
]
Brandon Williams edited comment on CASSANDRA-16999 at 3/30/23 2:12 PM:
-----------------------------------------------------------------------
In the current state, via the system table we expose "native_address" and
"native_port" to clients. In the yaml config we have "rpc_address" and
"native_transport_port" and "native_transport_port_ssl". It would seem from
the server perspective all we are really missing is exposing "native_port_ssl"
to clients?
As far as I can tell "native_transport_port" has always only been a yaml option
and not exposed to drivers, and "native_transport_address" has never existed.
If we want to rename "rpc_address" to "native_transport_address" that is
probably worth its own ticket, but for this one the most consistent thing seems
to be adding "native_port_ssl" to me.
was (Author: brandon.williams):
In the current state, via the system table we expose "native_address" and
"native_port" to clients. In the yaml config we have "rpc_address" and
"native_transport_port" and "native_transport_port_ssl". It would seem from
the server perspective all we are really missing is exposing "native_port_ssl"
to clients?
As far as I can tell "native_transport_address" and "native_transport_port"
have always only been yaml options and not exposed to drivers, and renaming
these is problematic and I don't think buys us much.
> system.peers and system.peers_v2 do not contain the native_transport and/or
> native_transport_port_ssl
> -----------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-16999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16999
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
> Reporter: Steve Lacerda
> Assignee: Brandon Williams
> Priority: Normal
> Fix For: 4.0.x, 5.x
>
>
> system.peers_v2 includes a “native_port” but has no notion of
> native_transport_port vs. native_transport_port_ssl. Given this limited
> information, there’s no clear way for the driver to know that different ports
> are being used for SSL vs. non-SSL or which of those two ports is identified
> by “native_port”.
>
> The issue we ran into is that the java driver, since it has no notion of the
> transport port SSL, the driver was only using the contact points and was not
> load balancing.
>
> The customer had both set:
> native_transport_port: 9042
> native_transport_port_ssl: 9142
>
> They were attempting to connect to 9142, but that was failing. They could
> only use 9042, and so their applications load balancing was failing. We found
> that any node that was a contact point was connecting, but the other nodes
> were never acting as coordinators.
>
> There are still issues in the driver, for which I have created JAVA-2967,
> which also refers to JAVA-2638, but the system.peers and system.peers_v2
> tables should both contain native_transport_port and
> native_transport_port_ssl.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
