Bug 57252 - Custom error page is not used for an error that occurs asynchronously
Summary: Custom error page is not used for an error that occurs asynchronously
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 7.0.57
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2014-11-24 15:00 UTC by Andy Wilkinson
Modified: 2014-12-05 11:46 UTC (History)
0 users

Small app to reproduce the problem (3.42 KB, application/octet-stream)
2014-11-24 15:00 UTC, Andy Wilkinson

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Wilkinson 2014-11-24 15:00:26 UTC
Created attachment 32224 [details]
Small app to reproduce the problem

If an error is sent as part of some asynchronous processing, for example:

@WebServlet(value = "/async", asyncSupported=true)
public class AsyncServlet extends HttpServlet {
	protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		final AsyncContext context = request.startAsync();
		context.start(new Runnable() {
			public void run() {
				try {
				} catch (IOException e) {

Tomcat 7.0.57 renders its default error page rather than the configured custom error page. The same behaviour is also exhibited in recent 8.0.x releases. It's perhaps worth noting that Tomcat 7.0.55 renders an entirely blank page in this scenario.

My expectation is that the custom error page is used and, FWIW, this is what Jetty does.

I have attached a war that can be used to reproduce the problem. /sync can be used to confirm that the custom error page is working. /async will reproduce the problem described above.
Comment 1 Mark Thomas 2014-12-02 15:07:42 UTC
FYI. I am currently working on this but my test cases have identified a further concurrency issue with the error handling that I am going to have to fix first.
Comment 2 Mark Thomas 2014-12-04 13:35:05 UTC
Proposed fix:

I'll commit this once the svn server returns to read/write
Comment 3 Mark Thomas 2014-12-05 11:46:16 UTC
Test case created and fix applied to trunk, 8.0.x (for 8.0.16) and 7.0.x for (7.0.58).