Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1070069

Summary: [GSS] (6.3.0) Timed out conversation unexpectedly alive on next request
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Takayoshi Kimura <tkimura>
Component: CDI/WeldAssignee: Jozef Hartinger <jharting>
Status: CLOSED CURRENTRELEASE QA Contact: Ron Šmeral <rsmeral>
Severity: unspecified Docs Contact: Russell Dickenson <rdickens>
Priority: unspecified    
Version: 6.1.0, 6.2.0, 6.1.1, 6.2.1, 6.2.2CC: amelicha, cdewolf, jawilson, kkhan, ksato, pmuir, rsvoboda, smumford
Target Milestone: ER4   
Target Release: EAP 6.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
In previous versions of JBoss EAP 6 it was found that a conversation could be unexpectedly activated and associated with a request even after the conversation expires, resulting in a `NonExistentConversationException`. This was because, in a JSF application, Weld did not properly check conversation state at the beginning of requests. This release of the product includes an updated conversation context activation and invalidation procedure to check conversation state more thoroughly. As a result, expired conversations no longer get mistakenly associated with requests.
 Story Points: ---
Clone Of:
: 1088791 (view as bug list) Environment:
Last Closed: 2014-06-28 15:40:15 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:    
Bug Blocks: 1088791, 1089990    

Description Takayoshi Kimura 2014-02-26 08:10:25 UTC 
In JSF app, Weld only checks conversation timeout at the RENDER_RESPONSE phase or respose complete. It doesn't check the conversation at the beginning of requests.

Upstream JIRA is:

Conversation timeout in redirect
https://issues.jboss.org/browse/WELD-1452
Comment 2 Kabir Khan 2014-04-25 15:14:38 UTC 
Moving to ER4 since ER3 is the new beta candidate, and is ER2+beta blockers only
Comment 3 Ron Šmeral 2014-05-14 12:51:06 UTC 
Verified in EAP 6.3.0.ER4.