[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.