[
https://issues.apache.org/jira/browse/CASSANDRA-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788148#comment-17788148
]
Stefan Miklosovic edited comment on CASSANDRA-18935 at 11/20/23 8:10 PM:
-------------------------------------------------------------------------
RPC_READY is set locally _after_ native transport is started (ports are open,
it is fully initialized and it listens to connections) and then it is
propagated by Gossip and it will eventually reach other nodes. So by the time
another node sees RPC_READY is "true" for such and such node, it is basically
guaranteed that it listens to connections. (if the node which started transport
service does not stop it by the time RPC_READY = true propagates in Gossip).
I am not sure what is the correct solution but the current one feels like a
hack. If RPC_READY is defacto irrelevant what it is set to, then we can change
it to something else, questionable to what. However, this is problematic only
for corner cases like storage node where RPC is turned off. It is quite a
bummer that the current code does not consider that scenario.
[~curlylrt] Why is it so problematic for you to have RPC started even on data
nodes? You can still firewall / blacklist them etc if you do not wish the
clients to connect to it, no?
This is patch for 3.0 I want to get in (1), I will continue on all branches
soon and I ll provide the builds.
(1) [https://github.com/apache/cassandra/pull/2923/files]
was (Author: smiklosovic):
RPC_READY is set locally _after_ native transport is started (ports are open,
it is fully initialized and it listens to connections) and then it is
propagated by Gossip and it will eventually reach other nodes. So by the time
another node sees RPC_READY is "true" for such and such node, it is basically
guaranteed that it listens to connections. (if the node which started transport
service does not stop it by the time RPC_READY = true propagates in Gossip).
I am not sure what is the correct solution but the current one feels like a
hack. If RPC_READY is defacto irrelevant what it is set to, then we can change
it to something else, questionable to what. However, this is problematic only
for a corner cases like storage node where RPC is turned off. It is quite a
bummer that the current code does not consider that scenario.
[~curlylrt] Why is it so problematic for you to have RPC started even on data
nodes? You can still firewall / blacklist them etc if you do not wish the
clients to connect to it, no?
This is patch for 3.0 I want to get in (1), I will continue on all branches
soon and I ll provide the builds.
(1) https://github.com/apache/cassandra/pull/2923/files
> Fix nodetool enable/disablebinary to correctly set rpc
> ------------------------------------------------------
>
> Key: CASSANDRA-18935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18935
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
> Reporter: Cameron Zemek
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0-rc, 5.x
>
> Attachments: 18935-3.11.patch, image-2023-11-16-10-56-16-693.png,
> signature.asc
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
>
> {code:java}
> if ((nativeFlag != null && Boolean.parseBoolean(nativeFlag)) ||
> (nativeFlag == null && DatabaseDescriptor.startNativeTransport()))
> {
> startNativeTransport();
> StorageService.instance.setRpcReady(true);
> } {code}
> The startup code here only sets RpcReady if native transport is enabled. If
> you call
> {code:java}
> nodetool enablebinary{code}
> then this flag doesn't get set.
> But with the change from CASSANDRA-13043 it requires RpcReady set to true in
> order to get a leader for the counter update.
> Not sure what the correct fix is here, seems to only really use this flag for
> counters. So thinking perhaps the fix is to just move this outside the if
> condition.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
