Bug 900697 (JBPAPP6-1009)
| Summary: | CLONE - Weld - Long running producer called multiple times in the same context | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Marek Schmidt <maschmid> | ||||||
| Component: | unspecified | Assignee: | Shelly McGowan <smcgowan> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 6.0.0 | CC: | ales.justin, maschmid, rajesh.rajasekaran, rsvoboda, sgilda, smcgowan, twells | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | EAP 6.0.1 | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| URL: | http://jira.jboss.org/jira/browse/JBPAPP6-1009 | ||||||||
| Whiteboard: | eap601candidate | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: |
JBoss AS 7.1.2.Final (EAP 6.0.0)
|
|||||||
| Last Closed: | 2013-07-18 13:35:27 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: | |||||||||
| Attachments: |
|
||||||||
Link: Added: This issue Cloned from WELD-1155 Security: Added: Public Docs QE Status: Added: NEW Labels: Removed: backport_weld1x Labels: Added: eap601candidate Stuart can you have a look? I believe this one has been fixed upstream in 2.0 and needs to be backported: https://github.com/weld/core/commit/50cf1d8fedf23275404b67950bf10cb848f2d865 The upstream issue seem to be fixed. Assigning to Shelly to accordingly set the fix version and make sure the upstream fixes are pulled in. While the upstream issue is not listed as Fixed In version 1.1.9.Final, I have verified it is in the commit list for that release which is included in EAP 6.0.1. Pls verify on the latest ER release available. Verified on EAP 6.0.1.ER2 Does this need a release note for EAP 6.0.1? If so, the issue needs to be re-opened and the release notes flags set (Affects Release Notes, Not Yet Documented). If not, the issue needs to be re-opened and the release notes flag set to "Release notes not required". reopening for RN Release Notes Docs Status: Added: Not Yet Documented Affects: Added: Release Notes Release Notes Text: Added: SessionScoped Producers were called multiple times in the same session if a second request in the same session comes before the first producer finishes. reopening for release notes updates Writer: Added: elogue Writer: Removed: elogue Added: tomwells Release Notes Docs Status: Removed: Not Yet Documented Added: Needs More Info Hey Marek, Could you summarize the changes made that fixed this issue for the release notes? Thanks. The fix is https://github.com/weld/core/commit/d92b345c58da3e7b8718f5cc3c00b04d2958f18a The AbstractSessionBeanStore incorrectly assumed that the underlying HttpSession attributes cannot change. When there are two concurrent requests in the same session that cause a session-scoped instance to be produced, the AbstractContext creation lock correctly blocked the second request from calling the producer a second time, but then a check, that was supposed to tell if an instance have already been produced while waiting on the creation lock, failed, due to the erroneous assumption in the AbstractSessionBeanStore. This caused the producer to be called the second time. AbstractSessionBeanStore has now been fixed to look inside the HttpSession attributes if an instance cannot be found in the thread-local store. Thanks Marek. Release Notes Docs Status: Removed: Needs More Info Added: Documented as Resolved Issue Release Notes Text: Removed: SessionScoped Producers were called multiple times in the same session if a second request in the same session comes before the first producer finishes. Added: The AbstractSessionBeanStore incorrectly assumed that the underlying HttpSession attributes couldn't change. When there were two concurrent requests in the same session that caused a session-scoped instance to be produced, the AbstractContext creation lock correctly blocked the second request from calling the producer a second time. However, a check that was supposed to tell if an instance had already been produced while waiting on the creation lock would fail because of the erroneous assumption in the AbstractSessionBeanStore. This caused the producer to be called a second time. AbstractSessionBeanStore has now been fixed to look inside the HttpSession attributes if an instance cannot be found in the thread-local store. Release Notes Docs Status: Removed: Documented as Resolved Issue Writer: Removed: tomwells Release Notes Text: Removed: The AbstractSessionBeanStore incorrectly assumed that the underlying HttpSession attributes couldn't change. When there were two concurrent requests in the same session that caused a session-scoped instance to be produced, the AbstractContext creation lock correctly blocked the second request from calling the producer a second time. However, a check that was supposed to tell if an instance had already been produced while waiting on the creation lock would fail because of the erroneous assumption in the AbstractSessionBeanStore. This caused the producer to be called a second time. AbstractSessionBeanStore has now been fixed to look inside the HttpSession attributes if an instance cannot be found in the thread-local store. Docs QE Status: Removed: NEW Verified on EAP 6.0.1.ER2 |
Affects: Release Notes project_key: JBPAPP6 SessionScoped Producers are called multiple times in the same session if a second request in the same session comes before the first one finishes. The first request is thus processed with an outdated instance, as it will be replaced by the produce of the other request. {code} public class ShoppingCartProducer { private static AtomicInteger ai = new AtomicInteger(); @Produces @SessionScoped public ShoppingCart getShoppingCart() { System.out.println("getShoppingCart producer"); try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } return new ShoppingCart("cart" + ai.incrementAndGet()); } } {code}