Skip to content

KAFKA-18337: KafkaProducer Memory Leak in JmxReporter Class #18332

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

Closed
wants to merge 2 commits into from

Conversation

tmw090906
Copy link

Add a close status in JmxReporter, that avoid re-registering metrics to jmx after being closed, which could lead to memory leaks

relate KAFKA-18337

Committer Checklist (excluded from commit message)

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

…ering after being closed, which could lead to memory leaks
@github-actions github-actions bot added triage PRs from the community clients small Small PRs labels Dec 27, 2024
Copy link

github-actions bot commented Jan 4, 2025

A label of 'needs-attention' was automatically added to this PR in order to raise the
attention of the committers. Once this issue has been triaged, the triage label
should be removed to prevent this automation from happening again.

Copy link
Member

@AndrewJSchofield AndrewJSchofield 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 PR. It seems to me that the new defensive code is right down inside the reregister method, but I would have thought that the check on closed could be in the public methods such as init, metricChange and metricRemoval. All of the MBeans were unregistered when the reporter was closed already. wdyt?

@AndrewJSchofield AndrewJSchofield added ci-approved and removed needs-attention triage PRs from the community labels Jan 7, 2025
@tmw090906
Copy link
Author

Thanks for your reply! It seems that all the public methods will eventually call the reregister and the unregister . I think that the unregister method poses no potential risks after the JmxReporter is closed, so I put the check in the reregister method. wdyt?

@AndrewJSchofield
Copy link
Member

Thanks for your reply! It seems that all the public methods will eventually call the reregister and the unregister . I think that the unregister method poses no potential risks after the JmxReporter is closed, so I put the check in the reregister method. wdyt?

I prefer to do the closed check on every method which synchronizes on the lock. For one thing, some methods such as metricRemoval mess with the MBean, and then called reregister which fails. This doesn't seem like a very good pattern to me.

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 Apr 28, 2025
Copy link

This PR has been closed since it has not had any activity in 120 days. If you feel like this
was a mistake, or you would like to continue working on it, please feel free to re-open the
PR and ask for a review.

@github-actions github-actions bot added the closed-stale PRs that were closed due to inactivity label May 28, 2025
@github-actions github-actions bot closed this May 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci-approved clients closed-stale PRs that were closed due to inactivity small Small PRs stale Stale PRs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants