+++ This bug was initially created as a clone of Bug #1105280 +++

When using a clustered EAP configuration , and accessing the same page from multiple tabs 
Some hashmaps are being accessed from multiple thread and since they are not thread safe a concurrency exception is triggered
this is reproducible for : com.sun.faces.renderkit.ServerSideStateHelper.LogicalViewMap

But there might also be issues with :
com.sun.faces.application.view.activeViewMaps
org.jboss.weld.context.ConversationContext.conversations


The problem occurs whether you use @inject or @managedbean

a simple JSF war reproducer is attached .

1) install into eap
2) access page, and enter a value , update value
3) open another tab
4) hit refresh multiple times on the second tab until the exception occurs

--- Additional comment from  on 2014-06-05 16:39:33 EDT ---

All objects placed in the session must be thread safe, including serialization.

Since a HashMap (or LRUMap that extends HashMap) is not thread safe, it cannot be a top-level attribute in the session (unless it is immutable, which is not the case here).

The HashMaps being put in the session with the IDs in the above description must be replaced with a thread-safe object.

--- Additional comment from Farah Juma on 2014-06-06 13:12:38 EDT ---

I've created the following upstream issue and submitted a patch to make the LogicalViewMap synchronized:

https://java.net/jira/browse/JAVASERVERFACES-3323

If this patch looks good to the Mojarra team, I can apply it to our fork.

--- Additional comment from Farah Juma on 2014-06-06 13:32:03 EDT ---

Note that there's no longer an issue with the other JSF HashMap mentioned in the description, i.e., com.sun.faces.application.view.activeViewMaps. That was already fixed in Mojarra 2.1.28 (see https://java.net/jira/browse/JAVASERVERFACES-3159).

--- Additional comment from Farah Juma on 2014-06-11 11:37:17 EDT ---

My patch for JAVASERVERFACES-3323 has now been merged to the 2.2.x branch upstream and I've created JAVASERVERFACES-3325 to have this fix backported to the 2.1.x branch upstream. I've also applied the fix to our 2.1.28 fork and released the 2.1.28-jbossorg-3 version of jsf-impl. The source is available here:

https://github.com/jboss/mojarra/tree/2.1.28-jbossorg-3