[infinispan-issues] [JBoss JIRA] (ISPN-1796) Out-of-memory adding a lot of elements in cache with AsyncStore
Dan Berindei (Jira)
issues at jboss.org
Mon Dec 17 03:56:00 EST 2018
[ https://issues.jboss.org/browse/ISPN-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dan Berindei resolved ISPN-1796.
--------------------------------
Fix Version/s: 9.2.0.Final
Resolution: Done
Fixed with ISPN-2293
> Out-of-memory adding a lot of elements in cache with AsyncStore
> ---------------------------------------------------------------
>
> Key: ISPN-1796
> URL: https://issues.jboss.org/browse/ISPN-1796
> Project: Infinispan
> Issue Type: Task
> Components: Loaders and Stores, Transactions
> Affects Versions: 5.1.0.CR3
> Environment: We plan to use Infinispan as a large distributed write-behind cache of terabytes of data, with a little fraction cached in RAM, so OOM is real threat for us.
> Reporter: Andrew Pushkin
> Priority: Major
> Labels: executor, threads
> Fix For: 9.2.0.Final
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> OOM occure on peaks of putting objects in cache configured to use AsyncStore.
> See Steps to Reproduce.
>
> Profiling shows that the gc path is through AsyncStore.state field.
> The AsyncStore.executor initialized to ThreadPoolExecutor with DiscardPolicy to silently discard tasks if the queue is full, which delays async processing of entries in *state* map, which continues to grow.
> Suggested solution.
> Instead of DiscardPolicy use customized behavior, which is to estimate accumulated state size and (probably comparing it with modificationQueueSize) decide to discard or to block until it is processed.
> The downside of suggested solution is the necessity to lock to estimate state size every time the task is rejected. Possibly it can be alleviated by increasing workingQueue size, so that it survive peaks without rejection.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
More information about the infinispan-issues
mailing list