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 ) 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.
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?
You are right, i am just chasing this down
, let me throw what I have into a new PR and have you look at it.
or just tell me name of your branch