https://bz.apache.org/bugzilla/show_bug.cgi?id=59220
Violeta Georgieva <violet...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS| |All
--- Comment #1 from Violeta Georgieva <violet...@apache.org> ---
Hi,
Based on the example that you've provided I can say that you are in so called
"error dispatch" situation i.e.
"2.3.3.3 Asynchronous processing
- If none of the listeners called AsyncContext.complete or any of the
AsyncContext.dispatch methods, then perform an error dispatch with a
status code equal to HttpServletResponse.SC_INTERNAL_SERVER_ERROR
and make the Throwable available as the value of the
RequestDispatcher.ERROR_EXCEPTION request attribute.
- If no matching error page is found, or the error page does not call
AsyncContext.complete() or any of the AsyncContext.dispatch methods,
then the container MUST call AsyncContext.complete."
So when you do not perform flush the response is not committed and
org.apache.catalina.valves.ErrorReportValve.invoke(...) handles the situation
correctly and onComplete is called, but when you perform flush,
ErrorReportValve will mark the connection to be closed as the response is
committed and onComplete will not be invoked.
I'm thinking about whether we should delay this, but I would like to hear the
other committers' opinion.
For your use case my recommendation is to call AsyncContext.complete in your
listener and not to wait the container to call it for you.
Regards,
Violeta
--
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
