2014-06-17 17:08 GMT+04:00 Mark Thomas <ma...@apache.org>: > On 17/06/2014 00:50, Konstantin Kolinko wrote: >> 2014-06-14 0:21 GMT+04:00 <ma...@apache.org>: >>> Author: markt >>> Date: Fri Jun 13 20:21:32 2014 >>> New Revision: 1602510 > > <snip/> > >> 3) In case if there are several executor threads that process the >> socket at the same time, what happens? >> >> My understanding/answer is that "synchronized (socket)" in >> NioEndpoint$SocketProcessor.run() handles that. > > Correct. You don't want multiple threads trying to read from the socket > at the same time. Neither do you want multiple threads trying to writ to > the socket at the same time. One thread reading and one thread writing > is OK. > >> In this case I see that NioEndpoint$SocketProcessor.doRun() does >> "nioChannels.offer(socket)" >> That is it offers the "socket" for reuse. >> >> Thus "synchronized (socket)" is broken, as the "socket" can be >> recycled and reused by another thread while the second one waits to >> obtain the monitor on the "socket". > > In theory yes. In practise, I don't believe that this will happen. > > The syncs were added as part of the Servlet 3.0 async processing > implementation. The case they were trying to deal with was: > a) app on container thread starts async processing > b) app passes control to app thread > c) container thread is returned to container for reuse > (update state, does a little clean up before it is reused) > d) app thread completes the async processing > e) control returns to container thread to complete the request > > There was a chance that e) could complete before c) and that caused all > sorts of confusion. The syncs ensure c) completes before e) starts. > > For the problem you describe to occur a fatal I/O error would have to > occur during c) after e) had reached the sync. Since there should be no > I/O during c) I don't think this can happen. > > If you have a scenario where you think this is an issue, please share it.
I suspect that the following scenario might happen: a),b),c) the same as above d) App thread performs I/O and an error happens (e.g. in 'COMMIT' or 'ACK' case in AbstractHttp11Processor.action()) e) AbstractProcessor.setErrorState() dispatches SocketStatus.CLOSE_NOW f) App thread calls async.complete() or async.dispatch() g) AbstractHttp11Processor.action() dispatches SocketStatus.OPEN_READ How the race between e) and g) is resolved? Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
