MINOR : lower Metadata info log to debug for topic ID change#12378
MINOR : lower Metadata info log to debug for topic ID change#12378nicolasguyomar wants to merge 1 commit intoapache:trunkfrom
Conversation
Hi team, Minor suggestion to lower that new log to DEBUG as we used not to have any INFO log in this class and it looks like something has changed when you start a client while it's just the first metadata response result which is triggering the log with a somehow worrisome change from null to an actual topicID, as if something was not OK before, because null, and now it's good Let me know what you think Thank you
Can you clarify this point? Are you seeing this log on startup? This message should only be logged when the ID was not null. |
|
Hello @jolshan Yes you will see the log on any consumer/producer startup |
|
I'm not sure I follow why this happens though -- can you share an example of one of the logs? |
|
Hello @jolshan , this is a Confluent Bundle 7.2.0 console producer output, producing a "test" message in topic "nicolas" You'll see that upon receiving the first Metadata response, we log the message that I would like to "hide", but you're probably right we should not log it at all [2022-07-19 15:35:41,214] INFO [Producer clientId=console-producer] Resetting the last seen epoch of partition nicolas-0 to 0 since the associated topicId changed from null to 7OdYyViuRY2XmggNWuP_Vg (org.apache.kafka.clients.Metadata) |
|
Ah looks like the issue is that the oldID is null (not the new ID). As described by this comment: So based on this comment, we do want to override the epoch. Just curious why this one extra log message was causing issues. I suppose one thing we can do is check if this is the first metadata response/ if the epochs are equal, but not sure how much this helps. |
Context ------- Since updating to kafka client 3.0.1, we noticed quite a lot of new info-level logs generated by `org.apache.kafka.clients.Metadata`. The logs look like this: ``` [Producer clientId=producer-1] Resetting the last seen epoch of partition user-3 to 2044 since the associated topicId changed from null to O5w7zNcCTpKdylvkOUMesQ ``` They appear at seemingly random times, while keeping the same last seen epoch value. Proposed fix ------------ As suggested in apache#12378, I am updating the code condition to avoid generating a log when the last seen epoch reset operation is a no-op.
|
This PR is being marked as stale since it has not had any activity in 90 days. If you 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. |
Hi team,
Minor suggestion to lower that new log to DEBUG as we used not to have any INFO log in this class and it looks like something has changed when you start a client while it's just the first metadata response result which is triggering the log with a somehow worrisome change from null to an actual topicID, as if something was not OK before, because null, and now it's good
Let me know what you think
Thank you
More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)