[BEEHIVE-779] ScopedRequestImpl.restoreAttributes() should not point the ScopedAttributeContainer at the Session's stored attribute HashMap instance

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: v1m1
• Fix Version/s: 1.0
• Assignee: Howard Carlin Rogers
• Reporter: Howard Carlin Rogers
• Created: 02/Jun/05 03:12
• Updated: 17/Jun/05 07:28
• Resolved: 08/Jun/05 04:33

Description

Currently the ScopedRequestImpl.restoreAttributes() assigns the
ScopedAttributeContainer with the Session's stored attribute HashMap instance.
If there are multiple requests to the server in very fast succession,
this will cause the use of the HashMap iterator to throw a
ConcurrentModificationException.

The problem is that during both restoreAttributes() and persistAttributes()
we are updating the session's instance of a HashMap. At the same time,
in persisAttributes() the call to the ScopedAttributeContainer's
getSerializableAttrs() uses the HashMap instance iterator
(HashMap.HashIterator). If between calls to next() for the next
MapEntry, and the number of elements in the Map gets altered,
we get the ConcurrentModificationException...

java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry()Ljava.util.HashMap$Entry;(Unknown Source)
at java.util.HashMap$EntryIterator.next()Ljava.util.Map$Entry;(Unknown Source)
at java.util.HashMap$EntryIterator.next()Ljava.lang.Object;(Unknown Source)
at org.apache.beehive.netui.pageflow.scoping.internal.AttributeContainer.getSerializableAttrs(AttributeContainer.java:91)
at org.apache.beehive.netui.pageflow.scoping.internal.ScopedRequestImpl.persistAttributes(ScopedRequestImpl.java:444)

I will take this one and submit a patch for the committers.