|
|
| Re: java.util.ConcurrentModificationException in AdapterFactoryContentProvide [message #431946 is a reply to message #431944] |
Thu, 30 July 2009 10:05   |
|
Jan,
I think the CDO Model Repository could help you with the mentioned
issues, and probably more. Not only CDO supports transactionality on
object level (EMF Transaction supports it on ResourceSet level and in
addition requires you to use commands to modify the model, IIRC). CDO
also shares model data among multiple transactions/views so that it's
rather cheap to create multiple transactions on the same session and
dedicate different threads to them. A proven pattern is to use a global
read-only view for all the UI lists and viewers and fork a transaction
in a background job for each modification action. Please let me know if
you would like more infos/pointers...
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Jan Kohnert schrieb:
> Hello,
>
> I've an RCP Application using EMF, JFace viewer and the EMF edit
> framework.
> When running my application I quite often get a
> ConcurrentModificationException when changes in the EMF model appear
> Stacktrace below).
>
> It might happen because of threads that are filling a List with
> runtime information within a synchronized method. Because of the
> AdapterFactoryContentProvide refreching the viewer using a asynchron
> runnable, the list may get changed in the middle of the operation.
>
> Is there a way to avoid such failures?
>
> !ENTRY org.eclipse.ui 4 0 2009-07-27 08:32:26.703
> !MESSAGE Unhandled event loop exception
> !STACK 0
> org.eclipse.swt.SWTException: Failed to execute runnable
> (java.util.ConcurrentModificationException)
> at org.eclipse.swt.SWT.error(SWT.java:3777)
> at org.eclipse.swt.SWT.error(SWT.java:3695)
> at
> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchr onizer.java:136)
>
> at
> org.eclipse.swt.widgets.Display.runAsyncMessages(Display.jav a:3800)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3425)
> at
> org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2382)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:21 98)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
>
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:488)
>
> at
> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at
> com.swisslab.xslprocessor.application.Application.start(Appl ication.java:75)
>
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:382)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 549)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
> Caused by: java.util.ConcurrentModificationException
> at
> org.eclipse.emf.common.util.BasicEList$EIterator.checkModCou nt(BasicEList.java:1378)
>
> at
> org.eclipse.emf.common.util.BasicEList$EIterator.doNext(Basi cEList.java:1326)
>
> at
> org.eclipse.emf.common.util.BasicEList$EIterator.next(BasicE List.java:1312)
>
> at
> org.eclipse.emf.edit.provider.ItemProviderAdapter.getChildre n(ItemProviderAdapter.java:340)
>
> at
> org.eclipse.emf.edit.provider.ItemProviderAdapter.hasChildre n(ItemProviderAdapter.java:397)
>
> at
> org.eclipse.emf.edit.provider.ItemProviderAdapter.hasChildre n(ItemProviderAdapter.java:384)
>
> at
> org.eclipse.emf.edit.ui.provider.AdapterFactoryContentProvid er.hasChildren(AdapterFactoryContentProvider.java:198)
>
> at
> com.swisslab.xslprocessor.ui.views.ReporterView$1.hasChildre n(ReporterView.java:134)
>
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.isExpandable(Ab stractTreeViewer.java:2076)
>
> at
> org.eclipse.jface.viewers.TreeViewer.isExpandable(TreeViewer .java:582)
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.isExpandable(Ab stractTreeViewer.java:2102)
>
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren( AbstractTreeViewer.java:2536)
>
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh Struct(AbstractTreeViewer.java:1856)
>
> at
> org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(T reeViewer.java:711)
>
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh Struct(AbstractTreeViewer.java:1863)
>
> at
> org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(T reeViewer.java:711)
>
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh (AbstractTreeViewer.java:1831)
>
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh (AbstractTreeViewer.java:1787)
>
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh (AbstractTreeViewer.java:1773)
>
> at
> org.eclipse.jface.viewers.StructuredViewer$7.run(StructuredV iewer.java:1430)
>
> at
> org.eclipse.jface.viewers.StructuredViewer.preservingSelecti on(StructuredViewer.java:1365)
>
> at
> org.eclipse.jface.viewers.TreeViewer.preservingSelection(Tre eViewer.java:397)
>
> at
> org.eclipse.jface.viewers.StructuredViewer.preservingSelecti on(StructuredViewer.java:1328)
>
> at
> org.eclipse.jface.viewers.StructuredViewer.refresh(Structure dViewer.java:1428)
>
> at
> org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer. java:537)
> at
> com.swisslab.xslprocessor.ui.views.ReporterView$1$1.run(Repo rterView.java:116)
>
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:3 5)
> at
> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchr onizer.java:133)
>
> ... 22 more
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
| Re: java.util.ConcurrentModificationException in AdapterFactoryContentProvide [message #492854 is a reply to message #491638] |
Thu, 22 October 2009 05:39 |
|
Hi Anders,
I'm not a UI expert but I'd expect that the UI queues up all UI tasks
and executes them one after the other.
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Anders Forsell schrieb:
> Eike,
>
> A follow-up question around your proposed pattern to solve this.
>
> Couldn't there still be a potential of
> ConcurrentModificationExceptions if:
>
> 1. A transaction is committed
> 2. The global view is invalidated and the change
> subscriptions/notifications are triggered to update the listeners in
> the TreeViewer.
> 3. Another transaction is committed
> 4. (same as 2)
>
> What happens if the UI thread is still updating the tree as a result
> of #2 when the next transaction triggers another update?
>
> ---
> Anders
>
> Eike Stepper wrote:
>> Jan,
>>
>> I think the CDO Model Repository could help you with the mentioned
>> issues, and probably more. Not only CDO supports transactionality on
>> object level (EMF Transaction supports it on ResourceSet level and in
>> addition requires you to use commands to modify the model, IIRC). CDO
>> also shares model data among multiple transactions/views so that it's
>> rather cheap to create multiple transactions on the same session and
>> dedicate different threads to them. A proven pattern is to use a global
>> read-only view for all the UI lists and viewers and fork a transaction
>> in a background job for each modification action. Please let me know if
>> you would like more infos/pointers...
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>> Jan Kohnert schrieb:
>>> Hello,
>>>
>>> I've an RCP Application using EMF, JFace viewer and the EMF edit
>>> framework.
>>> When running my application I quite often get a
>>> ConcurrentModificationException when changes in the EMF model appear
>>> Stacktrace below).
>>>
>>> It might happen because of threads that are filling a List with
>>> runtime information within a synchronized method. Because of the
>>> AdapterFactoryContentProvide refreching the viewer using a asynchron
>>> runnable, the list may get changed in the middle of the operation.
>>>
>>> Is there a way to avoid such failures?
>>>
>>> !ENTRY org.eclipse.ui 4 0 2009-07-27 08:32:26.703
>>> !MESSAGE Unhandled event loop exception
>>> !STACK 0
>>> org.eclipse.swt.SWTException: Failed to execute runnable
>>> (java.util.ConcurrentModificationException)
>>> at org.eclipse.swt.SWT.error(SWT.java:3777)
>>> at org.eclipse.swt.SWT.error(SWT.java:3695)
>>> at
>>> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchr onizer.java:136)
>>>
>>>
>>> at
>>> org.eclipse.swt.widgets.Display.runAsyncMessages(Display.jav a:3800)
>>> at
>>> org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3425)
>>> at
>>> org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2382)
>>> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
>>> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:21 98)
>>> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
>>> at
>>> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
>>>
>>>
>>> at
>>> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:488)
>>>
>>>
>>> at
>>> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
>>> at
>>> com.swisslab.xslprocessor.application.Application.start(Appl ication.java:75)
>>>
>>>
>>> at
>>> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
>>>
>>>
>>> at
>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
>>>
>>>
>>> at
>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
>>>
>>>
>>> at
>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:382)
>>>
>>>
>>> at
>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
>>>
>>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 549)
>>> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
>>> at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
>>> Caused by: java.util.ConcurrentModificationException
>>> at
>>> org.eclipse.emf.common.util.BasicEList$EIterator.checkModCou nt(BasicEList.java:1378)
>>>
>>>
>>> at
>>> org.eclipse.emf.common.util.BasicEList$EIterator.doNext(Basi cEList.java:1326)
>>>
>>>
>>> at
>>> org.eclipse.emf.common.util.BasicEList$EIterator.next(BasicE List.java:1312)
>>>
>>>
>>> at
>>> org.eclipse.emf.edit.provider.ItemProviderAdapter.getChildre n(ItemProviderAdapter.java:340)
>>>
>>>
>>> at
>>> org.eclipse.emf.edit.provider.ItemProviderAdapter.hasChildre n(ItemProviderAdapter.java:397)
>>>
>>>
>>> at
>>> org.eclipse.emf.edit.provider.ItemProviderAdapter.hasChildre n(ItemProviderAdapter.java:384)
>>>
>>>
>>> at
>>> org.eclipse.emf.edit.ui.provider.AdapterFactoryContentProvid er.hasChildren(AdapterFactoryContentProvider.java:198)
>>>
>>>
>>> at
>>> com.swisslab.xslprocessor.ui.views.ReporterView$1.hasChildre n(ReporterView.java:134)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.AbstractTreeViewer.isExpandable(Ab stractTreeViewer.java:2076)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.TreeViewer.isExpandable(TreeViewer .java:582)
>>> at
>>> org.eclipse.jface.viewers.AbstractTreeViewer.isExpandable(Ab stractTreeViewer.java:2102)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren( AbstractTreeViewer.java:2536)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh Struct(AbstractTreeViewer.java:1856)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(T reeViewer.java:711)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh Struct(AbstractTreeViewer.java:1863)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(T reeViewer.java:711)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh (AbstractTreeViewer.java:1831)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh (AbstractTreeViewer.java:1787)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh (AbstractTreeViewer.java:1773)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.StructuredViewer$7.run(StructuredV iewer.java:1430)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.StructuredViewer.preservingSelecti on(StructuredViewer.java:1365)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.TreeViewer.preservingSelection(Tre eViewer.java:397)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.StructuredViewer.preservingSelecti on(StructuredViewer.java:1328)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.StructuredViewer.refresh(Structure dViewer.java:1428)
>>>
>>>
>>> at
>>> org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer. java:537)
>>> at
>>> com.swisslab.xslprocessor.ui.views.ReporterView$1$1.run(Repo rterView.java:116)
>>>
>>>
>>> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:3 5)
>>> at
>>> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchr onizer.java:133)
>>>
>>>
>>> ... 22 more
>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.03830 seconds
] 
Search
Help
Register
Login
Home
