On 10/05/17 20:50, Violeta Georgieva wrote: > Hi, > > 2017-05-02 12:54 GMT+03:00 Violeta Georgieva <miles...@gmail.com>: >> >> >> 2017-05-02 12:25 GMT+03:00 Mark Thomas <ma...@apache.org>: >>> >>> On 02/05/17 09:52, Violeta Georgieva wrote: >>>> Hi, >>>> >>>> I have a question about Async state DISPATCHING. >>>> >>>> I have the following scenario >>>> - Application invokes startAsync() and then continues processing in a >>>> separate non-container thread A. >>>> - At some point thread A makes dispatch() -> Async state is changed to >>>> DISPATCHING >>>> - At the same time a socket error occurs and thread B tries to change > the >>>> Async state to ERROR, as the state was already changed to > DISPATCHING, the >>>> exception below occurs and the state cannot be changed to ERROR. >>>> >>>> Isn't that a problem as onError event will not be called? >>>> Why don't we treat DISPATCHING as DISPATCHED in asyncError? >>>> > https://github.com/apache/tomcat/blob/trunk/java/org/apache/coyote/AsyncStateMachine.java#L388 >>> >>> It depends. (Async errors and threading issues have been a topic of >>> discussion in the Servlet EG recently.) >>> >>> Could you explain a little more about what triggers this? >>> >>> My initial thoughts are that the socket error should be visible to the >>> application and therefore the application should not call dispatch. >> >> In the described scenario above yes it sees the socket error but even > though it calls dispatch. >> Don’t we need to ensure onError is called so that if there are libraries > in between (not only server and application) they will receive onError > event? > > What do you think? Is this an issue that requires a fix?
I'm leaning towards thinking this is an application bug. If the application has two non-container threads, A and B, then, as per section 2.3.3.4 of the Servlet spec, the application is responsible for accessing the request from those threads in a thread-safe manner. In the scenario above, thread A should only call dispatch once the I/O activity in thread B has completed. Alternatively, once thread A has called dispatch, thread B should not be performing any I/O. Mark > > Thanks, > Violeta > >> >> >>> Mark >>> >>> >>>> >>>> Thanks, >>>> Violeta >>>> >>>> org.apache.catalina.connector.CoyoteAdapter.asyncDispatch Exception > while >>>> processing an asynchronous request >>>> >>>> java.lang.IllegalStateException: Calling [asyncError()] is not valid > for a >>>> request with Async state [DISPATCHING] >>>> >>>> at >>>> > org.apache.coyote.AsyncStateMachine.asyncError(AsyncStateMachine.java:398) >>>> >>>> at > org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:393) >>>> >>>> at org.apache.coyote.Request.action(Request.java:390) >>>> >>>> at >>>> > org.apache.catalina.core.AsyncContextImpl.setErrorState(AsyncContextImpl.java:385) >>>> >>>> at >>>> > org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:175) >>>> >>>> at > org.apache.coyote.AbstractProcessor.dispatch(AbstractProcessor.java:225) >>>> >>>> at >>>> > org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53) >>>> >>>> at >>>> > org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:796) >>>> >>>> at >>>> > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1366) >>>> >>>> at >>>> > org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) >>>> >>>> at >>>> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>>> >>>> at >>>> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> >>>> at >>>> > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) >>>> >>>> at java.lang.Thread.run(Thread.java:745) >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
