[Bug 68037] Async Servlet implementation doesn't allow setting a response status
https://bz.apache.org/bugzilla/show_bug.cgi?id=68037
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #7 from Mark Thomas ---
There is a fundamental difference between synchronous and asynchronous for IO
error handling.
In synchronous servlets, processing is always on a container thread. When an
IOException occurs during the service method (including when thrown by
container code), the container expects to catch it and handle it outside of the
service() method. This offers an opportunity for an application to catch the
IOException inside the service() method and effectively hide it from the
container. This is what happens in this test case - hence the client sees the
408 status code.
In asynchronous servlets, processing may not be on a container thread.
Therefore if an IOException is thrown by the container it has to note this
because it will not have an opportunity to catch and handle the exception later
if on a non-container thread and the container is required to call onError().
Because the container tracks the IOException as soon as it is thrown, it is not
possible for the application to hide the exception from the container. This
means the standard handling for IOException is applied which includes disabling
all further IO on the grounds there is no point in further IO after an
IOException. Hence the client never sees the 408 status code.
The application does have a narrow gap in onError() where you can achieve a
similar result to the synchronous case. Something along the lines of:
public void onError(Throwable t) {
if (t instanceof SocketTimeoutException) {
try {
resp.setStatus(408);
resp.flushBuffer();
} catch (IOException e) {
e.printStackTrace();
}
}
req.getAsyncContext().complete();
}
The reason you need to use setStatus() is that sendError() also disables
further output (it works in the synchronous case because the container
re-enables output in the error handling but that step is skipped for
asynchronous because the container knows there has been an IOException).
It is a bit of a hack, but then so is catching and swallowing IOException in
service().
I did spend some time seeing looking at the asynchronous error handling but
couldn't see an approach I liked more than the current code.
--
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
[Bug 68037] Async Servlet implementation doesn't allow setting a response status
https://bz.apache.org/bugzilla/show_bug.cgi?id=68037 --- Comment #6 from adwsingh --- To be clear I don't expect the async and sync version to work the same way. I do however expect to be able to achieve the same result using async that I was able to do using sync. -- 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
[Bug 68037] Async Servlet implementation doesn't allow setting a response status
https://bz.apache.org/bugzilla/show_bug.cgi?id=68037 --- Comment #5 from adwsingh --- @remm is there a way to do it in a non-blocking fashion then? I want to send back a 408 on a SocketTimeoutException while reading the request. -- 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
[Bug 68037] Async Servlet implementation doesn't allow setting a response status
https://bz.apache.org/bugzilla/show_bug.cgi?id=68037 Remy Maucherat changed: What|Removed |Added Severity|blocker |normal --- Comment #4 from Remy Maucherat --- I am not sure I am seeing anything wrong. You expect regular and async to behave the same way, but that is not necessarily the case. As you noticed, there is an error processing that is needed for async, but with regular blocking IO there is no error dispatch so the request is considered "done" (= committed) after certain errors. -- 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
[Bug 68037] Async Servlet implementation doesn't allow setting a response status
https://bz.apache.org/bugzilla/show_bug.cgi?id=68037 --- Comment #3 from adwsingh --- @markt do you know why we check here [1] if its an asyncError and only then choose to process the SocketEvent? [1] https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/coyote/AbstractProcessor.java#L121 -- 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
[Bug 68037] Async Servlet implementation doesn't allow setting a response status
https://bz.apache.org/bugzilla/show_bug.cgi?id=68037 --- Comment #2 from adwsingh --- @markt do you know why we check here [1] if its an asyncError and only then choose to process the SocketEvent? [1] https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/coyote/AbstractProcessor.java#L121 -- 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
[Bug 68037] Async Servlet implementation doesn't allow setting a response status
https://bz.apache.org/bugzilla/show_bug.cgi?id=68037 adwsingh changed: What|Removed |Added CC||adwsi...@gmail.com -- 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
[Bug 68037] Async Servlet implementation doesn't allow setting a response status
https://bz.apache.org/bugzilla/show_bug.cgi?id=68037 --- Comment #1 from adwsingh --- I traced the problem to this line in AbstractProcessor : https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/coyote/AbstractProcessor.java#L121 This will not dispatch if the container thread is the one which is processing the error. But in this case it will always be the container thread which gets the SocketEvent.ERROR. -- 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
