https://bz.apache.org/bugzilla/show_bug.cgi?id=67235
--- Comment #4 from Han Li <li...@apache.org> --- It can be reproduced. From my debug observations, it turns out that it's ultimately due to the change of `org.apache.coyote.AsyncStateMachine#asyncError` (Maybe not final reason). Since I'm not very familiar with this area, I'll try to be as descriptive as possible :) Abnormal behavior: 10.1.11: execute `decreaseInProgressAsyncCount` first, then execute `recycle` 10.1.12: becomes `recycle` first, then execute `decreaseInProgressAsyncCount`. 1. When writing after 5s, an IO exception is encountered because the connection is broken. So you end up changing the state to ERROR at org.apache.coyote.AbstractProcessor#setErrorState:122 line, which is normal I think and which is first time to set state. 2.An scoket ERROR event is then generated after 1) and process it asynchronously. The final execution reaches org.apache.catalina.core.AsyncContextImpl#setErrorState: 393 line to notify the listener that an exception exists. At this point, there is a listener `StandardServletAsyncWebRequest`. This listener will eventually execute to ` org.apache.coyote.AsyncStateMachine#asyncDispatch` where will set state to DISPATCHING. 3.The process continues, and then it goes to org.apache.coyote.AsyncStateMachine#asyncError. This is the problem. 10.1.11 eventually set state to ERROR, but 10.1.12 there ensure the error processing is only started once per generation, the state is still DISPATCHING. Hope the analysis is right ;) -- 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
