tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marko Asplund <marko.aspl...@gmail.com>
Subject Re: Servlet 3.1 asynchronous processing API
Date Wed, 09 Jul 2014 15:53:38 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message