[jira] [Assigned] (CAY-2642) EhCache memory leak due to misconfiguration

["Nikita Timofeev (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAY-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nikita Timofeev reassigned CAY-2642:
------------------------------------

    Assignee: Nikita Timofeev

> EhCache memory leak due to misconfiguration
> -------------------------------------------
>
>                 Key: CAY-2642
>                 URL: https://issues.apache.org/jira/browse/CAY-2642
>             Project: Cayenne
>          Issue Type: Task
>    Affects Versions: 4.1.RC2
>            Reporter: Andrus Adamchik
>            Assignee: Nikita Timofeev
>            Priority: Major
>             Fix For: 4.1.RC3, 4.2.M1
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> h2. Background
> Just ran across a scenario when a user can inadvertently introduce a memory leak in their app. This happens when an app is using query caching with JCacheQueryCache and EhCache provider in the backend, and the cache key space is large / growing. The last criterion is met when local cache is in use and new DataContexts are created for new jobs/requests (each DataContext introduces its own key subspace). In this case cache entries (including their DataContexts) are retained in memory indefinitely, eventually causing the app to crash with OutOfMemory
> h2. Cause
> If there is a query with a cache group that does not have a cache configured explicitly in the backend (in "ehcache.xml"), JCacheQueryCache creates a new cache on the fly using JCacheDefaultConfigurationFactory. While JCacheDefaultConfigurationFactory has a default expiration of 10 minutes, it doesn't have an upper limit on the number of entries (there's no API in JCache to set it), so such cache becomes essentially boundless.
> Since cache groups are assigned by query, and their number can increase as the app evolves, it is very easy to overlook the need for a matching <cache> configuration entry. So previously stable apps can suddenly acquire such time bombs as they evolve over time. 
> h2. Solution
> I wish we were able to create caches with fixed size bounds, but I don't see how to do it in JCache. So a minimal possible solution would be to print a big warning in the logs whenever we need to call "JCacheQueryCache.createCache". 
> In the future versions we might replace the warning with an exception (??) (Or make this behavior - warn vs exception - configurable via a property).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)