Uploaded image for project: 'MariaDB Connector/J'
  1. MariaDB Connector/J
  2. CONJ-563

Thread leak reported by Tomcat when using the connector

Details

    • Task
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Fixed
    • 2.2.1
    • 2.5.0
    • batch
    • None
    • Linux 64-bit rhel07

    Description

      When used in a Tomcat application, the following thread leaks are reported sometimes:

      WARNING: The web application [...] appears to have started a thread named [MariaDb-bulk-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: sun.misc.Unsafe.park(Native Method)
      

      The Driver is properly unloaded. It seems like these threads are not being joined.

      Attachments

        Issue Links

          Activity

            diego dupin Diego Dupin added a comment -

            Closing since discoverd and corrected with CONJ-671

            diego dupin Diego Dupin added a comment - Closing since discoverd and corrected with CONJ-671

            I don't see this is fixed at all. I still get the same error with v2.4.3.

            I believe the source of the issue is that the class org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol has a ThreadPoolExecutor stored in the variable "readScheduler" that is never shutdown... there maybe other resources in mariadb's connector/j that aren't properly shut down as well but this is on I always run into as well.

            The org.mariadb.jdbc.Driver class should be creating a DriverAction that should shutdown these executors and free resources etc. "DriverManager.registerDriver(new Driver());" is where the DriverAction should be passed which is called when DriverManager.deregisterDriver is called.

            Art Fiedler Arthur Fiedler added a comment - I don't see this is fixed at all. I still get the same error with v2.4.3. I believe the source of the issue is that the class org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol has a ThreadPoolExecutor stored in the variable "readScheduler" that is never shutdown... there maybe other resources in mariadb's connector/j that aren't properly shut down as well but this is on I always run into as well. The org.mariadb.jdbc.Driver class should be creating a DriverAction that should shutdown these executors and free resources etc. "DriverManager.registerDriver(new Driver());" is where the DriverAction should be passed which is called when DriverManager.deregisterDriver is called.
            diego dupin Diego Dupin added a comment - - edited

            right, the error has been reproduced.
            Correction is done with this commit correcting these thread leak.

            This will only be in 2.5.0 release since it changes the interface of pool implementation (a new close method) that has to be implemented for customs implementations.

            diego dupin Diego Dupin added a comment - - edited right, the error has been reproduced. Correction is done with this commit correcting these thread leak. This will only be in 2.5.0 release since it changes the interface of pool implementation (a new close method) that has to be implemented for customs implementations.

            Nice work Diego, I didn't test the changes yet but I reviewed the commit and you did exactly what I was thinking needed to be done when I was originally reviewing the problem.

            One tiny concern that would be irrelevant to me but maybe valid for someone else... If the default provider is used at some point and then setSchedulerProvider is used later with a custom provider, the resources used in the default provider wouldn't be closed... not sure the proper handling of what to do in that case other than tracking all providers used and then verifying on the deregister that all were closed, or if a simple note in the javadoc would be fine, but I would think whoever calls that method probably shouldn't have used the default provider to start with if a custom provider was intended.

            Art Fiedler Arthur Fiedler added a comment - Nice work Diego, I didn't test the changes yet but I reviewed the commit and you did exactly what I was thinking needed to be done when I was originally reviewing the problem. One tiny concern that would be irrelevant to me but maybe valid for someone else... If the default provider is used at some point and then setSchedulerProvider is used later with a custom provider, the resources used in the default provider wouldn't be closed... not sure the proper handling of what to do in that case other than tracking all providers used and then verifying on the deregister that all were closed, or if a simple note in the javadoc would be fine, but I would think whoever calls that method probably shouldn't have used the default provider to start with if a custom provider was intended.

            Another thought would be just to call close on the default provider and the current provider set, and if the coder is doing something strange with more then one custom provider their responsible for closing?

            Art Fiedler Arthur Fiedler added a comment - Another thought would be just to call close on the default provider and the current provider set, and if the coder is doing something strange with more then one custom provider their responsible for closing?
            diego dupin Diego Dupin added a comment -

            reopenning issue, since it might not be relevant for the use case, but it would be better to handle that anyway : after deregistration of the driver, if it's registered afterwhile, the thread pools that have been already used and registered as static like here would be in an inconsistent state.

            I'll handle closing previous implementation when assigning custom Implementation at the same time.

            diego dupin Diego Dupin added a comment - reopenning issue, since it might not be relevant for the use case, but it would be better to handle that anyway : after deregistration of the driver, if it's registered afterwhile, the thread pools that have been already used and registered as static like here would be in an inconsistent state. I'll handle closing previous implementation when assigning custom Implementation at the same time.

            People

              diego dupin Diego Dupin
              bgedik Bugra Gedik
              Votes:
              3 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.