Skip to content

CASSANALYTICS-130 Support per-instance sidecar port resolution in CDC client#187

Open
Klose6 wants to merge 6 commits intoapache:trunkfrom
Klose6:CASSANALYTICS-130
Open

CASSANALYTICS-130 Support per-instance sidecar port resolution in CDC client#187
Klose6 wants to merge 6 commits intoapache:trunkfrom
Klose6:CASSANALYTICS-130

Conversation

@Klose6
Copy link
Copy Markdown

@Klose6 Klose6 commented Mar 26, 2026

Currently when the sidecar tries to call another sidecar instance it assumes another sidecar will use the same port as itself, this change make the port as a input parameter so that the downstream caller can have the option to pass in the port if other sidecar is using a different port.

Copy link
Copy Markdown
Contributor

@jberragan jberragan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the patch, I made a couple of suggestions.

protected ClusterConfigProvider clusterConfigProvider;
protected SidecarCdcClient sidecarCdcClient;
@NotNull
protected Function<String, Integer> portResolver;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you keep a default implementation that returns (ignored) -> config.effectivePort() so we keep the preexisting behavior. Then add a builder method e.g. withPortResolver if users wish to override with their own implementation.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, I added the preexisting behavior in the constructor and another new constructor for the new portResolver parameter, also I just found this latest commit so I add the withPortResolver() in SidecarCdcClient and SidecarCdcBuilder to support the port resolving. Thanks!

Copy link
Copy Markdown
Author

@Klose6 Klose6 Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jberragan I double check the latest commit and think we don't need the changes on SidecarCdcBuilder now because the SidecarCdcClient is a input parameter to SidecarCdc now, remove the withPortResolver() in SidecarCdcBuilder and only the changes in sidecarCdcClient, thanks!

* Builds a port resolver function from the {@link CdcSidecarInstancesProvider}. The resolver looks up
* the port for a given hostname from the provider, falling back to the configured effective port.
*/
static Function<String, Integer> buildPortResolver(@NotNull CdcSidecarInstancesProvider provider,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit O(n) can we change the interface to be (CassandraInstance) -> Integer, that way we can just return:

    (instance) -> instance.port();

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this latest commit it accepts the sidecarCdcClient in the SidecarCdc.java so I removed this and in cassandra-sidecar we can inject the sidecar port mapping into the sidecarCdcClient with its added withPortResolver() when calls the SidecarCdc.builder().

@Klose6 Klose6 force-pushed the CASSANALYTICS-130 branch from 742ce8a to 347a59c Compare April 2, 2026 00:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants