Bug 1105280
| Summary: | [GSS] (6.3.1) ConcurrentModificationException due to non thread safe JSF HashMaps | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Shay Matasaro <smatasar> | ||||||||
| Component: | JSF | Assignee: | Farah Juma <fjuma> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Matous Jobanek <mjobanek> | ||||||||
| Severity: | unspecified | Docs Contact: | Russell Dickenson <rdickens> | ||||||||
| Priority: | unspecified | ||||||||||
| Version: | 6.2.0 | CC: | bbaranow, dereed, fjuma, mjobanek, myarboro, rsvoboda, ssilvert | ||||||||
| Target Milestone: | CR1 | Keywords: | Triaged | ||||||||
| Target Release: | EAP 6.3.1 | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | |||||||||||
| : | 1117365 (view as bug list) | Environment: | |||||||||
| Last Closed: | 2014-10-13 18:36:37 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | 1117365 | ||||||||||
| Bug Blocks: | 1102082, 1118035 | ||||||||||
| Attachments: |
|
||||||||||
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. 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. 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). 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 Adding to the EAP 6.3.1 (CP01) Blockers Tracker per Farah's request. 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. Hi, 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 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? jsf-impl-2.1.28-jbossorg-3.jar vs jsf-impl-2.1.28.redhat-3.jar 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 ? Ach, I just saw Davids comment in upstream, ignore c#10. Farah, 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. Farah, 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. That's good to know. Thanks for the update, Matous. You are welcome. However, we have found out that this issue: https://issues.jboss.org/browse/WELD-1623 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. Created attachment 925802 [details]
Server log connected to the conversation issue
Since that's a Weld bug, please create a separate BZ issue for that. Shay had previously created this one: https://bugzilla.redhat.com/show_bug.cgi?id=1106500 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
Matous, please attach the reproducer and steps to reproduce the Weld issue to this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1128819 Thanks. In other words - this is not fixed at this moment? What needs to be done to make it vanish? 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. Verified in EAP 6.3.1.CP.CR1 |
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 : 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