[
https://issues.apache.org/jira/browse/CASSANDRA-11181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17422426#comment-17422426
]
Aleksei Zotov edited comment on CASSANDRA-11181 at 10/1/21, 12:17 PM:
----------------------------------------------------------------------
h3. ssl_storage_port
I have a different perception on {{ssl_storage_port}}. Even if 16830 gets
delayed, I see no need to expose {{ssl_storage_port}} since it is deprecated.
People should not generally use deprecated properties, so there should be no
much value of exposing it. For me it seems to be a work without much value: we
introduce the field (without having enough justification that someone really
needs it) and then soon remove.
I'm not really familiar with many real use cases, maybe some people really
struggle without this functionality. But, frankly speaking, I'm not clear what
the use of such exposing is unless someone develops a library or smth very
flexible. Within an organization some static value is generally used (even if
it might be non default) and people may simply assume (as a workaround until
the property is completely removed) the port number since it is not dynamic.
Please, share your thoughts.
h3. listen_on_broadcast_address
{quote}While the settings are kept as they they, uses of that method will
ignore any defined {{listen_address}}.
{quote}
[~mck] are you sure? Here is what I can see locally:
{code:java}
INFO [Messaging-EventLoop-3-3] 2021-09-30 02:01:07,675
OutboundConnection.java:1150 -
/127.0.0.4:7000(/127.0.0.1:49010)->/127.0.0.1:7000-URGENT_MESSAGES-736a3123
successfully connected, version = 12, framing = CRC, encryption = unencrypted
INFO [Messaging-EventLoop-3-4] 2021-09-30 02:01:07,692
InboundConnectionInitiator.java:484 -
/127.0.0.4:7000(/127.0.0.1:49010)->localhost/127.0.0.1:7000-URGENT_MESSAGES-393447d2
messaging connection established, version = 12, framing = CRC, encryption =
unencrypted
INFO [Messaging-EventLoop-3-3] 2021-09-30 02:01:07,712
OutboundConnection.java:1150 -
/127.0.0.4:7000(/127.0.0.1:47290)->/127.0.0.4:7000-URGENT_MESSAGES-d8dd5b25
successfully connected, version = 12, framing = CRC, encryption = unencrypted
INFO [Messaging-EventLoop-3-4] 2021-09-30 02:01:07,713
InboundConnectionInitiator.java:484 -
/127.0.0.4:7000(/127.0.0.1:47290)->localhost/127.0.0.1:7000(/127.0.0.4:7000)-URGENT_MESSAGES-d3120790
messaging connection established, version = 12, framing = CRC, encryption =
unencrypted{code}
for configuration:
{code:java}
broadcast_address: 127.0.0.4
listen_address: localhost
listen_on_broadcast_address: true
{code}
This configuration failed with "listen_address: localhost" (I have not checked
why, maybe that would dispel my confusion - the devil is in the details :)),
but the point is that C* seems to listen on both IPs. So the behavior you
explained earlier:
{code:java}
broadcast_address = FBUtilities.getJustBroadcastAddress() # broadcast_address
orElse same-as-listen_address-below
listen_address = FBUtilities.getJustLocalAddress()
# listen_address orElse listen_interface orElse InetAddress.getLocalHost()
orElse InetAddress.getLoopbackAddress()
{code}
seems to be correct to me.
I'm just confused on what seems to be wrong. Could you please highlight what
I'm missing.
was (Author: azotcsit):
h3. ssl_storage_port
I have a different perception on {{ssl_storage_port}}. Even if 16830 gets
delayed, I see no need to expose {{ssl_storage_port}} since it is deprecated.
People should not generally use deprecated properties, so there should be no
much value of exposing it. For me it seems to be a work without much value: we
introduce the field (without having enough justification that someone really
needs it) and then soon remove.
I'm not really familiar with many real use cases, maybe some people really
struggle without this functionality. But, frankly speaking, I'm not clear what
the use of such exposing is unless someone develops a library or smth very
flexible. Within an organization some static value is generally used (even if
it might be non default) and people may simply assume (as a workaround until
the property is completely removed) the port number since it is not dynamic.
Please, share your thoughts.
h3. listen_on_broadcast_address
{quote}While the settings are kept as they they, uses of that method will
ignore any defined {{listen_address}}.
{quote}
[~mck] are you sure? Here is what I can see locally:
{code:java}
INFO [Messaging-EventLoop-3-3] 2021-09-30 02:01:07,675
OutboundConnection.java:1150 -
/127.0.0.4:7000(/127.0.0.1:49010)->/127.0.0.1:7000-URGENT_MESSAGES-736a3123
successfully connected, version = 12, framing = CRC, encryption = unencrypted
INFO [Messaging-EventLoop-3-4] 2021-09-30 02:01:07,692
InboundConnectionInitiator.java:484 -
/127.0.0.4:7000(/127.0.0.1:49010)->localhost/127.0.0.1:7000-URGENT_MESSAGES-393447d2
messaging connection established, version = 12, framing = CRC, encryption =
unencrypted
INFO [Messaging-EventLoop-3-3] 2021-09-30 02:01:07,712
OutboundConnection.java:1150 -
/127.0.0.4:7000(/127.0.0.1:47290)->/127.0.0.4:7000-URGENT_MESSAGES-d8dd5b25
successfully connected, version = 12, framing = CRC, encryption = unencrypted
INFO [Messaging-EventLoop-3-4] 2021-09-30 02:01:07,713
InboundConnectionInitiator.java:484 -
/127.0.0.4:7000(/127.0.0.1:47290)->localhost/127.0.0.1:7000(/127.0.0.4:7000)-URGENT_MESSAGES-d3120790
messaging connection established, version = 12, framing = CRC, encryption =
unencrypted{code}
for configuration:
{code:java}
broadcast_address: 127.0.0.4
listen_address: localhost
{code}
This configuration failed with "listen_address: localhost" (I have not checked
why, maybe that would dispel my confusion - the devil is in the details :)),
but the point is that C* seems to listen on both IPs. So the behavior you
explained earlier:
{code:java}
broadcast_address = FBUtilities.getJustBroadcastAddress() # broadcast_address
orElse same-as-listen_address-below
listen_address = FBUtilities.getJustLocalAddress()
# listen_address orElse listen_interface orElse InetAddress.getLocalHost()
orElse InetAddress.getLoopbackAddress()
{code}
seems to be correct to me.
I'm just confused on what seems to be wrong. Could you please highlight what
I'm missing.
> Add broadcast_rpc_address to system.local
> -----------------------------------------
>
> Key: CASSANDRA-11181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11181
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Distributed Metadata
> Reporter: Nick Bailey
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Right now it's impossible to get the broadcast_rpc_address of the node you
> are connected to via the drivers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
