Potential thread leak in echache3

[sgup432]

I was trying echache3 (3.10.8) purely as a disk store. While testing with multiple gets/puts, it works fine as expected.

But when I tried to use remove API and then close the cache afterwards, there was still some thread(MappedByteBufferSource) lingering on

1) Thread[id=37, name=MappedByteBufferSource Async Flush Thread, state=WAITING, group=TGRP-EhCacheDiskCachingTierNewTests]
        at java...@17.0.7/jdk.internal.misc.Unsafe.park(Native Method)

My code setup and steps to reproduce:

// Create cache manager

PersistenceCacheManager cacheManager =            CacheManagerBuilder.newCacheManagerBuilder()
.with(CacheManagerBuilder.persistence(new File(storagePath)))
.using(PooledExecutionServiceConfigurationBuilder.newPooledExecutionServiceConfigurationBuilder()
.defaultPool("default", 1, 3) 
.pool("custom", 1, 3)
.build(true);

// Create cache

Cache<String, String>
cache = cacheManager.createCache("alias"); 

//Put value
cache.put("random", "random");

//Remove
cache.remove("random", "random");

// close cache
cacheManager.removeCache("alias");
cacheManager.close();

After this, I always see above thread leaks happening. Can someone look into this and verify?

[sgup432]

Seems like during cache.remove(), eventually MappedPageSource.free() is called, where we submit a task asynchronously with above thread name, and these threads are not getting cleaned up even after cacheManager is closed.

[sgup432]

@chrisdennis

[sgup432]

@chrisdennis Do you know if this would be picked up? I am not sure if I can pick it up. I am guessing this background thread is cleaning up some offheap memory associated with disk cache. Is there a workaround this for now? Would be helpful.

[sgup432]

@chrisdennis Any update on this?