[
https://issues.jboss.org/browse/ISPN-2789?page=com.atlassian.jira.plugin....
]
Anna Manukyan commented on ISPN-2789:
-------------------------------------
[~sannegrinovero] The thing was that the loadAll() method was calling
load(Integer.MAX_VALUE) method passing Integer Max value. The load method was
instantiating HashSet for storing the loaded values in it, and the thing was that the
HashSet was instantiating by passing the initialCapacity equals to the passed
Integer.MAX_VALUE.
The OutOfMemory issue was appearing while instantiating HashSet with the passed
initialCapacity value.
So I thought that there is no point in passing these value as an initial capacity to the
HashSet, especially if the app works with low number of entities and uses loadAll()
method, then a huge amount of memory is allocated but during app lifetime it is not used.
If this fix is not acceptable, then we need to think of another solution, even though the
VM parameters extension to high numbers didn't help.
OutOfMemoryError in case if LuceneCacheLoader.loadAll() is called
-----------------------------------------------------------------
Key: ISPN-2789
URL:
https://issues.jboss.org/browse/ISPN-2789
Project: Infinispan
Issue Type: Bug
Components: Lucene Directory
Affects Versions: 5.2.0.Final
Reporter: Anna Manukyan
Assignee: Anna Manukyan
Fix For: 5.3.0.Alpha1, 5.3.0.Final
In case when calling LuceneCacheLoader.loadAll() method, the following exception
appears:
{code}
java.lang.OutOfMemoryError: Java heap space
at java.util.HashMap.<init>(HashMap.java:204)
at java.util.HashMap.<init>(HashMap.java:216)
at java.util.HashSet.<init>(HashSet.java:142)
at
org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadAllEntries(DirectoryLoaderAdaptor.java:87)
at org.infinispan.lucene.cachestore.LuceneCacheLoader.load(LuceneCacheLoader.java:116)
at
org.infinispan.lucene.cachestore.LuceneCacheLoader.loadAll(LuceneCacheLoader.java:105)
at
org.infinispan.lucene.cacheloader.LuceneCacheLoaderTest.testLoadEntries(LuceneCacheLoaderTest.java:146)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{code}
I tried to edit VM options for make it to work, but even in case of high numbers for
memory usage, this still happens.
--
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