Bug 1103891

Summary: [GSS] (6.2.x) NIO can improperly lead to request/response objects being used concurrently
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Aaron Ogburn <aogburn>
Component: WebAssignee: Aaron Ogburn <aogburn>
Status: CLOSED CURRENTRELEASE QA Contact: Radim Hatlapatka <rhatlapa>
Severity: unspecified Docs Contact: Russell Dickenson <rdickens>
Priority: unspecified    
Version: 6.2.0, 6.2.1, 6.2.2, 6.2.3CC: aogburn, cdewolf, mhasko, smumford, vtunka
Target Milestone: CR1   
Target Release: EAP 6.2.4   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
In previous versions of JBoss EAP 6, using NIO with async servlets could improperly lead to a processor and its request/response objects being used by multiple threads to process different requests at once. This issue would present if two events occurred on the same channel and executed `Http11NioProtocol.event()` at the same time. If they result in a `SocketState` other than LONG, both offered the same processor to `recycledProcessors` in the finally block. This would then allow two different requests to poll the same processor at once from `reycledProcessors`. This behavior was incorrect as a processor should only ever have one entry in `recycledProcessors`. To fix this, the "Http11NioProtocol.event()" call was wrapped in a synchronized block. So the issue is avoided as a single processor is no longer inserted multiple times into the recycledProcessors queue.
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-07 12:13:17 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: 1090103    
Bug Blocks: 1067534, 1103808    

Description Aaron Ogburn 2014-06-02 19:38:38 UTC
Description of problem:

Using NIO with async servlets can improperly lead to a processor and its request/response objects being used by multiple threads to process different requests at once. The problem arises in Http11NioProtocol.event().

If two events occur on the same channel and execute this at the same time, it'll lead to this issue if they result in a SocketState other than LONG. When that happens, they both offer the same processor to recycledProcessors in the finally block. Later on, two different requests can then poll the same processor at once from reycledProcessors; a processor should only ever have one entry in recycledProcessors.

It looks like we need to synch the Http11NioProtocol.event() call or the NioEndpoint.ChannelProcessor.run().

Version-Release number of selected component (if applicable):

7.3.1.Final

Comment 1 Aaron Ogburn 2014-06-02 19:41:21 UTC
Fixed in JBossWeb 7.3.x branch for EAP 6.2.x by r2437.

Comment 2 Michal Haško 2014-06-23 15:26:00 UTC
VERIFIED on 6.2.4.CP.CR1

Comment 3 Scott Mumford 2014-06-23 22:39:06 UTC
Started a draft Release Note based on the description but more information is needed to complete it.

Aaron, can you tell me which of the options you mention above became the eventual fix?

Comment 4 Aaron Ogburn 2014-07-07 13:17:37 UTC
To fix this, the "Http11NioProtocol.event()" call was wrapped in a synchronized block.  So the issue is avoided as a single processor is no longer inserted multiple times into the recycledProcessors queue.