Bug #118528 | Connector/J Memory Leak Problem | ||
---|---|---|---|
Submitted: | 26 Jun 8:43 | Modified: | 8 Aug 19:55 |
Reporter: | ünal polat | Email Updates: | |
Status: | No Feedback | Impact on me: | |
Category: | Connector / J | Severity: | S3 (Non-critical) |
Version: | 9.1.0 | OS: | Any |
Assigned to: | MySQL Verification Team | CPU Architecture: | Any |
Tags: | Connector/J, memory-leak |
[26 Jun 8:43]
ünal polat
[8 Jul 19:55]
Filipe Silva
Hi Ünal Polat, Thank you for your interest in MySQL Connector/J and for taking the time to report this issue. As it stands, the current implementation doesn't require the spans map to be explicitly cleared. The use of a WeakHashMap in combination with the garbage collector is intended to handle this automatically. The fix you suggested doesn’t have a meaningful effect, as it would only remove a single entry from the map—the one corresponding to the span promoted as a link target (i.e., the connection creation span). All other spans are short-lived and, once the operation is complete, no strong references remain. As such, they should be eligible for garbage collection and automatically removed from the map. Are you certain that the garbage collector is not cleaning up the spans map? In my observations, this behavior appears to be working as expected. Would you be able to provide a minimal test case that reproduces the issue without involving Spring Boot? Ideally, it would include only Connector/J, OpenTelemetry, and a bit of test code to help isolate the behavior. Also, please use the latest MySQL Connector/J version.
[9 Aug 1:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".