https://issues.apache.org/bugzilla/show_bug.cgi?id=57340
Bug ID: 57340
Summary: NioConnector caches get corrupted on concurrent comet
close
Product: Tomcat 7
Version: 7.0.47
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Connectors
Assignee: dev@tomcat.apache.org
Reporter: zyuly...@devexperts.com
Configuration:
Tomcat 7.0.47 NioConnector, nginx 1.6.2, atmosphere 2.2.3.
It happens when nginx and atmosphere close the same comet connection
concurrently.
In NioEndpoint.Poller thread(A) the SocketChannel becomes ready for read when
nginx closes it. Poller unregisters the channel for read and forks another
thread(B) to handle close event. (see NioEndpoint:1239)
Then atmosphere calls close on the connection in thread(C) and Tomcat receives
internal action with code ActionCode.COMET_CLOSE and adds the channel to the
Poller, which registers it for read again. (see Http11NioProcessor.java:462).
The SocketChannel is still readable in case thread(B) hasn’t invalidated the
SelectionKey yet, so Poller in thread(A) initiates the closing process again
and forks thread(D).
Thread(B) completes the closing process and puts NioChannel and AttachmentKey
into the corresponding caches.
Then Thread(D) tries to close the channel again and realizes that it has
already been closed (see AbstractProtocol.java:564) and puts the same
NioChannel and AttachmentKey into caches.
Caches become corrupted because they contain 2 references to the same object.
Then any 2 subsequent requests may get the same NioChannel and AttachmentKey
and some crazy stuff may happen (mixed up responses, etc).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
