On 09/07/2014 16:53, Marko Asplund wrote: > 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?
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? I don;t see any. The basic rule is make sure that the application thread doesn't modify any container provided object (request, response, outputstream etc.) after you have called complete(). That is the point where control returns to the container. Mark > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
