[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] The ScrollableCursor's issues
|
I investigated reasons for leaks and I can say that about 50% of the heap is
free during the total size of the memory which is allocated for JVM is being
increased by 1Gb so the heap is not a reason for the
java.lang.OutOfMemoryError.
Regards,
Dmitry
dmitryerkin wrote:
>
> Hi, James Sutherland
> Thank you again!
>
> I implemented the finalize method for the class whose instances are
> retrieved by the cursor and I can see the result of the finalizing in the
> system log so I am sure that instances are collected.
>
> @Override
> protected void finalize() throws Throwable {
> // TODO Auto-generated method stub
> super.finalize();
> System.out.println("OebsView.finalize()");
> System.out.println("id=" + this.getId());
> }
>
> And I use this code to tell the JVM to collect the garbage:
>
> Runtime rt = Runtime.getRuntime();
> rt.gc();
>
> But I have the java.lang.OutOfMemoryError in the end.
>
>
>
> Regards,
> Dmitry
>
>
>
>
> James Sutherland wrote:
>>
>> In Java the VM will garbage collect whenever it feels it needs to. There
>> is an API on java.lang.System.gc(), but this is only a suggestion, the VM
>> may still not perform a gc.
>>
>> Ensure that nothing in your application is holding onto the objects. If
>> anything references an object, it cannot gc. There are memory profilers
>> such as JProfiler that can pinpoint memory leaks. The easiest way to
>> find out if an object has gc'd is to create a WeakReference to it, and
>> check if the reference is null.
>>
>> In general I would not recommend using NoIdentityMap, weak should be
>> fine.
>>
>> Are you running out of memory? Did you try increasing your JVM's memory?
>>
>>
>> dmitryerkin wrote:
>>>
>>> Hi, James Sutherland
>>> Thanks for your help and patience
>>>
>>> The level of the cache which is configured for the descriptor of the
>>> OebsView.class is None:
>>>
>>> // ClassDescriptor Properties.
>>> descriptor.useNoIdentityMap();
>>> descriptor.setIdentityMapSize(0);
>>> descriptor.useRemoteNoIdentityMap();
>>> descriptor.setRemoteIdentityMapSize(0);
>>> descriptor.setIsIsolated(true);
>>> descriptor.setAlias("OebsView");
>>>
>>> descriptor.setCacheSynchronizationType(ClassDescriptor.DO_NOT_SEND_CHANGES);
>>>
>>> I added the dontMaintainCache() but it did not change anything in the
>>> allocation of the jvm's memory:
>>>
>>> ReadAllQuery queryByTime = new ReadAllQuery(OebsView.class, where);
>>> queryByTime.useScrollableCursor();
>>> queryByTime.setIsReadOnly(true);
>>> queryByTime.dontMaintainCache();
>>>
>>> ut.setTransactionTimeout(60*60*24);
>>> ut.begin();
>>>
>>> jpaEM = org.eclipse.persistence.jpa.JpaHelper.getEntityManager(em);
>>> uow = jpaEM.getActiveSession().getActiveUnitOfWork();
>>> if(uow == null){
>>> System.out.println("uow is null");
>>> uow = jpaEM.getActiveSession().acquireUnitOfWork();
>>> }
>>> cursorByTimeAndOrganizationId = (ScrollableCursor)
>>> uow.executeQuery(queryByTime);
>>>
>>>
>>> The memory is still allocated after the transaction is committed.
>>> Is this a jvm's feature? Can I use a jvm's interface to release memory?
>>>
>>>
>>> Regards,
>>> Dmitry
>>>
>>>
>>>
>>> James Sutherland wrote:
>>>>
>>>> The objects will no longer be held by the UnitOfWork/EntityManager, but
>>>> will still be in the cache. Depending on what caching you are using,
>>>> they will eventually garbage collect (weak references). SoftWeak is
>>>> the default cache type, which will hold 100 objects using soft
>>>> reference and the rest using weak references, weak will garbage collect
>>>> in the next gc, and soft will garbage collect when memory is low. You
>>>> can change your cache type to weak to allow better garbage collection.
>>>> You could potentially also set dontMaintainCache() on the query to
>>>> avoid the cache entirely.
>>>>
>>>> If you set read-only on the query, you don't need to execute it with
>>>> the Session, using the EntityManager is fine.
>>>>
>>>>
>>>>
>>>> dmitryerkin wrote:
>>>>>
>>>>> Hi, James Sutherland!
>>>>> Thanks a lot for your help.
>>>>>
>>>>> One your tip helped me but another did not help.
>>>>> I found settings for the transaction service and changed the value of
>>>>> timeout. It works.
>>>>> But a memory for the previous block is not released after the next
>>>>> block is getted although I changed my code:
>>>>>
>>>>> ReadAllQuery queryByTime = new ReadAllQuery(OebsView.class, where);
>>>>> queryByTime.useScrollableCursor();
>>>>> queryByTime.setIsReadOnly(true);
>>>>>
>>>>> ut.setTransactionTimeout(60*60*24);
>>>>> ut.begin();
>>>>>
>>>>> jpaEM = org.eclipse.persistence.jpa.JpaHelper.getEntityManager(em);
>>>>> uow = jpaEM.getActiveSession().getActiveUnitOfWork();
>>>>> if(uow == null){
>>>>> System.out.println("uow is null");
>>>>> uow = jpaEM.getActiveSession().acquireUnitOfWork();
>>>>> }
>>>>> cursorByTimeAndOrganizationId = (ScrollableCursor)
>>>>> uow.getParent().executeQuery(queryByTime);
>>>>>
>>>>>
>>>>> I could not try the third way which You advised because I could not
>>>>> find the class where the clear() method is declared.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Dmitry
>>>>>
>>>>>
>>>>>
>>>>> James Sutherland wrote:
>>>>>>
>>>>>> You are executing the query in the UnitOfWork so all of the returned
>>>>>> objects will be managed (and not allowed to garbage collect). If you
>>>>>> execute it in the Session (uow.getParent()), then the objects will
>>>>>> not be managed and free to gc, (but must be used as read-only). You
>>>>>> could also call clear() in between each page, or set the query to be
>>>>>> read-only (setIsReadOnly(true) same as exec in session).
>>>>>>
>>>>>> The rollback seems like it is cause because you have a transaction
>>>>>> timeout set somewhere in WAS or your DB. You will need to find and
>>>>>> increase this timeout.
>>>>>>
>>>>>> You could also potentially use JPA firstResult/maxResult to page the
>>>>>> results.
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/The-ScrollableCursor%27s-issues-tp19392081p19553522.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.
