Hi Chetan I like this very much. Cool work +1 to get this into Sling, if you will :-)
Two comments: * There is a stray pom.xml in the src folder * I suggest to use BundleTracker which takes aways the burden of initial bundle scan from you. Regards Felix Am 31.01.2014 um 11:17 schrieb Chetan Mehrotra <[email protected]>: > Hi Ian, > > I implemented the proposed approach in [1]. Can you give it a try and > let me know if it works for you. > > Chetan Mehrotra > [1] https://github.com/chetanmeh/sling-leak-detector > > On Wed, Jan 29, 2014 at 5:43 PM, Felix Meschberger <[email protected]> wrote: >> Hi >> >> Agreed, this sounds like an interesting approach to follow. >> >> Regards >> Felix >> >> Am 29.01.2014 um 12:21 schrieb Chetan Mehrotra <[email protected]>: >> >>> One possible approach can be that >>> >>> 1. Have a custom bundle listener. This would maintain some structure >>> around bundle >>> 2. Use Java Phantom reference [1] to register a callback for GC of >>> classloader associated with the bundle. Upon gc callback we remove the >>> information >>> >>> Then have a web console plugin which can look into the current data >>> structure maintained by the listener. It would then check the state >>> against actual active bundle and flag the suspects. And if left over a >>> period of time can easly mark out stale bundles which are leaking. >>> Should not incur any performance cost >>> >>> Chetan Mehrotra >>> [1] >>> http://docs.oracle.com/javase/7/docs/api/java/lang/ref/PhantomReference.html >>
