You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Aleksei Zotov (Jira)" <ji...@apache.org> on 2021/10/01 12:18:00 UTC
[jira] [Comment Edited] (CASSANDRA-11181) Add broadcast_rpc_address
to system.local
[ 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org