Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » Re: ConcurrentModificationExceptions with ECoreUtil.resolveAll
Re: ConcurrentModificationExceptions with ECoreUtil.resolveAll [message #470413] Wed, 14 February 2007 11:57 Go to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31049
Registered: July 2009
Senior Member
Paul,

It sounds likely that this is a multi-threading issue. Certainly
ECrossReferenceAdapter is not designed for safe multi-threaded updates
and I don't think the CacheAdapter is specialized to support that
either. I didn't see your posting on the UML newsgroup, so I added it
to the "to" list.


Paul Kelly wrote:
> Hi,
>
> I get the following exception when I call ECoreUtil.resolveAll :
>
> java.util.ConcurrentModificationException: concurrent access to
> HashMap attempted by Thread[Worker-6,5,main]
> at java.util.HashMap.onExit(HashMap.java:217)
> at java.util.HashMap.transfer(HashMap.java:514)
> at java.util.HashMap.resize(HashMap.java:500)
> at java.util.HashMap.addEntry(HashMap.java:800)
> at java.util.HashMap.put(HashMap.java:441)
> at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:420)
> at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:393)
> at
> org.eclipse.uml2.uml.internal.impl.PropertyImpl.getDeployedE lements(PropertyImpl.java:635)
>
> at
> org.eclipse.uml2.uml.internal.impl.PropertyImpl.eIsSet(Prope rtyImpl.java:2551)
>
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:818)
>
> at
> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:414)
>
> at
> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.next(EContentsEList.java:549)
>
> at
> org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences( EcoreUtil.java:302)
>
> at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.ja va:296)
>
> Just wondering if anyone else has come across this issue?
> I wasn't sure whether to post to the uml2 or emf forum, decided on both.
> Its a hard one to recreate, but i've typically seen it when there are
> many background tasks running. I know there was a similar bug for
> getAppliedStereotypes(), just wondering if there is a fix or
> workaround for this issue? Any help appreciated.
>
> Cheers,
>
> Paul
Re: ConcurrentModificationExceptions with ECoreUtil.resolveAll [message #470414 is a reply to message #470413] Wed, 14 February 2007 12:25 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: pkelly03.gmail.com

Thanks for update Ed.

Paul

Ed Merks wrote:
> Paul,
>
> It sounds likely that this is a multi-threading issue. Certainly
> ECrossReferenceAdapter is not designed for safe multi-threaded updates
> and I don't think the CacheAdapter is specialized to support that
> either. I didn't see your posting on the UML newsgroup, so I added it
> to the "to" list.
>
>
> Paul Kelly wrote:
>> Hi,
>>
>> I get the following exception when I call ECoreUtil.resolveAll :
>>
>> java.util.ConcurrentModificationException: concurrent access to
>> HashMap attempted by Thread[Worker-6,5,main]
>> at java.util.HashMap.onExit(HashMap.java:217)
>> at java.util.HashMap.transfer(HashMap.java:514)
>> at java.util.HashMap.resize(HashMap.java:500)
>> at java.util.HashMap.addEntry(HashMap.java:800)
>> at java.util.HashMap.put(HashMap.java:441)
>> at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:420)
>> at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:393)
>> at
>> org.eclipse.uml2.uml.internal.impl.PropertyImpl.getDeployedE lements(PropertyImpl.java:635)
>>
>> at
>> org.eclipse.uml2.uml.internal.impl.PropertyImpl.eIsSet(Prope rtyImpl.java:2551)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:818)
>>
>> at
>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:414)
>>
>> at
>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.next(EContentsEList.java:549)
>>
>> at
>> org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences( EcoreUtil.java:302)
>>
>> at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.ja va:296)
>>
>> Just wondering if anyone else has come across this issue?
>> I wasn't sure whether to post to the uml2 or emf forum, decided on both.
>> Its a hard one to recreate, but i've typically seen it when there are
>> many background tasks running. I know there was a similar bug for
>> getAppliedStereotypes(), just wondering if there is a fix or
>> workaround for this issue? Any help appreciated.
>>
>> Cheers,
>>
>> Paul
Re: ConcurrentModificationExceptions with ECoreUtil.resolveAll [message #470415 is a reply to message #470413] Wed, 14 February 2007 14:32 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Ed,

While it's true that the cross-referencing aspects of the cache adapter (as
extended from EMF) weren't designed to be thread-safe, the data caching
aspects were... This particular problem should have been fixed by
https://bugs.eclipse.org/bugs/show_bug.cgi?id=172040.

Kenn

"Ed Merks" <merks@ca.ibm.com> wrote in message
news:equtel$t30$1@utils.eclipse.org...
> Paul,
>
> It sounds likely that this is a multi-threading issue. Certainly
> ECrossReferenceAdapter is not designed for safe multi-threaded updates and
> I don't think the CacheAdapter is specialized to support that either. I
> didn't see your posting on the UML newsgroup, so I added it to the "to"
> list.
>
>
> Paul Kelly wrote:
>> Hi,
>>
>> I get the following exception when I call ECoreUtil.resolveAll :
>>
>> java.util.ConcurrentModificationException: concurrent access to HashMap
>> attempted by Thread[Worker-6,5,main]
>> at java.util.HashMap.onExit(HashMap.java:217)
>> at java.util.HashMap.transfer(HashMap.java:514)
>> at java.util.HashMap.resize(HashMap.java:500)
>> at java.util.HashMap.addEntry(HashMap.java:800)
>> at java.util.HashMap.put(HashMap.java:441)
>> at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:420)
>> at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:393)
>> at
>> org.eclipse.uml2.uml.internal.impl.PropertyImpl.getDeployedE lements(PropertyImpl.java:635)
>> at
>> org.eclipse.uml2.uml.internal.impl.PropertyImpl.eIsSet(Prope rtyImpl.java:2551)
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:818)
>> at
>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:414)
>> at
>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.next(EContentsEList.java:549)
>> at
>> org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences( EcoreUtil.java:302)
>> at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.ja va:296)
>>
>> Just wondering if anyone else has come across this issue?
>> I wasn't sure whether to post to the uml2 or emf forum, decided on both.
>> Its a hard one to recreate, but i've typically seen it when there are
>> many background tasks running. I know there was a similar bug for
>> getAppliedStereotypes(), just wondering if there is a fix or workaround
>> for this issue? Any help appreciated.
>>
>> Cheers,
>>
>> Paul
Re: ConcurrentModificationExceptions with ECoreUtil.resolveAll [message #470931 is a reply to message #470415] Wed, 14 February 2007 15:11 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31049
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010203090306090301060800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Kenn,

I thought I remembered something about this being fixed. I think this
stream will be released on Friday along with Eclipse 3.2.2, right?


Kenn Hussey wrote:
> Ed,
>
> While it's true that the cross-referencing aspects of the cache adapter (as
> extended from EMF) weren't designed to be thread-safe, the data caching
> aspects were... This particular problem should have been fixed by
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=172040.
>
> Kenn
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:equtel$t30$1@utils.eclipse.org...
>
>> Paul,
>>
>> It sounds likely that this is a multi-threading issue. Certainly
>> ECrossReferenceAdapter is not designed for safe multi-threaded updates and
>> I don't think the CacheAdapter is specialized to support that either. I
>> didn't see your posting on the UML newsgroup, so I added it to the "to"
>> list.
>>
>>
>> Paul Kelly wrote:
>>
>>> Hi,
>>>
>>> I get the following exception when I call ECoreUtil.resolveAll :
>>>
>>> java.util.ConcurrentModificationException: concurrent access to HashMap
>>> attempted by Thread[Worker-6,5,main]
>>> at java.util.HashMap.onExit(HashMap.java:217)
>>> at java.util.HashMap.transfer(HashMap.java:514)
>>> at java.util.HashMap.resize(HashMap.java:500)
>>> at java.util.HashMap.addEntry(HashMap.java:800)
>>> at java.util.HashMap.put(HashMap.java:441)
>>> at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:420)
>>> at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:393)
>>> at
>>> org.eclipse.uml2.uml.internal.impl.PropertyImpl.getDeployedE lements(PropertyImpl.java:635)
>>> at
>>> org.eclipse.uml2.uml.internal.impl.PropertyImpl.eIsSet(Prope rtyImpl.java:2551)
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:818)
>>> at
>>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:414)
>>> at
>>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.next(EContentsEList.java:549)
>>> at
>>> org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences( EcoreUtil.java:302)
>>> at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.ja va:296)
>>>
>>> Just wondering if anyone else has come across this issue?
>>> I wasn't sure whether to post to the uml2 or emf forum, decided on both.
>>> Its a hard one to recreate, but i've typically seen it when there are
>>> many background tasks running. I know there was a similar bug for
>>> getAppliedStereotypes(), just wondering if there is a fix or workaround
>>> for this issue? Any help appreciated.
>>>
>>> Cheers,
>>>
>>> Paul
>>>
>
>
>


--------------010203090306090301060800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Kenn,<br>
<br>
I thought I remembered something about this being fixed.&nbsp; I think this
stream will be released on Friday along with Eclipse 3.2.2, right?<br>
<br>
<br>
Kenn Hussey wrote:
<blockquote cite="mideqv6h8$nvd$1@utils.eclipse.org" type="cite">
<pre wrap="">Ed,

While it's true that the cross-referencing aspects of the cache adapter (as
extended from EMF) weren't designed to be thread-safe, the data caching
aspects were... This particular problem should have been fixed by
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=172040">https://bugs.eclipse.org/bugs/show_bug.cgi?id=172040</a>.

Kenn

"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com">&lt;merks@ca.ibm.com&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:equtel$t30$1@utils.eclipse.org">news:equtel$t30$1@utils.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Paul,

It sounds likely that this is a multi-threading issue. Certainly
ECrossReferenceAdapter is not designed for safe multi-threaded updates and
I don't think the CacheAdapter is specialized to support that either. I
didn't see your posting on the UML newsgroup, so I added it to the "to"
list.


Paul Kelly wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,

I get the following exception when I call ECoreUtil.resolveAll :

java.util.ConcurrentModificationException: concurrent access to HashMap
attempted by Thread[Worker-6,5,main]
at java.util.HashMap.onExit(HashMap.java:217)
at java.util.HashMap.transfer(HashMap.java:514)
at java.util.HashMap.resize(HashMap.java:500)
at java.util.HashMap.addEntry(HashMap.java:800)
at java.util.HashMap.put(HashMap.java:441)
at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:420)
at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:393)
at
org.eclipse.uml2.uml.internal.impl.PropertyImpl.getDeployedE lements(PropertyImpl.java:635)
at
org.eclipse.uml2.uml.internal.impl.PropertyImpl.eIsSet(Prope rtyImpl.java:2551)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:818)
at
org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:414)
at
org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.next(EContentsEList.java:549)
at
org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences( EcoreUtil.java:302)
at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.ja va:296)

Just wondering if anyone else has come across this issue?
I wasn't sure whether to post to the uml2 or emf forum, decided on both.
Its a hard one to recreate, but i've typically seen it when there are
many background tasks running. I know there was a similar bug for
getAppliedStereotypes(), just wondering if there is a fix or workaround
for this issue? Any help appreciated.

Cheers,

Paul
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
<br>
</body>
</html>

--------------010203090306090301060800--
Re: ConcurrentModificationExceptions with ECoreUtil.resolveAll [message #470934 is a reply to message #470931] Wed, 14 February 2007 15:14 Go to previous message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.

------=_NextPart_000_074C_01C75020.FBD64E50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes.
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:eqv8qf$c02$2@utils.eclipse.org...
Kenn,

I thought I remembered something about this being fixed. I think this =
stream will be released on Friday along with Eclipse 3.2.2, right?


Kenn Hussey wrote:=20
Ed,

While it's true that the cross-referencing aspects of the cache adapter =
(as=20
extended from EMF) weren't designed to be thread-safe, the data caching=20
aspects were... This particular problem should have been fixed by=20
https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D172040.

Kenn

"Ed Merks" <merks@ca.ibm.com> wrote in message=20
news:equtel$t30$1@utils.eclipse.org...
Paul,

It sounds likely that this is a multi-threading issue. Certainly=20
ECrossReferenceAdapter is not designed for safe multi-threaded updates =
and=20
I don't think the CacheAdapter is specialized to support that either. I =

didn't see your posting on the UML newsgroup, so I added it to the "to"=20
list.


Paul Kelly wrote:
Hi,

I get the following exception when I call ECoreUtil.resolveAll :

java.util.ConcurrentModificationException: concurrent access to HashMap=20
attempted by Thread[Worker-6,5,main]
at java.util.HashMap.onExit(HashMap.java:217)
at java.util.HashMap.transfer(HashMap.java:514)
at java.util.HashMap.resize(HashMap.java:500)
at java.util.HashMap.addEntry(HashMap.java:800)
at java.util.HashMap.put(HashMap.java:441)
at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:420)
at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:393)
at=20
org.eclipse.uml2.uml.internal.impl.PropertyImpl.getDeployedE lements(Prope=
rtyImpl.java:635)
at=20
org.eclipse.uml2.uml.internal.impl.PropertyImpl.eIsSet(Prope rtyImpl.java:=
2551)
at=20
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:=
818)
at=20
org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(ECo=
ntentsEList.java:414)
at=20
org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.next(EConte=
ntsEList.java:549)
at=20
org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences( EcoreUtil.jav=
a:302)
at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.ja va:296)

Just wondering if anyone else has come across this issue?
I wasn't sure whether to post to the uml2 or emf forum, decided on both.
Its a hard one to recreate, but i've typically seen it when there are=20
many background tasks running. I know there was a similar bug for=20
getAppliedStereotypes(), just wondering if there is a fix or workaround=20
for this issue? Any help appreciated.

Cheers,

Paul=20
=20

=20

------=_NextPart_000_074C_01C75020.FBD64E50
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2900.3020" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Yes.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" &lt;<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>&gt;=20
wrote in message <A=20
=
href=3D"news:eqv8qf$c02$2@utils.eclipse.org">news:eqv8qf$c02$2@utils.ecli=
pse.org</A>...</DIV>Kenn,<BR><BR>I=20
thought I remembered something about this being fixed.&nbsp; I think =
this=20
stream will be released on Friday along with Eclipse 3.2.2,=20
right?<BR><BR><BR>Kenn Hussey wrote:=20
<BLOCKQUOTE cite=3Dmideqv6h8$nvd$1@utils.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Ed,

While it's true that the cross-referencing aspects of the cache adapter =
(as=20
extended from EMF) weren't designed to be thread-safe, the data caching=20
aspects were... This particular problem should have been fixed by=20
<A class=3Dmoz-txt-link-freetext =
href=3D"https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D172040">https://b=
ugs.eclipse.org/bugs/show_bug.cgi?id=3D172040</A>.

Kenn

"Ed Merks" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:merks@ca.ibm.com">&lt;merks@ca.ibm.com&gt;</A> wrote in =
message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:equtel$t30$1@utils.eclipse.org">news:equtel$t30$1@utils.ecli=
pse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Paul,

It sounds likely that this is a multi-threading issue. Certainly=20
ECrossReferenceAdapter is not designed for safe multi-threaded updates =
and=20
I don't think the CacheAdapter is specialized to support that either. I =

didn't see your posting on the UML newsgroup, so I added it to the "to"=20
list.


Paul Kelly wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi,

I get the following exception when I call ECoreUtil.resolveAll :

java.util.ConcurrentModificationException: concurrent access to HashMap=20
attempted by Thread[Worker-6,5,main]
at java.util.HashMap.onExit(HashMap.java:217)
at java.util.HashMap.transfer(HashMap.java:514)
at java.util.HashMap.resize(HashMap.java:500)
at java.util.HashMap.addEntry(HashMap.java:800)
at java.util.HashMap.put(HashMap.java:441)
at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:420)
at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:393)
at=20
org.eclipse.uml2.uml.internal.impl.PropertyImpl.getDeployedE lements(Prope=
rtyImpl.java:635)
at=20
org.eclipse.uml2.uml.internal.impl.PropertyImpl.eIsSet(Prope rtyImpl.java:=
2551)
at=20
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:=
818)
at=20
org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(ECo=
ntentsEList.java:414)
at=20
org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.next(EConte=
ntsEList.java:549)
at=20
org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences( EcoreUtil.jav=
a:302)
at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.ja va:296)

Just wondering if anyone else has come across this issue?
I wasn't sure whether to post to the uml2 or emf forum, decided on both.
Its a hard one to recreate, but i've typically seen it when there are=20
many background tasks running. I know there was a similar bug for=20
getAppliedStereotypes(), just wondering if there is a fix or workaround=20
for this issue? Any help appreciated.

Cheers,

Paul=20
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""><!---->

</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_074C_01C75020.FBD64E50--
Re: ConcurrentModificationExceptions with ECoreUtil.resolveAll [message #588738 is a reply to message #470413] Wed, 14 February 2007 12:25 Go to previous message
Eclipse UserFriend
Originally posted by: pkelly03.gmail.com

Thanks for update Ed.

Paul

Ed Merks wrote:
> Paul,
>
> It sounds likely that this is a multi-threading issue. Certainly
> ECrossReferenceAdapter is not designed for safe multi-threaded updates
> and I don't think the CacheAdapter is specialized to support that
> either. I didn't see your posting on the UML newsgroup, so I added it
> to the "to" list.
>
>
> Paul Kelly wrote:
>> Hi,
>>
>> I get the following exception when I call ECoreUtil.resolveAll :
>>
>> java.util.ConcurrentModificationException: concurrent access to
>> HashMap attempted by Thread[Worker-6,5,main]
>> at java.util.HashMap.onExit(HashMap.java:217)
>> at java.util.HashMap.transfer(HashMap.java:514)
>> at java.util.HashMap.resize(HashMap.java:500)
>> at java.util.HashMap.addEntry(HashMap.java:800)
>> at java.util.HashMap.put(HashMap.java:441)
>> at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:420)
>> at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:393)
>> at
>> org.eclipse.uml2.uml.internal.impl.PropertyImpl.getDeployedE lements(PropertyImpl.java:635)
>>
>> at
>> org.eclipse.uml2.uml.internal.impl.PropertyImpl.eIsSet(Prope rtyImpl.java:2551)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:818)
>>
>> at
>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:414)
>>
>> at
>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.next(EContentsEList.java:549)
>>
>> at
>> org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences( EcoreUtil.java:302)
>>
>> at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.ja va:296)
>>
>> Just wondering if anyone else has come across this issue?
>> I wasn't sure whether to post to the uml2 or emf forum, decided on both.
>> Its a hard one to recreate, but i've typically seen it when there are
>> many background tasks running. I know there was a similar bug for
>> getAppliedStereotypes(), just wondering if there is a fix or
>> workaround for this issue? Any help appreciated.
>>
>> Cheers,
>>
>> Paul
Re: ConcurrentModificationExceptions with ECoreUtil.resolveAll [message #588749 is a reply to message #470413] Wed, 14 February 2007 14:32 Go to previous message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Ed,

While it's true that the cross-referencing aspects of the cache adapter (as
extended from EMF) weren't designed to be thread-safe, the data caching
aspects were... This particular problem should have been fixed by
https://bugs.eclipse.org/bugs/show_bug.cgi?id=172040

Kenn

"Ed Merks" <merks@ca.ibm.com> wrote in message
news:equtel$t30$1@utils.eclipse.org...
> Paul,
>
> It sounds likely that this is a multi-threading issue. Certainly
> ECrossReferenceAdapter is not designed for safe multi-threaded updates and
> I don't think the CacheAdapter is specialized to support that either. I
> didn't see your posting on the UML newsgroup, so I added it to the "to"
> list.
>
>
> Paul Kelly wrote:
>> Hi,
>>
>> I get the following exception when I call ECoreUtil.resolveAll :
>>
>> java.util.ConcurrentModificationException: concurrent access to HashMap
>> attempted by Thread[Worker-6,5,main]
>> at java.util.HashMap.onExit(HashMap.java:217)
>> at java.util.HashMap.transfer(HashMap.java:514)
>> at java.util.HashMap.resize(HashMap.java:500)
>> at java.util.HashMap.addEntry(HashMap.java:800)
>> at java.util.HashMap.put(HashMap.java:441)
>> at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:420)
>> at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:393)
>> at
>> org.eclipse.uml2.uml.internal.impl.PropertyImpl.getDeployedE lements(PropertyImpl.java:635)
>> at
>> org.eclipse.uml2.uml.internal.impl.PropertyImpl.eIsSet(Prope rtyImpl.java:2551)
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:818)
>> at
>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:414)
>> at
>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.next(EContentsEList.java:549)
>> at
>> org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences( EcoreUtil.java:302)
>> at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.ja va:296)
>>
>> Just wondering if anyone else has come across this issue?
>> I wasn't sure whether to post to the uml2 or emf forum, decided on both.
>> Its a hard one to recreate, but i've typically seen it when there are
>> many background tasks running. I know there was a similar bug for
>> getAppliedStereotypes(), just wondering if there is a fix or workaround
>> for this issue? Any help appreciated.
>>
>> Cheers,
>>
>> Paul
Re: ConcurrentModificationExceptions with ECoreUtil.resolveAll [message #588779 is a reply to message #470415] Wed, 14 February 2007 15:11 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31049
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010203090306090301060800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Kenn,

I thought I remembered something about this being fixed. I think this
stream will be released on Friday along with Eclipse 3.2.2, right?


Kenn Hussey wrote:
> Ed,
>
> While it's true that the cross-referencing aspects of the cache adapter (as
> extended from EMF) weren't designed to be thread-safe, the data caching
> aspects were... This particular problem should have been fixed by
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=172040
>
> Kenn
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:equtel$t30$1@utils.eclipse.org...
>
>> Paul,
>>
>> It sounds likely that this is a multi-threading issue. Certainly
>> ECrossReferenceAdapter is not designed for safe multi-threaded updates and
>> I don't think the CacheAdapter is specialized to support that either. I
>> didn't see your posting on the UML newsgroup, so I added it to the "to"
>> list.
>>
>>
>> Paul Kelly wrote:
>>
>>> Hi,
>>>
>>> I get the following exception when I call ECoreUtil.resolveAll :
>>>
>>> java.util.ConcurrentModificationException: concurrent access to HashMap
>>> attempted by Thread[Worker-6,5,main]
>>> at java.util.HashMap.onExit(HashMap.java:217)
>>> at java.util.HashMap.transfer(HashMap.java:514)
>>> at java.util.HashMap.resize(HashMap.java:500)
>>> at java.util.HashMap.addEntry(HashMap.java:800)
>>> at java.util.HashMap.put(HashMap.java:441)
>>> at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:420)
>>> at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:393)
>>> at
>>> org.eclipse.uml2.uml.internal.impl.PropertyImpl.getDeployedE lements(PropertyImpl.java:635)
>>> at
>>> org.eclipse.uml2.uml.internal.impl.PropertyImpl.eIsSet(Prope rtyImpl.java:2551)
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:818)
>>> at
>>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:414)
>>> at
>>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.next(EContentsEList.java:549)
>>> at
>>> org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences( EcoreUtil.java:302)
>>> at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.ja va:296)
>>>
>>> Just wondering if anyone else has come across this issue?
>>> I wasn't sure whether to post to the uml2 or emf forum, decided on both.
>>> Its a hard one to recreate, but i've typically seen it when there are
>>> many background tasks running. I know there was a similar bug for
>>> getAppliedStereotypes(), just wondering if there is a fix or workaround
>>> for this issue? Any help appreciated.
>>>
>>> Cheers,
>>>
>>> Paul
>>>
>
>
>


--------------010203090306090301060800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Kenn,<br>
<br>
I thought I remembered something about this being fixed.&nbsp; I think this
stream will be released on Friday along with Eclipse 3.2.2, right?<br>
<br>
<br>
Kenn Hussey wrote:
<blockquote cite="mideqv6h8$nvd$1@utils.eclipse.org" type="cite">
<pre wrap="">Ed,

While it's true that the cross-referencing aspects of the cache adapter (as
extended from EMF) weren't designed to be thread-safe, the data caching
aspects were... This particular problem should have been fixed by
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=172040">https://bugs.eclipse.org/bugs/show_bug.cgi?id=172040</a>.

Kenn

"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com">&lt;merks@ca.ibm.com&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:equtel$t30$1@utils.eclipse.org">news:equtel$t30$1@utils.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Paul,

It sounds likely that this is a multi-threading issue. Certainly
ECrossReferenceAdapter is not designed for safe multi-threaded updates and
I don't think the CacheAdapter is specialized to support that either. I
didn't see your posting on the UML newsgroup, so I added it to the "to"
list.


Paul Kelly wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,

I get the following exception when I call ECoreUtil.resolveAll :

java.util.ConcurrentModificationException: concurrent access to HashMap
attempted by Thread[Worker-6,5,main]
at java.util.HashMap.onExit(HashMap.java:217)
at java.util.HashMap.transfer(HashMap.java:514)
at java.util.HashMap.resize(HashMap.java:500)
at java.util.HashMap.addEntry(HashMap.java:800)
at java.util.HashMap.put(HashMap.java:441)
at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:420)
at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:393)
at
org.eclipse.uml2.uml.internal.impl.PropertyImpl.getDeployedE lements(PropertyImpl.java:635)
at
org.eclipse.uml2.uml.internal.impl.PropertyImpl.eIsSet(Prope rtyImpl.java:2551)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:818)
at
org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:414)
at
org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.next(EContentsEList.java:549)
at
org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences( EcoreUtil.java:302)
at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.ja va:296)

Just wondering if anyone else has come across this issue?
I wasn't sure whether to post to the uml2 or emf forum, decided on both.
Its a hard one to recreate, but i've typically seen it when there are
many background tasks running. I know there was a similar bug for
getAppliedStereotypes(), just wondering if there is a fix or workaround
for this issue? Any help appreciated.

Cheers,

Paul
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
<br>
</body>
</html>

--------------010203090306090301060800--
Re: ConcurrentModificationExceptions with ECoreUtil.resolveAll [message #588788 is a reply to message #470931] Wed, 14 February 2007 15:14 Go to previous message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.

------=_NextPart_000_074C_01C75020.FBD64E50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes.
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:eqv8qf$c02$2@utils.eclipse.org...
Kenn,

I thought I remembered something about this being fixed. I think this =
stream will be released on Friday along with Eclipse 3.2.2, right?


Kenn Hussey wrote:=20
Ed,

While it's true that the cross-referencing aspects of the cache adapter =
(as=20
extended from EMF) weren't designed to be thread-safe, the data caching=20
aspects were... This particular problem should have been fixed by=20
https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D172040

Kenn

"Ed Merks" <merks@ca.ibm.com> wrote in message=20
news:equtel$t30$1@utils.eclipse.org...
Paul,

It sounds likely that this is a multi-threading issue. Certainly=20
ECrossReferenceAdapter is not designed for safe multi-threaded updates =
and=20
I don't think the CacheAdapter is specialized to support that either. I =

didn't see your posting on the UML newsgroup, so I added it to the "to"=20
list.


Paul Kelly wrote:
Hi,

I get the following exception when I call ECoreUtil.resolveAll :

java.util.ConcurrentModificationException: concurrent access to HashMap=20
attempted by Thread[Worker-6,5,main]
at java.util.HashMap.onExit(HashMap.java:217)
at java.util.HashMap.transfer(HashMap.java:514)
at java.util.HashMap.resize(HashMap.java:500)
at java.util.HashMap.addEntry(HashMap.java:800)
at java.util.HashMap.put(HashMap.java:441)
at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:420)
at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:393)
at=20
org.eclipse.uml2.uml.internal.impl.PropertyImpl.getDeployedE lements(Prope=
rtyImpl.java:635)
at=20
org.eclipse.uml2.uml.internal.impl.PropertyImpl.eIsSet(Prope rtyImpl.java:=
2551)
at=20
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:=
818)
at=20
org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(ECo=
ntentsEList.java:414)
at=20
org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.next(EConte=
ntsEList.java:549)
at=20
org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences( EcoreUtil.jav=
a:302)
at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.ja va:296)

Just wondering if anyone else has come across this issue?
I wasn't sure whether to post to the uml2 or emf forum, decided on both.
Its a hard one to recreate, but i've typically seen it when there are=20
many background tasks running. I know there was a similar bug for=20
getAppliedStereotypes(), just wondering if there is a fix or workaround=20
for this issue? Any help appreciated.

Cheers,

Paul=20
=20

=20

------=_NextPart_000_074C_01C75020.FBD64E50
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2900.3020" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Yes.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" &lt;<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>&gt;=20
wrote in message <A=20
=
href=3D"news:eqv8qf$c02$2@utils.eclipse.org">news:eqv8qf$c02$2@utils.ecli=
pse.org</A>...</DIV>Kenn,<BR><BR>I=20
thought I remembered something about this being fixed.&nbsp; I think =
this=20
stream will be released on Friday along with Eclipse 3.2.2,=20
right?<BR><BR><BR>Kenn Hussey wrote:=20
<BLOCKQUOTE cite=3Dmideqv6h8$nvd$1@utils.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Ed,

While it's true that the cross-referencing aspects of the cache adapter =
(as=20
extended from EMF) weren't designed to be thread-safe, the data caching=20
aspects were... This particular problem should have been fixed by=20
<A class=3Dmoz-txt-link-freetext =
href=3D"https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D172040">https://b=
ugs.eclipse.org/bugs/show_bug.cgi?id=3D172040</A>.

Kenn

"Ed Merks" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:merks@ca.ibm.com">&lt;merks@ca.ibm.com&gt;</A> wrote in =
message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:equtel$t30$1@utils.eclipse.org">news:equtel$t30$1@utils.ecli=
pse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Paul,

It sounds likely that this is a multi-threading issue. Certainly=20
ECrossReferenceAdapter is not designed for safe multi-threaded updates =
and=20
I don't think the CacheAdapter is specialized to support that either. I =

didn't see your posting on the UML newsgroup, so I added it to the "to"=20
list.


Paul Kelly wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi,

I get the following exception when I call ECoreUtil.resolveAll :

java.util.ConcurrentModificationException: concurrent access to HashMap=20
attempted by Thread[Worker-6,5,main]
at java.util.HashMap.onExit(HashMap.java:217)
at java.util.HashMap.transfer(HashMap.java:514)
at java.util.HashMap.resize(HashMap.java:500)
at java.util.HashMap.addEntry(HashMap.java:800)
at java.util.HashMap.put(HashMap.java:441)
at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:420)
at org.eclipse.uml2.common.util.CacheAdapter.put(CacheAdapter.j ava:393)
at=20
org.eclipse.uml2.uml.internal.impl.PropertyImpl.getDeployedE lements(Prope=
rtyImpl.java:635)
at=20
org.eclipse.uml2.uml.internal.impl.PropertyImpl.eIsSet(Prope rtyImpl.java:=
2551)
at=20
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:=
818)
at=20
org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(ECo=
ntentsEList.java:414)
at=20
org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.next(EConte=
ntsEList.java:549)
at=20
org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences( EcoreUtil.jav=
a:302)
at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.ja va:296)

Just wondering if anyone else has come across this issue?
I wasn't sure whether to post to the uml2 or emf forum, decided on both.
Its a hard one to recreate, but i've typically seen it when there are=20
many background tasks running. I know there was a similar bug for=20
getAppliedStereotypes(), just wondering if there is a fix or workaround=20
for this issue? Any help appreciated.

Cheers,

Paul=20
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""><!---->

</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_074C_01C75020.FBD64E50--
Previous Topic:type conformance
Next Topic:EcoreUtil.copy() and stereotypes
Goto Forum:
  


Current Time: Fri Apr 10 20:28:02 GMT 2020

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

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

Back to the top