[jboss-jira] [JBoss JIRA] (JBWEB-297) NIO can improperly lead to request/response objects being used concurrently

[RH Bugzilla Integration (JIRA)]

    [ https://issues.jboss.org/browse/JBWEB-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12964976#comment-12964976 ] 

RH Bugzilla Integration commented on JBWEB-297:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1090103|https://bugzilla.redhat.com/show_bug.cgi?id=1090103] from MODIFIED to ON_QA

> NIO can improperly lead to request/response objects being used concurrently
> ---------------------------------------------------------------------------
>
>                 Key: JBWEB-297
>                 URL: https://issues.jboss.org/browse/JBWEB-297
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.2.2.GA, JBossWeb-7.3.0.GA, JBossWeb-7.4.0.GA
>            Reporter: Aaron Ogburn
>            Assignee: Remy Maucherat
>         Attachments: JBWEB-297.diff
>
>
> 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 here in Http11NioProtocol.event():
> {code:title=Http11NioProtocol.java|borderStyle=solid}
> 		public SocketState event(NioChannel channel, SocketStatus status) {
> 			Http11NioProcessor processor = connections.get(channel.getId());
> 			SocketState state = SocketState.CLOSED;
> 			if (processor != null) {
> 				processor.startProcessing();
> 				// Call the appropriate event
> 				try {
> 					state = processor.event(status);
> 				} catch (java.net.SocketException e) {
> 					// SocketExceptions are normal
> 				    CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> 				} catch (java.io.IOException e) {
> 					// IOExceptions are normal
>                     CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> 				}
> 				// Future developers: if you discover any other
> 				// rare-but-nonfatal exceptions, catch them here, and log as
> 				// above.
> 				catch (Throwable e) {
> 					// any other exception or error is odd. Here we log it
> 					// with "ERROR" level, so it will show up even on
> 					// less-than-verbose logs.
>                     CoyoteLogger.HTTP_NIO_LOGGER.socketError(e);
> 				} finally {
> 					if (state != SocketState.LONG) {
> 						connections.remove(channel.getId());
> 						recycledProcessors.offer(processor);
> {code}
> 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().



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)