Hi,
Is it possible, in code running in a bundle, to detect if the OSGi
container has a classloader that is being pinned and should have been
garbage collected.
I have recently found code (in bundle A) that registered a
implementation class with a service outside its own bundle (bundle B)
but forgot to deregister that class when bundle A restarts. (during
startup or reconfiguration)
Bundle B has a copy of the class and a reference to the classloader.
The original bundle A has gone, but the classloader remains. I have a
feeling that the classloader might be weakly referenced by the
container through wiring, but could be wrong.
This appears to causes 4 problems:
A memory leak.
B I think, but I am not certain, that the classloader is referenced
(weak(ly)) by the JSP compiler causing certain calls to
classloader.getResourceAsStream(className.replace('.','/')+".class");
to return null which makes the JSP compiler think the class is a
package. Reported in the logs, fixed by a JSP bundle restart or
container restart.
C Instability, although I am even less certain about this and don't
have evidence.
D Very occasionally a broken container on startup.
I can isolate the problem by taking a heap dump and analysing the heap
for live classes from more than one classloader where the class is not
embeded.
Is there a way of doing this in the container when it is running,
ideally exposed through the sling console ?
If not:
I have been thinking about listening to bundles start and stop and
holding weak references to their bundles and classloaders to identify
classloaders that exist with no bundle.
Although it would be better if I could load a bundle that locates all
live classloaders and builds a list of classes loaded from more than
one classloader.
Any ideas welcome ?
Best Regards
Ian
