Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [Papyrus, CDO] Deadlock situation when same model is loaded in different CDOViews
[Papyrus, CDO] Deadlock situation when same model is loaded in different CDOViews [message #1733832] Wed, 01 June 2016 10:37 Go to next message
Thorsten Schlathölter is currently offline Thorsten SchlathölterFriend
Messages: 312
Registered: February 2012
Location: Düsseldorf
Senior Member
Hi,
I found a deadlock situation in Papyrus in conjunction with CDO. If I have the same model loaded in different CDOTransactions I get a deadlock very reliably when I modify the model. This is due to the CacheAdapter performing "handleCrossReference" which is synced on the "inverseCrossReferencer" and the CDOLegacyAdapter performing "revisionToInstance" which is synced on "recursionCounter".

This are the stacks starting from the point where the threads aquire theirs blocking lock:

	Daemon System Thread [Attach Listener] (Suspended)	
	Daemon System Thread [Signal Dispatcher] (Suspended)	
	Daemon System Thread [Finalizer] (Suspended)	
	Daemon System Thread [Reference Handler] (Suspended)	
	Thread [main] (Suspended)	
		owns: CDOTransactionImpl  (id=79)	
		owns: CacheAdapter$InverseCrossReferencer  (id=80)	
		waiting for: InheritableThreadLocal<T>  (id=78)	
			owned by: Thread [Worker-1] (Suspended)	
				waiting for: CacheAdapter$InverseCrossReferencer  (id=80)	
					owned by: Thread [main] (Suspended)	
						waiting for: InheritableThreadLocal<T>  (id=78)	
		CDOLegacyAdapter(CDOLegacyWrapper).revisionToInstance() line: 444	
		CDOLegacyAdapter(CDOLegacyWrapper).cdoInternalPostLoad() line: 369	
		CDOTransactionImpl(AbstractCDOView).cleanObject(InternalCDOObject, InternalCDORevision) line: 1950	
		CDOTransactionImpl(AbstractCDOView).createObject(CDOID) line: 1859	
		CDOTransactionImpl(AbstractCDOView).getObject(CDOID, boolean) line: 1661	
		CDOTransactionImpl.getObject(CDOID, boolean) line: 1498	
		CDOTransactionImpl(AbstractCDOView).convertIDToObject(Object) line: 2140	
		CDOStoreImpl.convertIDToObject(InternalCDOView, EObject, EStructuralFeature, int, Object) line: 897	
		CDOStoreImpl.convertToEMF(EObject, InternalCDORevision, EStructuralFeature, int, Object) line: 860	
		CDOStoreImpl.isSet(InternalEObject, EStructuralFeature) line: 248	
		ValueTableImpl(CDOObjectImpl).eDynamicIsSet(int, EStructuralFeature) line: 734	
		ValueTableImpl(BasicEObjectImpl).eIsSet(int) line: 1257	
		ValueTableImpl(BasicEObjectImpl).eIsSet(EStructuralFeature) line: 1241	
		EContentsEList$FeatureIteratorImpl<E>.hasNext() line: 437	
		CacheAdapter(ECrossReferenceAdapter).setTarget(EObject) line: 775	
		CacheAdapter(ECrossReferenceAdapter).setTarget(Notifier) line: 752	
		CacheAdapter.setTarget(Notifier) line: 360	


		Thread [Worker-1] (Suspended)	
	owns: InheritableThreadLocal<T>  (id=78)	
	owns: CDOTransactionImpl  (id=82)	
	owns: SoxRepositoryProject  (id=83)	
	waiting for: CacheAdapter$InverseCrossReferencer  (id=80)	
		owned by: Thread [main] (Suspended)	
			waiting for: InheritableThreadLocal<T>  (id=78)	
				owned by: Thread [Worker-1] (Suspended)	
					waiting for: CacheAdapter$InverseCrossReferencer  (id=80)	
						owned by: Thread [main] (Suspended)	
	CacheAdapter.handleCrossReference(EObject) line: 341	
	AssociationImpl(ElementImpl).eSetDeliver(boolean) line: 988	
	CDOLegacyAdapter(CDOLegacyWrapper).revisionToInstance() line: 520


Both locks are static so I think the situation could also occur when working with different models are processed at the same time.

Any idea how to tackle this?

Regards,
Thorsten
Re: [Papyrus, CDO] Deadlock situation when same model is loaded in different CDOViews [message #1733907 is a reply to message #1733832] Thu, 02 June 2016 06:55 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6690
Registered: July 2009
Senior Member
Hi Thorsten,

I'm unfamiliar with this CacheAdapter. Where does it come from and, more importantly, why are the two
CDOTransactions/ResourceSets use the same instance of this CacheAdapter?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper





Am 01.06.2016 um 12:37 schrieb Thorsten Schlathölter:
> Hi,
> I found a deadlock situation in Papyrus in conjunction with CDO. If I have the same model loaded in different
> CDOTransactions I get a deadlock very reliably when I modify the model. This is due to the CacheAdapter performing
> "handleCrossReference" which is synced on the "inverseCrossReferencer" and the CDOLegacyAdapter performing
> "revisionToInstance" which is synced on "recursionCounter".
>
> This are the stacks starting from the point where the threads aquire theirs blocking lock:
>
>
> Daemon System Thread [Attach Listener] (Suspended)
> Daemon System Thread [Signal Dispatcher] (Suspended)
> Daemon System Thread [Finalizer] (Suspended)
> Daemon System Thread [Reference Handler] (Suspended)
> Thread [main] (Suspended)
> owns: CDOTransactionImpl (id=79)
> owns: CacheAdapter$InverseCrossReferencer (id=80)
> waiting for: InheritableThreadLocal<T> (id=78)
> owned by: Thread [Worker-1] (Suspended)
> waiting for: CacheAdapter$InverseCrossReferencer (id=80)
> owned by: Thread [main] (Suspended)
> waiting for: InheritableThreadLocal<T> (id=78)
> CDOLegacyAdapter(CDOLegacyWrapper).revisionToInstance() line: 444
> CDOLegacyAdapter(CDOLegacyWrapper).cdoInternalPostLoad() line: 369
> CDOTransactionImpl(AbstractCDOView).cleanObject(InternalCDOObject, InternalCDORevision) line: 1950
> CDOTransactionImpl(AbstractCDOView).createObject(CDOID) line: 1859
> CDOTransactionImpl(AbstractCDOView).getObject(CDOID, boolean) line: 1661
> CDOTransactionImpl.getObject(CDOID, boolean) line: 1498
> CDOTransactionImpl(AbstractCDOView).convertIDToObject(Object) line: 2140
> CDOStoreImpl.convertIDToObject(InternalCDOView, EObject, EStructuralFeature, int, Object) line: 897
> CDOStoreImpl.convertToEMF(EObject, InternalCDORevision, EStructuralFeature, int, Object) line: 860
> CDOStoreImpl.isSet(InternalEObject, EStructuralFeature) line: 248
> ValueTableImpl(CDOObjectImpl).eDynamicIsSet(int, EStructuralFeature) line: 734
> ValueTableImpl(BasicEObjectImpl).eIsSet(int) line: 1257
> ValueTableImpl(BasicEObjectImpl).eIsSet(EStructuralFeature) line: 1241
> EContentsEList$FeatureIteratorImpl<E>.hasNext() line: 437
> CacheAdapter(ECrossReferenceAdapter).setTarget(EObject) line: 775
> CacheAdapter(ECrossReferenceAdapter).setTarget(Notifier) line: 752
> CacheAdapter.setTarget(Notifier) line: 360
>
>
>
> Thread [Worker-1] (Suspended)
> owns: InheritableThreadLocal<T> (id=78)
> owns: CDOTransactionImpl (id=82)
> owns: SoxRepositoryProject (id=83)
> waiting for: CacheAdapter$InverseCrossReferencer (id=80)
> owned by: Thread [main] (Suspended)
> waiting for: InheritableThreadLocal<T> (id=78)
> owned by: Thread [Worker-1] (Suspended)
> waiting for: CacheAdapter$InverseCrossReferencer (id=80)
> owned by: Thread [main] (Suspended)
> CacheAdapter.handleCrossReference(EObject) line: 341
> AssociationImpl(ElementImpl).eSetDeliver(boolean) line: 988
> CDOLegacyAdapter(CDOLegacyWrapper).revisionToInstance() line: 520
>
>
> Both locks are static so I think the situation could also occur when working with different models are processed at
> the same time.
>
> Any idea how to tackle this?
>
> Regards,
> Thorsten


Re: [Papyrus, CDO] Deadlock situation when same model is loaded in different CDOViews [message #1733946 is a reply to message #1733907] Thu, 02 June 2016 11:35 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Hi, Eike,

The CacheAdapter is a component of the UML2 API. It is a static
singleton and elements of UML models automatically ensure that it is
attached to themselves and all contents reachable from them, which is
why all resource sets that have UML content have this adapter.

The CacheAdapter is crucial for acceptable performance of derived
feature and operation computations in the UML API and in the very
earliest days of the UML2 project it was determined that attempting to
have a distinct CacheAdapter per ResourceSet killed performance.

That said, applications can replace the CacheAdapter with a custom
implementation of their own that perhaps addresses either locking
issues or isn't quite a singleton.

HTH,

Christian


On 2016-06-02 06:55:25 +0000, Eike Stepper said:

> Hi Thorsten,
>
> I'm unfamiliar with this CacheAdapter. Where does it come from and,
> more importantly, why are the two CDOTransactions/ResourceSets use the
> same instance of this CacheAdapter?
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
>
>
> Am 01.06.2016 um 12:37 schrieb Thorsten Schlathölter:
>> Hi,
>> I found a deadlock situation in Papyrus in conjunction with CDO. If I
>> have the same model loaded in different CDOTransactions I get a
>> deadlock very reliably when I modify the model. This is due to the
>> CacheAdapter performing "handleCrossReference" which is synced on the
>> "inverseCrossReferencer" and the CDOLegacyAdapter performing
>> "revisionToInstance" which is synced on "recursionCounter".
>>
>> This are the stacks starting from the point where the threads aquire
>> theirs blocking lock:
>>
>>
>> Daemon System Thread [Attach Listener] (Suspended)
>> Daemon System Thread [Signal Dispatcher] (Suspended)
>> Daemon System Thread [Finalizer] (Suspended)
>> Daemon System Thread [Reference Handler] (Suspended)
>> Thread [main] (Suspended)
>> owns: CDOTransactionImpl (id=79)
>> owns: CacheAdapter$InverseCrossReferencer (id=80)
>> waiting for: InheritableThreadLocal<T> (id=78)
>> owned by: Thread [Worker-1] (Suspended)
>> waiting for: CacheAdapter$InverseCrossReferencer (id=80)
>> owned by: Thread [main] (Suspended)
>> waiting for: InheritableThreadLocal<T> (id=78)
>> CDOLegacyAdapter(CDOLegacyWrapper).revisionToInstance() line: 444
>> CDOLegacyAdapter(CDOLegacyWrapper).cdoInternalPostLoad() line: 369
>> CDOTransactionImpl(AbstractCDOView).cleanObject(InternalCDOObject,
>> InternalCDORevision) line: 1950
>> CDOTransactionImpl(AbstractCDOView).createObject(CDOID) line: 1859
>> CDOTransactionImpl(AbstractCDOView).getObject(CDOID, boolean) line: 1661
>> CDOTransactionImpl.getObject(CDOID, boolean) line: 1498
>> CDOTransactionImpl(AbstractCDOView).convertIDToObject(Object) line: 2140
>> CDOStoreImpl.convertIDToObject(InternalCDOView, EObject,
>> EStructuralFeature, int, Object) line: 897
>> CDOStoreImpl.convertToEMF(EObject, InternalCDORevision,
>> EStructuralFeature, int, Object) line: 860
>> CDOStoreImpl.isSet(InternalEObject, EStructuralFeature) line: 248
>> ValueTableImpl(CDOObjectImpl).eDynamicIsSet(int, EStructuralFeature) line: 734
>> ValueTableImpl(BasicEObjectImpl).eIsSet(int) line: 1257
>> ValueTableImpl(BasicEObjectImpl).eIsSet(EStructuralFeature) line: 1241
>> EContentsEList$FeatureIteratorImpl<E>.hasNext() line: 437
>> CacheAdapter(ECrossReferenceAdapter).setTarget(EObject) line: 775
>> CacheAdapter(ECrossReferenceAdapter).setTarget(Notifier) line: 752
>> CacheAdapter.setTarget(Notifier) line: 360
>>
>>
>>
>> Thread [Worker-1] (Suspended)
>> owns: InheritableThreadLocal<T> (id=78)
>> owns: CDOTransactionImpl (id=82)
>> owns: SoxRepositoryProject (id=83)
>> waiting for: CacheAdapter$InverseCrossReferencer (id=80)
>> owned by: Thread [main] (Suspended)
>> waiting for: InheritableThreadLocal<T> (id=78)
>> owned by: Thread [Worker-1] (Suspended)
>> waiting for: CacheAdapter$InverseCrossReferencer (id=80)
>> owned by: Thread [main] (Suspended)
>> CacheAdapter.handleCrossReference(EObject) line: 341
>> AssociationImpl(ElementImpl).eSetDeliver(boolean) line: 988
>> CDOLegacyAdapter(CDOLegacyWrapper).revisionToInstance() line: 520
>>
>>
>> Both locks are static so I think the situation could also occur when
>> working with different models are processed at the same time.
>>
>> Any idea how to tackle this?
>>
>> Regards,
>> Thorsten
Re: [Papyrus, CDO] Deadlock situation when same model is loaded in different CDOViews [message #1733950 is a reply to message #1733946] Thu, 02 June 2016 11:54 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6690
Registered: July 2009
Senior Member
Hi Christian,

Thanks for the valuable infos. The problem that has been reported here is definitely because of nested snychronization
on two different, global singletons (CacheAdapter$InverseCrossReferencer and InheritableThreadLocal<T>).

Thorsten, I'm willing to play with a narrower replacement of CDO's singleton lock (e.g., the current CDOView). Please
submit a bugzilla.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Am 02.06.2016 um 13:35 schrieb Christian W. Damus:
> Hi, Eike,
>
> The CacheAdapter is a component of the UML2 API. It is a static singleton and elements of UML models automatically
> ensure that it is attached to themselves and all contents reachable from them, which is why all resource sets that
> have UML content have this adapter.
>
> The CacheAdapter is crucial for acceptable performance of derived feature and operation computations in the UML API
> and in the very earliest days of the UML2 project it was determined that attempting to have a distinct CacheAdapter
> per ResourceSet killed performance.
>
> That said, applications can replace the CacheAdapter with a custom implementation of their own that perhaps addresses
> either locking issues or isn't quite a singleton.
>
> HTH,
>
> Christian
>
>
> On 2016-06-02 06:55:25 +0000, Eike Stepper said:
>
>> Hi Thorsten,
>>
>> I'm unfamiliar with this CacheAdapter. Where does it come from and, more importantly, why are the two
>> CDOTransactions/ResourceSets use the same instance of this CacheAdapter?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>>
>>
>> Am 01.06.2016 um 12:37 schrieb Thorsten Schlathölter:
>>> Hi,
>>> I found a deadlock situation in Papyrus in conjunction with CDO. If I have the same model loaded in different
>>> CDOTransactions I get a deadlock very reliably when I modify the model. This is due to the CacheAdapter performing
>>> "handleCrossReference" which is synced on the "inverseCrossReferencer" and the CDOLegacyAdapter performing
>>> "revisionToInstance" which is synced on "recursionCounter".
>>>
>>> This are the stacks starting from the point where the threads aquire theirs blocking lock:
>>>
>>>
>>> Daemon System Thread [Attach Listener] (Suspended)
>>> Daemon System Thread [Signal Dispatcher] (Suspended)
>>> Daemon System Thread [Finalizer] (Suspended)
>>> Daemon System Thread [Reference Handler] (Suspended)
>>> Thread [main] (Suspended)
>>> owns: CDOTransactionImpl (id=79)
>>> owns: CacheAdapter$InverseCrossReferencer (id=80)
>>> waiting for: InheritableThreadLocal<T> (id=78)
>>> owned by: Thread [Worker-1] (Suspended)
>>> waiting for: CacheAdapter$InverseCrossReferencer (id=80)
>>> owned by: Thread [main] (Suspended)
>>> waiting for: InheritableThreadLocal<T> (id=78)
>>> CDOLegacyAdapter(CDOLegacyWrapper).revisionToInstance() line: 444
>>> CDOLegacyAdapter(CDOLegacyWrapper).cdoInternalPostLoad() line: 369
>>> CDOTransactionImpl(AbstractCDOView).cleanObject(InternalCDOObject, InternalCDORevision) line: 1950
>>> CDOTransactionImpl(AbstractCDOView).createObject(CDOID) line: 1859
>>> CDOTransactionImpl(AbstractCDOView).getObject(CDOID, boolean) line: 1661
>>> CDOTransactionImpl.getObject(CDOID, boolean) line: 1498
>>> CDOTransactionImpl(AbstractCDOView).convertIDToObject(Object) line: 2140
>>> CDOStoreImpl.convertIDToObject(InternalCDOView, EObject, EStructuralFeature, int, Object) line: 897
>>> CDOStoreImpl.convertToEMF(EObject, InternalCDORevision, EStructuralFeature, int, Object) line: 860
>>> CDOStoreImpl.isSet(InternalEObject, EStructuralFeature) line: 248
>>> ValueTableImpl(CDOObjectImpl).eDynamicIsSet(int, EStructuralFeature) line: 734
>>> ValueTableImpl(BasicEObjectImpl).eIsSet(int) line: 1257
>>> ValueTableImpl(BasicEObjectImpl).eIsSet(EStructuralFeature) line: 1241
>>> EContentsEList$FeatureIteratorImpl<E>.hasNext() line: 437
>>> CacheAdapter(ECrossReferenceAdapter).setTarget(EObject) line: 775
>>> CacheAdapter(ECrossReferenceAdapter).setTarget(Notifier) line: 752
>>> CacheAdapter.setTarget(Notifier) line: 360
>>>
>>>
>>>
>>> Thread [Worker-1] (Suspended)
>>> owns: InheritableThreadLocal<T> (id=78)
>>> owns: CDOTransactionImpl (id=82)
>>> owns: SoxRepositoryProject (id=83)
>>> waiting for: CacheAdapter$InverseCrossReferencer (id=80)
>>> owned by: Thread [main] (Suspended)
>>> waiting for: InheritableThreadLocal<T> (id=78)
>>> owned by: Thread [Worker-1] (Suspended)
>>> waiting for: CacheAdapter$InverseCrossReferencer (id=80)
>>> owned by: Thread [main] (Suspended)
>>> CacheAdapter.handleCrossReference(EObject) line: 341
>>> AssociationImpl(ElementImpl).eSetDeliver(boolean) line: 988
>>> CDOLegacyAdapter(CDOLegacyWrapper).revisionToInstance() line: 520
>>>
>>>
>>> Both locks are static so I think the situation could also occur when working with different models are processed at
>>> the same time.
>>>
>>> Any idea how to tackle this?
>>>
>>> Regards,
>>> Thorsten
>
>


Re: [Papyrus, CDO] Deadlock situation when same model is loaded in different CDOViews [message #1733988 is a reply to message #1733950] Thu, 02 June 2016 16:16 Go to previous messageGo to next message
Thorsten Schlathölter is currently offline Thorsten SchlathölterFriend
Messages: 312
Registered: February 2012
Location: Düsseldorf
Senior Member
Thanks for paying attention to both of you.

Here is the bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=495323
Re: [Papyrus, CDO] Deadlock situation when same model is loaded in different CDOViews [message #1733989 is a reply to message #1733988] Thu, 02 June 2016 16:39 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6690
Registered: July 2009
Senior Member
Am 02.06.2016 um 18:16 schrieb Thorsten Schlathölter:
> Thanks for paying attention to both of you.
>
> Here is the bug:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=495323
I doubt, though, that any respective changes will make it into Neon. So, you may want to evaluate the alternative that
Christian layed out in the meantime, i.e., create your own CacheAdapter per ResourceSet.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Previous Topic:How to specify the Type of an attribute programmatically?
Next Topic:Eclipse custom import wizard plugin
Goto Forum:
  


Current Time: Sun Nov 10 18:15:16 GMT 2024

Powered by FUDForum. Page generated in 0.06224 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top