Application GUI fails to launch with ConcurrentModificationException

classic Classic list List threaded Threaded
4 messages Options
Joy
Reply | Threaded
Open this post in threaded view
|

Application GUI fails to launch with ConcurrentModificationException

Joy
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
Reply | Threaded
Open this post in threaded view
|

Re: Application GUI fails to launch with ConcurrentModificationException

James Lemieux
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,

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



--
View this message in context: http://glazedlists.1045722.n5.nabble.com/Application-GUI-fails-to-launch-with-ConcurrentModificationException-tp5709765.html
Sent from the GlazedLists - Dev mailing list archive at Nabble.com.

Joy
Reply | Threaded
Open this post in threaded view
|

Re: Application GUI fails to launch with ConcurrentModificationException

Joy
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
Reply | Threaded
Open this post in threaded view
|

Re: Application GUI fails to launch with ConcurrentModificationException

James Lemieux
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,

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



--
View this message in context: http://glazedlists.1045722.n5.nabble.com/Application-GUI-fails-to-launch-with-ConcurrentModificationException-tp5709765p5709767.html
Sent from the GlazedLists - Dev mailing list archive at Nabble.com.