| why during my unload crossreferencer resolve my already unloaded resources .... ? [message #645418] |
Fri, 17 December 2010 08:07  |
 Tristan Faure
Messages: 460
Registered: July 2009 |
Senior Member |
|
|
Hi UML2 and EMF.
I have a resourceset with UML2 resources and own resources linked to my
UML resources.
I do the "typical" unload at the end of my process to empty my resource
set and empty the UML2 CacheAdapter (in fact the InverseCrossReferencer
of the cache adapter).
for (Iterator<Resource> i = set.getResources().iterator() ; i.hasNext() ; )
{
Resource r = i.next() ;
r.unload();
i.remove();
}
The problem is when I unload a resource I can notice this stack trace
org.topcased.modeler.diagrams.model.util.DiagramsResourceImp l(org.eclipse.emf.ecore.resource.impl.ResourceImpl).load(jav a.io.InputStream,
java.util.Map<?,?>) line: 1514
org.topcased.modeler.diagrams.model.util.DiagramsResourceImp l(org.eclipse.emf.ecore.resource.impl.ResourceImpl).load(jav a.util.Map <?,?>)
line: 1282
org.topcased.modeler.editor.TopcasedAdapterFactoryEditingDom ain$TopcasedAdapterFactoryEditingDomainResourceSet(org.eclip se.emf.ecore.resource.impl.ResourceSetImpl).demandLoad(org.e clipse.emf.ecore.resource.Resource)
line: 255
org.topcased.modeler.editor.TopcasedAdapterFactoryEditingDom ain$TopcasedAdapterFactoryEditingDomainResourceSet(org.eclip se.emf.ecore.resource.impl.ResourceSetImpl).demandLoadHelper (org.eclipse.emf.ecore.resource.Resource)
line: 270
org.topcased.modeler.editor.TopcasedAdapterFactoryEditingDom ain$TopcasedAdapterFactoryEditingDomainResourceSet(org.eclip se.emf.ecore.resource.impl.ResourceSetImpl).getResource(org. eclipse.emf.common.util.URI,
boolean) line: 397
org.topcased.modeler.editor.TopcasedAdapterFactoryEditingDom ain$TopcasedAdapterFactoryEditingDomainResourceSet.getResour ce(org.eclipse.emf.common.util.URI,
boolean) line: 482
org.topcased.modeler.editor.TopcasedAdapterFactoryEditingDom ain$TopcasedAdapterFactoryEditingDomainResourceSet(org.eclip se.emf.ecore.resource.impl.ResourceSetImpl).getEObject(org.e clipse.emf.common.util.URI,
boolean) line: 216
org.eclipse.emf.ecore.util.EcoreUtil.resolve(org.eclipse.emf .ecore.EObject,
org.eclipse.emf.ecore.resource.ResourceSet) line: 202
org.eclipse.emf.ecore.util.EcoreUtil.resolve(org.eclipse.emf .ecore.EObject,
org.eclipse.emf.ecore.EObject) line: 262
org.topcased.modeler.diagrams.model.internal.impl.DiagramsIm pl(org.eclipse.emf.ecore.impl.BasicEObjectImpl).eResolveProx y(org.eclipse.emf.ecore.InternalEObject)
line: 1483
org.eclipse.emf.ecore.util.EObjectContainmentWithInverseELis t$Resolving <E>(org.eclipse.emf.ecore.util.EcoreEList<E>).resolveProxy(org.eclipse.emf.ecore.EObject)
line: 212
org.eclipse.emf.ecore.util.EObjectContainmentWithInverseELis t$Resolving <E>(org.eclipse.emf.ecore.util.EcoreEList<E>).resolve(int,
org.eclipse.emf.ecore.EObject) line: 167
org.eclipse.emf.ecore.util.EObjectContainmentWithInverseELis t$Resolving <E>.resolve(int,
E) line: 111
org.eclipse.emf.ecore.util.EObjectContainmentWithInverseELis t$Resolving <E>(org.eclipse.emf.common.util.BasicEList<E>).get(int)
line: 354
org.eclipse.emf.ecore.util.EContentsEList$ResolvingFeatureIt eratorImpl <E> (org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorIm pl <E>).hasNext()
line: 484
org.eclipse.emf.ecore.util.EContentsEList$ResolvingFeatureIt eratorImpl <E> (org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorIm pl <E>).next()
line: 565
org.topcased.modeler.diagrams.model.util.CrossReferenceAdapt er(org.eclipse.emf.ecore.util.ECrossReferenceAdapter).unsetT arget(org.eclipse.emf.ecore.EObject)
line: 780
org.topcased.modeler.diagrams.model.util.CrossReferenceAdapt er(org.eclipse.emf.ecore.util.ECrossReferenceAdapter).unsetT arget(org.eclipse.emf.common.notify.Notifier)
line: 747
org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList <E>.didRemove(int,
E) line: 156
org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList <E>(org.eclipse.emf.common.util.BasicEList<E>).remove(int)
line: 622
org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList <E>.remove(int)
line: 227
org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList <E>(org.eclipse.emf.common.util.AbstractEList<E>).remove(java.lang.Object)
line: 466
org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList <E>.remove(java.lang.Object)
line: 220
org.topcased.modeler.diagrams.model.util.CrossReferenceAdapt er(org.eclipse.emf.ecore.util.ECrossReferenceAdapter).remove Adapter(org.eclipse.emf.common.notify.Notifier)
line: 828
org.topcased.modeler.diagrams.model.util.CrossReferenceAdapt er(org.eclipse.emf.ecore.util.ECrossReferenceAdapter).unsetT arget(org.eclipse.emf.ecore.EObject)
line: 784
org.topcased.modeler.diagrams.model.util.CrossReferenceAdapt er(org.eclipse.emf.ecore.util.ECrossReferenceAdapter).unsetT arget(org.eclipse.emf.common.notify.Notifier)
line: 747
org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList <E>.didRemove(int,
E) line: 156
org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList <E>(org.eclipse.emf.common.util.AbstractEList<E>).didClear(int,
java.lang.Object[]) line: 172
org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList <E>(org.eclipse.emf.common.util.BasicEList<E>).clear()
line: 646
org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList <E>.clear()
line: 241
org.topcased.modeler.diagrams.model.util.DiagramsResourceImp l(org.eclipse.emf.ecore.resource.impl.ResourceImpl).unloaded (org.eclipse.emf.ecore.InternalEObject)
line: 1565
org.topcased.modeler.diagrams.model.util.DiagramsResourceImp l(org.eclipse.emf.ecore.resource.impl.ResourceImpl).doUnload ()
line: 1624
org.topcased.modeler.diagrams.model.util.DiagramsResourceImp l(org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl).doUnload()
line: 506
org.topcased.modeler.diagrams.model.util.DiagramsResourceImp l(org.eclipse.emf.ecore.resource.impl.ResourceImpl).unload()
line: 1639
The problem comes from an adapter list of the resource which is cleared
and this list triggers adapter mechanisms which will resolve elements
which will load a resource unloaded which will fill again the
CacheAdapter and creates a memory leak in my application.
How can I avoid this kind of solutions? My goal is having only proxies
after my unload process and with this behavior, it never happens.
|
|
|
|
| Re: why during my unload, the crossreferencer resolves my already unloaded resources .... ? [message #646040 is a reply to message #645937] |
Tue, 21 December 2010 16:58  |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020706080704070901070604
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Tristan,
ECrossReferenceAdapter has this method
protected boolean resolve()
{
return true;
}
so it's possible to override it so it doesn't resolve proxies. I can't
comment on exactly why a client using it
(org.topcased.modeler.diagrams.model.util.CrossReferenceAdap ter) chooses
to resolve proxies or not. Generally one would want to resolve proxies
to really know which objects are referencing each other, but I can't
imagine you'd need to know that when you're unloading everything.
Tristan FAURE wrote:
> Hi again maybe I shall reformulate my question, I forgot punctuation :(
>
> why during my unload, the crossreferencer resolves my already unloaded
> resources .... ?
>
> It is a very problematic solution if somebody can help me to figure
> out why it is happening
--------------020706080704070901070604
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tristan,<br>
<br>
ECrossReferenceAdapter has this method<br>
<blockquote><small> protected boolean resolve()<br>
{<br>
return true;<br>
}</small><br>
</blockquote>
so it's possible to override it so it doesn't resolve proxies. I can't
comment on exactly why a client using it
(org.topcased.modeler.diagrams.model.util.CrossReferenceAdap ter)
chooses to resolve proxies or not. Generally one would want to resolve
proxies to really know which objects are referencing each other, but I
can't imagine you'd need to know that when you're unloading everything.<br>
<br>
<br>
Tristan FAURE wrote:
<blockquote cite="mid:ieprvk$lfn$1@news.eclipse.org" type="cite">Hi
again maybe I shall reformulate my question, I forgot punctuation :(
<br>
<br>
why during my unload, the crossreferencer resolves my already unloaded
resources .... ?
<br>
<br>
It is a very problematic solution if somebody can help me to figure out
why it is happening
<br>
</blockquote>
</body>
</html>
--------------020706080704070901070604--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.04184 seconds
] 
Search
Help
Register
Login
Home
