On 09/07/2014 09:16, Mark Thomas wrote: > > There's a couple of parts in particular that I'm wondering about: > > - what's the correct way to deliver error response to client? Can I just > > cast the response acquired from AsyncContext to HttpServletResponse and use > > the normal Servlet API mechanisms? > > Personally, I'd do a dispatch since that completes the AsyncContext as > well. Your approach should work. Which is better is probably a matter of > style.
Thanks Mark! Dispatching to a separate error handler might be the cleaner approach. I guess that would involve passing error status and other info as needed to the dispatch target in the request object. So, with the response.sendError approach I would still need to finally invoke asyncContext.complete() in order to complete request processing, right? > > - does the code contain thread-safety issues in particular related to the > > response object and OutputStream? > > Ensuring thread-safe access of those objects is entirely an application > responsibility. Are there any potential thread-safety issues in the sample code related to how the application and container threads share the response object? For example if the application touches HttpServletResponse headers, status code or OutputStream, then invokes AsyncContext#complete(), can this result in thread-safety issues with the container thread when the container serializes the response to the client? As an aside, from an application developer point of view, the JAX-RS 2 way of completing asynchronous request processing in both happy path and erroneous scenarios with AsyncResponse#resume() seems quite handy. I realize that these are different abstraction levels and that Servlet API doesn't e.g. include exception mapper concept. marko
