You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Marko Asplund <ma...@gmail.com> on 2014/07/09 00:18:25 UTC
Servlet 3.1 asynchronous processing API
Hi,
I'm just starting out with using the Servlet 3.1 asynchronous processing
API.
I use the API for generating response content, that can potentially be a
slow process, in another thread.
The code appears to be working, but since the specification contains many
caveats, I'd like to try and verify correctness.
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?
- does the code contain thread-safety issues in particular related to the
response object and OutputStream?
Here's a simplified version of my code:
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
final AsyncContext asyncContext = req.startAsync();
asyncContext.start(new Runnable() {
@Override
public void run() {
HttpServletResponse response = null;
try {
response = (HttpServletResponse)asyncContext;
if(hasOperationFailed()) {
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
} else {
response.getOutputStream().write(generateResponseContent().getBytes());
}
} catch (IOException e) {
try {
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
} catch (IOException e1) {
e1.printStackTrace();
}
}
asyncContext.complete();
}
});
}
Any feedback and pointers would be welcome.
marko
Re: Servlet 3.1 asynchronous processing API
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Wed, Jul 9, 2014 at 1:18 AM, Marko Asplund <ma...@gmail.com>
wrote:
> Hi,
>
> I'm just starting out with using the Servlet 3.1 asynchronous processing
> API.
> I use the API for generating response content, that can potentially be a
> slow process, in another thread.
> The code appears to be working, but since the specification contains many
caveats, I'd like to try and verify correctness.
>
> 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?
> - does the code contain thread-safety issues in particular related to the
> response object and OutputStream?
>
> Here's a simplified version of my code:
>
> @Override
> protected void doGet(HttpServletRequest req, HttpServletResponse resp)
> throws ServletException, IOException {
> final AsyncContext asyncContext = req.startAsync();
> asyncContext.start(new Runnable() {
> @Override
> public void run() {
> HttpServletResponse response = null;
> try {
> response = (HttpServletResponse)asyncContext;
>
Maybe it is implementation detail that this cast works but usually you have
to use
http://docs.oracle.com/javaee/6/api/javax/servlet/AsyncContext.html#getResponse()
to get the response
> if(hasOperationFailed()) {
>
> response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
> } else {
>
> response.getOutputStream().write(generateResponseContent().getBytes());
> }
> } catch (IOException e) {
> try {
>
> response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
> } catch (IOException e1) {
> e1.printStackTrace();
> }
> }
> asyncContext.complete();
> }
> });
> }
>
> Any feedback and pointers would be welcome.
>
>
> marko
>
Re: Servlet 3.1 asynchronous processing API
Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Jul 9, 2014 at 12:48 PM, Marko Asplund <ma...@gmail.com>
wrote:
> On Wed, 09 Jul 2014 07:23 Martin Grigorov wrote:
>
> > > ...
> > > try {
> > > response = (HttpServletResponse)asyncContext;
> > >
> >
> > Maybe it is implementation detail that this cast works but usually you
> have
> > to use
> >
>
> http://docs.oracle.com/javaee/6/api/javax/servlet/AsyncContext.html#getResponse()
> > to get the response
>
> This was one of the things I was wondering about: calling
> AsyncContext#getResponse() returns a ServletResponse instance that doesn't
> implement the HTTP protocol specific sendError etc. methods.
>
Casting ServletResponse to HttpServletResponse is OK most of the time. You
can check with "instanceof" before doing the cast.
But casting AsyncContext to HttpServletResponse is way too brave.
>
> What would be the correct way to return an error response (including HTTP
> status code) to the client in this case?
>
>
> marko
>
Re: Servlet 3.1 asynchronous processing API
Posted by Marko Asplund <ma...@gmail.com>.
On Wed, 09 Jul 2014 07:23 Martin Grigorov wrote:
> > ...
> > try {
> > response = (HttpServletResponse)asyncContext;
> >
>
> Maybe it is implementation detail that this cast works but usually you
have
> to use
>
http://docs.oracle.com/javaee/6/api/javax/servlet/AsyncContext.html#getResponse()
> to get the response
This was one of the things I was wondering about: calling
AsyncContext#getResponse() returns a ServletResponse instance that doesn't
implement the HTTP protocol specific sendError etc. methods.
What would be the correct way to return an error response (including HTTP
status code) to the client in this case?
marko
Re: Servlet 3.1 asynchronous processing API
Posted by Mark Thomas <ma...@apache.org>.
On 08/07/2014 23:18, Marko Asplund wrote:
> Hi,
>
> I'm just starting out with using the Servlet 3.1 asynchronous processing
> API.
> I use the API for generating response content, that can potentially be a
> slow process, in another thread.
> The code appears to be working, but since the specification contains many
> caveats, I'd like to try and verify correctness.
>
> 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.
> - 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org