Skip to content

KAFKA-17601: Inter-broker connections do not expose their clientSoftwareName and clientSoftwareVersion tags #17731

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: trunk
Choose a base branch
from

Conversation

FrankYang0529
Copy link
Member

When Kafka brokers are connecting to other brokers this information is not properly populated, we see the "unknown" value instead for both ClientSoftwareName and ClientSoftwareVersion. The reason is that we updated ClientInformation in ChannelMetadataRegistry after we built RequestConext. We should initialize ClientInformation before setup RequestContext.

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

// KIP-511: ApiVersionsRequest is intercepted here to catch the client software name
// and version. It is done here to avoid wiring things up to the api layer.
if (header.apiKey == ApiKeys.API_VERSIONS) {
val apiVersionsRequest = req.body[ApiVersionsRequest]
val result = RequestContext.staticParseRequest(header, receive.payload, connectionId, listenerName, channel.principal)
val apiVersionsRequest = result.request.asInstanceOf[ApiVersionsRequest]
if (apiVersionsRequest.isValid) {
channel.channelMetadataRegistry.registerClientInformation(new ClientInformation(
apiVersionsRequest.data.clientSoftwareName,
apiVersionsRequest.data.clientSoftwareVersion))
Copy link
Member

Choose a reason for hiding this comment

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

Could we update context#clientInformation directly?

Copy link
Member

Choose a reason for hiding this comment

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

What I mean is that context#clientInformation gets updated when the request is related to API_VERSIONS.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hi @chia7712, thanks for the suggestion. I updated code. Could you take a look again? Thanks.

…areName and clientSoftwareVersion tags

Signed-off-by: PoAn Yang <[email protected]>
@ijuma
Copy link
Member

ijuma commented Dec 24, 2024

We previously did not send api versions for inter broker connections, has that been changed?

assertEquals(ClientInformation.UNKNOWN_NAME_OR_VERSION, receivedReq.context.clientInformation.softwareName)
assertEquals(ClientInformation.UNKNOWN_NAME_OR_VERSION, receivedReq.context.clientInformation.softwareVersion)
assertEquals(expectedClientSoftwareName, receivedReq.context.clientInformation.softwareName)
assertEquals(expectedClientSoftwareVersion, receivedReq.context.clientInformation.softwareVersion)
Copy link
Member

Choose a reason for hiding this comment

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

The comment above these lines is wrong with this change. I assume there was a reason for the original behavior though - @dajac @rajinisivaram do you recall?

public final ClientInformation clientInformation;
// The client information can be updated if the request is ApiVersionRequest,
// so the client information will not be unknown for ApiVersionRequest.
public ClientInformation clientInformation;
Copy link
Member

Choose a reason for hiding this comment

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

Making this mutable and public seems dangerous. A few things to consider:

  1. Thread safety.
  2. Whether we want to allow it to be updated only once (if so, we'd want to have a method that enforces that).

Copy link

This PR is being marked as stale since it has not had any activity in 90 days. If you
would like to keep this PR alive, please leave a comment asking for a review. If the PR has
merge conflicts, update it with the latest from the base branch.

If you are having difficulty finding a reviewer, please reach out on the [mailing list](https://kafka.apache.org/contact).

If this PR is no longer valid or desired, please feel free to close it. If no activity occurs in the next 30 days, it will be automatically closed.

@github-actions github-actions bot added the stale Stale PRs label Mar 25, 2025
@FrankYang0529 FrankYang0529 removed the stale Stale PRs label Mar 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants