[
https://issues.jboss.org/browse/ISPN-1329?page=com.atlassian.jira.plugin....
]
Robert Stupp commented on ISPN-1329:
------------------------------------
Yes, of course. But it should not be a source of OutOfMemory exceptions. There is no
benefit, when the "physical" limit is reached with an out-of-memory - noone can
foresee how applications behave in such a situation.
The async store is very good to decouple the "frontend" from the backing cache
store - to let the "frontend" work smoothly even during phases of high load.
org.infinispan.loaders.decorators.AsyncStore leads to
OutOfMemoryExceptions
---------------------------------------------------------------------------
Key: ISPN-1329
URL:
https://issues.jboss.org/browse/ISPN-1329
Project: Infinispan
Issue Type: Bug
Components: Configuration, Loaders and Stores
Affects Versions: 5.0.0.CR8
Reporter: Robert Stupp
Assignee: Manik Surtani
When I configure
{code}
<async
enabled="true"
threadPoolSize="3"/>
{code}
the implementation creates three threads names "CoalescedAsyncStore" per cache
store.
When adding a large amount of data to the cache (for example indexing a lot of Lucene
documents), the application will stop working with a lot of OutOfMemory exceptions.
This is caused by the implementation of org.infinispan.loaders.decorators.AsyncStore that
uses an unbounded LinkedBlockingQueue.
A lot of worker threads push a huge amount of modifications into the queues, but the
underlying cache store is not able to handle throughput.
As a quick solution change
{code}
private final LinkedBlockingQueue<Modification> changesDeque = new
LinkedBlockingQueue<Modification>();
{code}
to
{code}
private final LinkedBlockingQueue<Modification> changesDeque = new
LinkedBlockingQueue<Modification>(512);
{code}
and add a new configuration option to the async element, that specifies the capacity of
the Linked Blocking Queue.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira