Eclipse Community Forums: EMF » CDO Concurrent Modfiication Exception

Help

Home

Home » Modeling » EMF » CDO Concurrent Modfiication Exception

Show: Today's Messages :: Show Polls :: Message Navigator

CDO Concurrent Modfiication Exception [message #1761211]

Tue, 09 May 2017 01:48

Gabe Colburn

Messages: 17
Registered: December 2012

Junior Member

I've been developing an application using EMF, CDO, RAP/E4.

When a view part is displayed it opens a cdo transaction, and performs jface databinding between the widgets and the objects retrieved from the transaction.

A session listener is used to receive notification of changes by other clients. On such an event, the transaction in the view part is rolled back. The decision was that which ever client commits first wins and other clients will rollback rather than deal with merging.

Occasionally I observe the stracktrace beneath indicating concurrent modification, but I have had difficulty generating the error in a repeatable manner, making it rather difficult to pin down. It happens in perhaps 1/20 commits. Has anyone seen this before?

At first I thought perhaps the issue was accessing the shared transaction object possibly from multiple threads, but it sounds like CDOTransaction objects are generally thread safe. I would appreciate any advice.

Would I be correct to assume this error is being thrown on the CDO Server side and not the client side?

I'm using CDO 4.5.0.v20160607-1254

Thanks!

java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextNode(Unknown Source)
at java.util.HashMap$KeyIterator.next(Unknown Source)
at java.util.Collections$UnmodifiableCollection$1.next(Unknown Source)
at org.eclipse.emf.cdo.common.lock.CDOLockUtil.createLockState(CDOLockUtil.java:67)
at org.eclipse.emf.cdo.internal.server.Repository.toCDOLockStates(Repository.java:1832)
at org.eclipse.emf.cdo.internal.server.Repository.lock(Repository.java:1773)
at org.eclipse.emf.cdo.internal.server.Repository.lock(Repository.java:1727)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.LockObjectsIndication.indicating(LockObjectsIndication.java:66)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndication.indicating(CDOServerIndication.java:107)
at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:100)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:377)
at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:73)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerWriteIndication.execute(CDOServerWriteIndication.java:39)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:283)
at org.eclipse.net4j.signal.Signal.run(Signal.java:162)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Report message to a moderator

Re: CDO Concurrent Modfiication Exception [message #1761347 is a reply to message #1761211]

Wed, 10 May 2017 06:12

Gabe Colburn

Messages: 17
Registered: December 2012

Junior Member

After further debugging, after a commit (one attribute changed on an object), a flurry of CDOSessionLocksChangedEvent notifications are received in the session listener. If I print out when these occur, then sometimes intermittently the concurrent modification is thrown client side.

For editing one string in a text field with databinding to the cdo object about 100 CDOSessionLocksChangedEvent notifications are sent, which seems like a lot for modifying one attribute, but perhaps is related to a number of databinding updates on the form when a CDOSessionInvalidationEvent is received, causing automatic locks on the other objects.

I tried the following setting to not get the lock notifications:
session.options().setLockNotificationMode(LockNotificationMode.OFF);

but this didn't stop the CDOSessionLocksChangedEvent from arriving and periodically causing concurrent modification exceptions. Perhaps I am misunderstanding this option.

Report message to a moderator

Re: CDO Concurrent Modfiication Exception [message #1766577 is a reply to message #1761347]

Fri, 23 June 2017 08:51

Eike Stepper

Messages: 6381
Registered: July 2009

Senior Member

Sorry for the late reply! In the past year we've applied some fundamental changes to the locking subsystem. Perhaps you should first try with the newest 4.6 release: http://download.eclipse.org/modeling/emf/cdo/drops/R20170614-0227

Please let us know if that fixes the problem...

Report message to a moderator

Re: CDO Concurrent Modfiication Exception [message #1771560 is a reply to message #1766577]

Mon, 28 August 2017 01:59

Pavel Vlasov

Messages: 23
Registered: December 2015

Junior Member

Hi Eike,

It looks like I'm facing a similar issue when I have 10 concurrent threads working on the same repository:

org.eclipse.net4j.signal.RemoteException: java.util.ConcurrentModificationException
at org.eclipse.net4j.signal.RequestWithConfirmation.getRemoteException(RequestWithConfirmation.java:141)
at org.eclipse.net4j.signal.RequestWithConfirmation.setRemoteException(RequestWithConfirmation.java:130)
at org.eclipse.net4j.signal.SignalProtocol.handleRemoteException(SignalProtocol.java:488)
at org.eclipse.net4j.signal.RemoteExceptionIndication.indicating(RemoteExceptionIndication.java:62)
at org.eclipse.net4j.signal.Indication.doExtendedInput(Indication.java:57)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:377)
at org.eclipse.net4j.signal.Indication.execute(Indication.java:51)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:283)
at org.eclipse.net4j.signal.Signal.run(Signal.java:162)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextNode(Unknown Source)
at java.util.HashMap$KeyIterator.next(Unknown Source)
at java.util.Collections$UnmodifiableCollection$1.next(Unknown Source)
at org.eclipse.emf.cdo.common.lock.CDOLockUtil.createLockState(CDOLockUtil.java:67)
at org.eclipse.emf.cdo.internal.server.Repository.toCDOLockStates(Repository.java:1983)
at org.eclipse.emf.cdo.internal.server.Repository.doUnlock(Repository.java:2020)
at org.eclipse.emf.cdo.internal.server.Repository.unlock(Repository.java:2004)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.UnlockObjectsIndication.indicating(UnlockObjectsIndication.java:71)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndication.indicating(CDOServerIndication.java:108)
at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:100)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:377)
at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:73)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerWriteIndication.execute(CDOServerWriteIndication.java:39)

I'm using Oxygen Release and Orbit R20170516192513. Is the drop you've recommended part of Oxygen? I've checked the versions of some bundles involved - they are the same.
---
Thank you, Pavel.

Report message to a moderator

Re: CDO Concurrent Modfiication Exception [message #1771635 is a reply to message #1771560]

Tue, 29 August 2017 03:40

Pavel Vlasov

Messages: 23
Registered: December 2015

Junior Member

I've stepped through the code and it looks like that the reason for this exception is that at CDOLockUtil line 67 a set of ReadLockOwners is returned from the lockState:
for (CDOCommonView view : lockState.getReadLockOwners())

The set is unmodifiable, but it is backed by org.eclipse.net4j.util.concurrent.RWOLockManager.LockState.readLockOwners set, which is modifiable. When this set is modified by another thread in org.eclipse.net4j.util.concurrent.RWOLockManager.LockState.doReadLock(CONTEXT) that causes ConcurrentModificationException.

Below are a couple of thoughts regarding how it might be addressed:

A simple solution might be to add synchronized blocks around the original set and return an unmodifiable copy from getReadLockOwners(). I don't know if that would be an acceptable solution because the iteration loop will not see concurrent modifications.

Another option is to protect readLockOwners by a lock, including the iteration loop, or wrap into a SynchronizedSet with Collections.synchronizedSet(). To keep the lock/synchronization encapsulated in the LockState getReadLockOwners() may be replaced by forEachReadLockOwner(Consumer<CONTEXT>).

[Updated on: Tue, 29 August 2017 19:24]

Report message to a moderator