I drilled into the dominator tree to look at some of the data. After I let the app run for 24 hours I can look com.hazelcast.cache.impl.record.CacheDataRecord.expirationTime and see if current time exceeds that time. Since it's replicating data it's going to start off with cached items because I do rolling deployments, so when I start TomEE it will replicate with the running node. I just want to make sure this is a real leak.
On Mon, Jul 25, 2016 at 1:27 PM, Romain Manni-Bucau <[email protected]> wrote: > so URLClassLoader is likely common-loader, question is: if hazelcast is > loaded from the webapp why does it uses the parent loader? > > API is there but providing the classloader it shouldn't rely on this. > > > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> | JavaEE Factory > <https://javaeefactory-rmannibucau.rhcloud.com> > > 2016-07-25 18:39 GMT+02:00 sgjava <[email protected]>: > > > OK, it still is detected by MAT as a leak: > > > > // Use TCCL to avoid heap leak > > cachingProvider = > > > Caching.getCachingProvider(Thread.currentThread().getContextClassLoader()); > > > > One instance of "com.hazelcast.cache.impl.CacheService" loaded by > > "java.net.URLClassLoader @ 0x807026b8" occupies 28,644,400 (36.85%) > bytes. > > The memory is accumulated in one instance of > > "com.hazelcast.cache.impl.CachePartitionSegment[]" loaded by > > "java.net.URLClassLoader @ 0x807026b8". > > > > > > > > -- > > View this message in context: > > > http://tomee-openejb.979440.n4.nabble.com/Heap-leak-as-JCache-provider-tp4679471p4679478.html > > Sent from the TomEE Users mailing list archive at Nabble.com. > > > -- Steven P. Goldsmith
