Bug 1105280 - [GSS] (6.3.1) ConcurrentModificationException due to non thread safe JSF HashMaps
Summary: [GSS] (6.3.1) ConcurrentModificationException due to non thread safe JSF Hash...
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: JSF
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: CR1
: EAP 6.3.1
Assignee: Farah Juma
QA Contact: Matous Jobanek
Russell Dickenson
Depends On: 1117365
Blocks: eap631-blockers, eap631-payload, eap63-cp01-blockers 1118035
TreeView+ depends on / blocked
Reported: 2014-06-05 18:39 UTC by Shay Matasaro
Modified: 2019-03-22 07:13 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1117365 (view as bug list)
Last Closed: 2014-10-13 18:36:37 UTC
Type: Bug

Attachments (Terms of Use)
JSF war (8.09 KB, application/octet-stream)
2014-06-05 18:39 UTC, Shay Matasaro
no flags Details
Server log connected to the conversation issue (75.39 KB, text/plain)
2014-08-11 14:39 UTC, Matous Jobanek
no flags Details
Reproducer for the conversation issue (14.25 KB, application/x-zip-compressed)
2014-08-11 14:52 UTC, Matous Jobanek
no flags Details

Description Shay Matasaro 2014-06-05 18:39:09 UTC
Created attachment 902624 [details]
JSF war

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 :

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

Comment 1 dereed 2014-06-05 20:39:33 UTC
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.

Comment 2 Farah Juma 2014-06-06 17:12:38 UTC
I've created the following upstream issue and submitted a patch to make the LogicalViewMap synchronized:


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

Comment 3 Farah Juma 2014-06-06 17:32:03 UTC
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).

Comment 4 Farah Juma 2014-06-11 15:37:17 UTC
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:


Comment 5 Rostislav Svoboda 2014-07-09 12:09:27 UTC
Adding to the EAP 6.3.1 (CP01) Blockers Tracker per Farah's request.

Comment 7 Farah Juma 2014-08-07 14:00:47 UTC
Thanks for adding the link to the commit for JAVASERVERFACES-3323/JAVASERVERFACES-3325.

There isn't a test case upstream for this since it would be difficult to test this automatically. However, I've added this to the manual tests that are performed when doing a jsf-impl release.

Comment 8 Matous Jobanek 2014-08-07 14:15:18 UTC
I've tested EAP 6.3.0 with jsf-impl-2.1.28-jbossorg-3.jar and your reproducer and the issue is still there - the exception ConcurrentModificationException is still thrown

Comment 9 Farah Juma 2014-08-07 14:59:35 UTC
I just tried testing it again several times using EAP 6.3.0 with jsf-impl-2.1.28-jbossorg-3.jar and I'm not able to reproduce the issue. Just to make sure we're using the same jsf-impl version, you're testing with jsf-impl-2.1.28-jbossorg-3.jar and *not* with jsf-impl-2.1.28.redhat-3.jar, correct?

Comment 10 baranowb 2014-08-08 06:25:07 UTC

This is a bit confusing. What is the difference? IIRC in EAP we have *-redhat-* artifacts, if so, how that 'jbossorg-3' can be turned into one and by whom ?

Comment 11 baranowb 2014-08-08 06:26:13 UTC
Ach, I just saw Davids comment in upstream, ignore c#10.

Comment 12 Matous Jobanek 2014-08-08 10:42:53 UTC
yes, I used the jsf-impl-2.1.28-jbossorg-3.jar
However, I used the standard standalone configuration of EAP (ie. standalone.xml), not the clustered one.

Comment 15 Matous Jobanek 2014-08-11 08:12:58 UTC
after another investigation I've found out, that when I was testing the patched jsf module there was used same sessionId as during the testing of the original(unpatched) jsf module. The result was, that the issue seemed not to be fixed, because there was still used the wrong Map(from the older session). Sorry for my confusions.

Comment 16 Farah Juma 2014-08-11 13:42:33 UTC
That's good to know. Thanks for the update, Matous.

Comment 17 Matous Jobanek 2014-08-11 14:33:38 UTC
You are welcome. However, we have found out that this issue:
is the same problem. The suspicion concerning org.jboss.weld.context.ConversationContext.conversations has been mentioned in the first comment. So, this patch is not sufficient and the patch for Weld should be included as well. I will attach server log and reproducer, which is slightly modified example provided by the customer.

Comment 18 Matous Jobanek 2014-08-11 14:39:55 UTC
Created attachment 925802 [details]
Server log connected to the conversation issue

Comment 19 Farah Juma 2014-08-11 14:41:33 UTC
Since that's a Weld bug, please create a separate BZ issue for that. Shay had previously created this one:


Comment 20 Matous Jobanek 2014-08-11 14:52:12 UTC
Created attachment 925808 [details]
Reproducer for the conversation issue

How to reproduce:
1. build the test-red-hat-conversations example
2. deploy test-red-hat-web.war
3. access the page
4. pres F5 and wait

Comment 21 Farah Juma 2014-08-11 15:29:54 UTC
Matous, please attach the reproducer and steps to reproduce the Weld issue to this BZ:



Comment 22 baranowb 2014-08-12 07:54:47 UTC
In other words - this is not fixed at this moment? What needs to be done to make it vanish?

Comment 23 Farah Juma 2014-08-12 13:43:30 UTC
The ConcurrentModificationException that was occurring because of non-thread-safe JSF HashMaps has been resolved. All that remains is a Weld fix (bug 1128819) to make sure the invalidation of expired conversations is also synchronized.

Comment 26 Matous Jobanek 2014-08-28 13:25:34 UTC
Verified in EAP 6.3.1.CP.CR1

Note You need to log in before you can comment on or make changes to this bug.