[infinispan-issues] [JBoss JIRA] (ISPN-2786) ThreadLocal memory leak in Tomcat

[Johann Burkard (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776899#comment-12776899 ] 

Johann Burkard commented on ISPN-2786:
--------------------------------------

Hi Galder,

I don't know what project I found this leak with but here is a configuration I had in January:

{code}
        EvictionStrategy strategy = EvictionStrategy.valueOf(configuration.eviction_strategy ?: 'FIFO')
       
        FileCacheStoreConfig storeConfig = new FileCacheStoreConfig()
        storeConfig.fsyncMode(FsyncMode.PER_WRITE).location(configuration.db ?: System.getProperty('java.io.tmpdir'))
        
        DefaultCacheManager cacheManager = new DefaultCacheManager()
        
        cacheManager.defaultConfiguration.fluent().with {
            // Passivation needs to be false, otherwise cache entries will only be written if evicted!
            loaders().addCacheLoader(storeConfig).passivation(false).shared(true).preload(true)
            eviction().maxEntries(configuration.max_entries?.integer ? configuration.max_entries as int : 4096I).strategy(strategy)
            locking().concurrencyLevel(configuration.threads?.integer ? configuration.threads as int : Runtime.runtime.availableProcessors())
            jmxStatistics().enabled(true)
        }
        
        cacheManager
{code}

The current setup looks like this:

{code}
        EvictionStrategy strategy = EvictionStrategy.valueOf(configuration.eviction_strategy ?: 'LRU')
        
        ConfigurationBuilder configurationBuilder = new ConfigurationBuilder()
        configurationBuilder.with {
            eviction().maxEntries(configuration.max_entries?.integer ? configuration.max_entries as int : 4096I).strategy(strategy)
            expiration().enableReaper().wakeUpInterval(configuration.reaper_wake_up_interval?.long ? configuration.reaper_wake_up_interval as long : 60000L)
            jmxStatistics().enable()
            // Passivation needs to be false, otherwise cache entries will only be written if evicted!
            loaders().passivation(false).shared(true).preload(true).addFileCacheStore().fsyncMode(FsyncMode.PER_WRITE).location(configuration.db ?: System.getProperty('java.io.tmpdir'))
            locking().useLockStriping(true).concurrencyLevel(configuration.threads?.integer ? configuration.threads as int : Runtime.runtime.availableProcessors())
            storeAsBinary().enable()
        }
        
       new DefaultCacheManager(new GlobalConfigurationBuilder().nonClusteredDefault().build(), configurationBuilder.build())
{code}

I don't do anything fancy with the caches. Single puts with life spans, gets and a bit of locking using {{NonTxInvocationContext}}.
                
> ThreadLocal memory leak in Tomcat
> ---------------------------------
>
>                 Key: ISPN-2786
>                 URL: https://issues.jboss.org/browse/ISPN-2786
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Marshalling, Transactions
>    Affects Versions: 5.1.8.Final
>            Reporter: Johann Burkard
>            Assignee: Galder Zamarreño
>              Labels: leak, local, memory, thread, threadlocal
>             Fix For: 5.3.0.Final
>
>
> Just started an app using Infinispan 5.1.8.Final on Tomcat and got a few ThreadLocal problems during un-deployment:
> (Shortened)
> {code}
> key=org.jboss.marshalling.UTFUtils.BytesHolder
> value=org.jboss.marshalling.UTFUtils$BytesHolder at 697a1686
> key=java.lang.ThreadLocal at 36ed5ba6
> value=org.infinispan.context.SingleKeyNonTxInvocationContext{flags=null}
> key=org.infinispan.marshall.jboss.AbstractJBossMarshaller$1
> value=org.infinispan.marshall.jboss.AbstractJBossMarshaller$1 at 75f10df7
> value=org.infinispan.marshall.jboss.AbstractJBossMarshaller.PerThreadInstanceHolder
> {code}
> I do call {{DefaultCacheManager#shutdown()}} during un-deployment. :)
> Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira