https://issues.apache.org/bugzilla/show_bug.cgi?id=50957
--- Comment #9 from Brad Plies <bpl...@bulliondirect.com> 2011-03-28 14:44:59 EDT --- Brainstorming out loud after examining some Tomcat code... In the witnessed case of receiving ImageA.gif as ImageB.gif, this suggests that the same InternalOutputBuffer was re-used to respond to both requests. This could hypothetically be possible if the output buffer were not properly reset between requests. Http11Processor.process(socket) AbstractOutputBuffer.nextRequest() will call response.recycle() that will reset the contentType, status, headers, encoding, etc. Most of these recycling/resetting operations are guarded by !isAsync() (AsyncStateMachine) I wonder if there is a concurrency hazard surrounding isAsync()? Namely that isAsync accesses shared state and is, itself, not synchronized. So couldn't you have, due to unlucky timing, a dirty read where: isAsync() returns true but almost immediately becomes false or isAsync() returns false but almost immediately becomes true While all of the async state mutating methods are synchronized, an unsynchronized read is governing control flow of external code. It should be possible for the state to be written concurrently with the unsync read and perhaps cause an unanticipated code path to execute. Http11Processor.process(socket) calls isAsync() 4 times (swallowInput(), endRequest(), buffers.nextRequest(), & SocketState.LONG) and could all conceivably return different answers from call to call. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- 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
