Uploaded image for project: 'Hibernate ORM'
  1. Hibernate ORM
  2. HHH-8363

ClassLoaderServiceImpl should be defined as Stoppable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 4.3.0.Beta3
    • Fix Version/s: 4.3.0.Beta4, 4.2.6
    • Component/s: None
    • Labels:
      None
    • Bug Testcase Reminder (view):

      Bug reports should generally be accompanied by a test case!

    • Last commented by a user?:
      true

      Description

      There are reports of Hibernate holding on to references of class loaders in a way that is somehow causing that ClassLoader to leak in Wildfly/Jipijapa. The details are a little fuzzy still, but in looking through some of the ServiceRegistry code and specifically the ClassLoaderServiceImpl and its internal AggregatedClassLoader (because of heapdump from Scott Marlow) it seems like this could be caused because ClassLoaderServiceImpl's AggregatedClassLoader does not release the ClassLoader references it holds.

      The heapdump pointed to a class we load from Jipijapa through a JDK ServiceLoader lookup using the AggregatedClassLoader. JDK ServiceLoader does do some caching of the service impls it loads somehow linked to the classloader. java.util.ServiceLoader does provide a way to refresh this cache. But not a way, that I can see, to clear it. Just something else to consider here..

      The idea here is to make ClassLoaderServiceImpl implement Stoppable so that it can receive callback from the ServiceRegistry shutdown process so that it can release these resources.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              brmeyer Brett Meyer added a comment - - edited

              Tomaz Cerar & Steve Ebersole:

              Unless I'm missing something, I think the PR is incomplete. Only the ServiceBindings within StandardServiceRegistryImpl (AbstractServiceRegistryImpl) will be stopped. But ClassLoaderServiceImpl is in the parent registry (BootstrapServiceRegistryImpl). Having AbstractServiceRegistryImpl#destroy() call parent#destroy(), then wiring in cleanup there, should do it.

              There's another gap where AbstractServiceRegistryImpl#createServiceBinding wasn't adding the binding to #serviceBindingList, used in destroy.

              Am I missing anything?

              Show
              brmeyer Brett Meyer added a comment - - edited Tomaz Cerar & Steve Ebersole : Unless I'm missing something, I think the PR is incomplete. Only the ServiceBindings within StandardServiceRegistryImpl (AbstractServiceRegistryImpl) will be stopped. But ClassLoaderServiceImpl is in the parent registry (BootstrapServiceRegistryImpl). Having AbstractServiceRegistryImpl#destroy() call parent#destroy(), then wiring in cleanup there, should do it. There's another gap where AbstractServiceRegistryImpl#createServiceBinding wasn't adding the binding to #serviceBindingList, used in destroy. Am I missing anything?
              Hide
              ctomc Tomaz Cerar added a comment -

              You are right, i am just chasing this down

              Show
              ctomc Tomaz Cerar added a comment - You are right, i am just chasing this down
              Hide
              brmeyer Brett Meyer added a comment -

              Tomaz Cerar, let me throw what I have into a new PR and have you look at it.

              Show
              brmeyer Brett Meyer added a comment - Tomaz Cerar , let me throw what I have into a new PR and have you look at it.
              Hide
              ctomc Tomaz Cerar added a comment -

              or just tell me name of your branch

              Show
              ctomc Tomaz Cerar added a comment - or just tell me name of your branch
              Show
              brmeyer Brett Meyer added a comment - https://github.com/hibernate/hibernate-orm/pull/590 https://github.com/brmeyer/hibernate-orm/tree/master_HHH-8363

                People

                • Votes:
                  1 Vote for this issue
                  Watchers:
                  5 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Time Tracking

                    Estimated:
                    Original Estimate - Not Specified
                    Not Specified
                    Remaining:
                    Remaining Estimate - Not Specified
                    Not Specified
                    Logged:
                    Time Spent - 8m
                    8m

                      Development