Application GUI fails to launch with ConcurrentModificationExceptio
Locked
 
|
Hi Team,
We are getting ConcurrentModification exception while launch of CEX Application GUI. java.util.ConcurrentModificationException at java.util.IdentityHashMap$IdentityHashMapIterator.nextIndex(IdentityHashMap.java:715) at java.util.IdentityHashMap$EntryIterator.next(IdentityHashMap.java:823) at java.util.IdentityHashMap$EntryIterator.next(IdentityHashMap.java:818) at ca.odell.glazedlists.event.SequenceDependenciesEventPublisher.fireEvent(SequenceDependenciesEventPublisher.java:352) at ca.odell.glazedlists.event.ListEventAssembler.commitEvent(ListEventAssembler.java:316) at ca.odell.glazedlists.FilterList.changed(FilterList.java:423) at ca.odell.glazedlists.FilterList.<init>(FilterList.java:90) at com.ericsson.oss.cex.topology.wcdma.ui.RNCRBSRXITopologyPage.createControl(Unknown Source) at com.ericsson.oss.cp.topology.ui.internal.TopologyPageFactory.createPages(TopologyPageFactory.java:75) at com.ericsson.oss.cp.topology.ui.views.TopologyView.createPagesRecs(TopologyView.java:381) at com.ericsson.oss.cp.topology.ui.views.TopologyView.createPartControl(TopologyView.java:418) at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:367) at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:226) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595) at org.eclipse.ui.internal.ViewReference.getView(ViewReference.java:195) at org.eclipse.ui.internal.WorkbenchPage.findView(WorkbenchPage.java:1907) at com.ericsson.oss.nsd.status.ui.views.StatusView.getDefaultPart(Unknown Source) Can you please let us know if the IdentityHashMapIterator class externally handles thread synchronization or not? If it does, how to rectify this exception which I am getting. Thanks' Joy |
Re: Application GUI fails to launch with ConcurrentModificationExceptio
|
|
The issue at play here is that you are not guarding your list pipline from changing *while* you construct your FilterList.
The code in com.ericsson.oss.cex.topology.wcdma.ui.RNCRBSRXITopologyPage.createControl(...) that constructs the FilterList needs to look like this: EventList source = ... source.getReadWriteLock().readLock().lock(); try { filtered = new FilterList(source, ...); } finally { source.getReadWriteLock().readLock().unlock(); } Alternatively, if you're already locking correctly in that part of the code, there is another location in your source code that is not locking properly. Consider temporarily replacing the BasicEventList at the root of your pipeline with a DebugList, which can help you locate the offending (unguarded) code. James On Mon, Sep 3, 2012 at 11:48 PM, Joy <[hidden email]> wrote: Hi Team, |
|
|
Hi James,
Thanks for your quick response to this thread. However the code suggested by you will surround the code with try and finally block then it will unlock when exception occur but it will not avoid the exception and fix the issue. We have checked the glazedlists class file as well (IdentityHashMap, SequenceDependenciesEventPublisher) and in IdentityHashMap.nextIndex()method is throwing Concurrent ModificationException as shown below: implements Map.Entry<K,V> { public Map.Entry<K,V> next() { nextIndex(); return this; } protected int nextIndex() { if (modCount != expectedModCount) throw new ConcurrentModificationException(); if (!indexValid && !hasNext()) throw new NoSuchElementException(); indexValid = false; lastReturnedIndex = index; index += 2; return lastReturnedIndex; } Now in order to avoid the exception we need to handle the concurrently accessing of the above method by two threads. So we need to synchronize the nextIndex() method or the next() method from where we are calling nextIndex(), and should we not handle the exception from the glazedlists side. Please let us know if you have a difference in view or there is a chance of improvement from design. Thanks' Joy |
Re: Application GUI fails to launch with ConcurrentModificationExceptio
|
|
Joy,
The point of using the locks, as I showed, is to PREVENT concurrent access (and thus the ConcurrentModificationException). This is standard practice in the design of JDK collections (as evidenced by the fact that it is a JDK collection class that is throwing the ConcurrentModificationException). Let me be clear, the issue at play here is not "to avoid the exception we need to handle the concurrently accessing of the above method by two threads." The point is to avoid concurrent access altogether. The way to do that is to have the competing threads synchronize their access to the data structure. The code I included showed one place in your code base (gleaned from the stack trace you sent) that you need to consider such synchronization. Using DebugList in place of BasicEventList will help you to uncover any other unsynchronized access to the data structure (the list pipeline). James On Wed, Sep 5, 2012 at 4:36 AM, Joy <[hidden email]> wrote: Hi James, |
«
Return to GlazedLists - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |