Very clear explanation about Timeouts, great!

However, a naïve question Rossen: what happens if I set a timeout value on server-side which exceeds the HTTP connection default timeout ?
In other sense, what if the underlying TCP connexion expired before the tmeout in AsyncContext is reached ? Will the container be notified of such expiration ? Will the AsyncContext (and its listeners) be notified ? In this case, what will the client see ? A classical HTTP 408 timeout or the result of the timeout management by my AsyncListener (if any) ?

Hi Rossen,

Thanks for a great post. I've start playing with the new async support and it seems to work well in most cases. However, when my callable is resolving a view, I'm getting a DispatcherServlet exception.

Testing is out with the examples in the spring-mvc-async branch, I noticed the same (http://localhost:8080/spring-mvc-showcase/views/html). Is there specific configuration changes I need to make for view resolution to work with async?

16:58:04 [qtp4697408-12] DispatcherServlet – DispatcherServlet with name 'appServlet' processing GET request for [/spring-mvc-showcase/views/html]
16:58:04 [qtp4697408-12] RequestMappingHandlerMapping – Looking up handler method for path /views/html
16:58:04 [qtp4697408-12] RequestMappingHandlerMapping – Returning handler method [public java.util.concurrent.Callable org.springframework.samples.mvc.views.ViewsController.prepare(org.springframework.ui.Model)]
16:58:04 [qtp4697408-12] DispatcherServlet – Last-Modified value for [/spring-mvc-showcase/views/html] is: -1
16:58:04 [qtp4697408-12] DispatcherServlet – Exiting request thread and leaving the response open
16:58:04 [SimpleAsyncTaskExecutor-1] DispatcherServlet – Resuming asynchronous processing of GET request for [/spring-mvc-showcase/views/html]
16:58:07 [SimpleAsyncTaskExecutor-1] DispatcherServlet – Rendering view [org.springframework.web.servlet.view.JstlView: name 'views/html'; URL [/WEB-INF/views/views/html.jsp]] in DispatcherServlet with name 'appServlet'
16:58:07 [SimpleAsyncTaskExecutor-1] JstlView – Added model object 'fruit' of type

[/java] to request in view with name 'views/html'
16:58:07 [SimpleAsyncTaskExecutor-1] JstlView - Added model object 'foo' of type [java language=".lang.String"]

to request in view with name 'views/html'
16:58:07 [SimpleAsyncTaskExecutor-1] DispatcherServlet – Could not complete request
javax.servlet.ServletException: Could not get RequestDispatcher for [/WEB-INF/views/views/html.jsp]: Check that the corresponding file exists within your web application archive!
at org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:219)
at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:262)
at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1265)
at org.springframework.web.servlet.DispatcherServlet.processDispatchResult(DispatcherServlet.java:1016)
at org.springframework.web.servlet.DispatcherServlet.access$300(DispatcherServlet.java:141)
at org.springframework.web.servlet.DispatcherServlet$2.call(DispatcherServlet.java:1054)
at org.springframework.web.servlet.DispatcherServlet$1.call(DispatcherServlet.java:884)
at org.springframework.web.servlet.FrameworkServlet$1.call(FrameworkServlet.java:991)
at org.springframework.web.context.request.async.AsyncExecutionChainRunnable.run(AsyncExecutionChainRunnable.java:64)
at java.lang.Thread.run(Thread.java:722)
16:58:07 [SimpleAsyncTaskExecutor-1] AsyncExecutionChainRunnable – Completing async request processing

Rossen, thanks for the quick reply.

The problem seems specific to Jetty (I'm using the last stable Jetty 8.1.3). The same code runs fine on Glassfish v3. Also the non-async version (that returns String instead of Callable) works on both Jetty and Glassfish.

I've opened a ticket as suggested
https://jira.springsource.org/browse/SPR-9433

Interesting feature which certainly has a great use case. I just want to point a simple wrong spelling:

"The idea is that all of what you already know about how a controller method works remains unchanged as much as possibble…"

The word possibble has two "b"s

please change the org.springframework.http.converter.StringHttpMessageConverter#public static final Charset DEFAULT_CHARSET = Charset.forName("ISO-8859-1") to UTF-8!thanks

Oops bad copy/paste… i use that now.

Great… i found what i need thks
https://fisheye.springsource.org/browse/spring-framework/spring-web/src/main/java/org/springframework/web/context/request/async/DeferredResult.java?hb=true

@RequestMapping(value = "/test", method = RequestMethod.GET)
public ResponseEntity test()
{
HttpHeaders headers = new HttpHeaders();
headers.setContentType(MediaType.TEXT_PLAIN);
return new ResponseEntity("Hi There!!", headers, HttpStatus.OK);
}

works fine. But when I add Callable interface

@RequestMapping(value = "/test", method = RequestMethod.GET)
public Callable<ResponseEntity> test()
{
return new Callable<ResponseEntity>()
{
@Override
public ResponseEntity call() throws Exception
{
Thread.sleep(10000);
HttpHeaders headers = new HttpHeaders();
headers.setContentType(MediaType.TEXT_PLAIN);
return new ResponseEntity("Hi There!!", headers, HttpStatus.OK);
}
};
}

I get HTTP Status 404 – WARN PageNotFound:1080 – No mapping found for HTTP request with URI [xxxxx] in DispatcherServlet with name 'dispatcher'

Hello Rossen,

Great post. I use Spring 3 mvc in many controllers and the methods all return ModelAndView objects with a ContentNegotiatingView resolver setup. I don't see any examples with this scenario. Does the new 3.2 M2 async support cover this type of setup or should we move off returning ModelAndView's in our controllers for something else? Thanks in advance.

I got HTTP 404 too
No mapping found for HTTP request

Hello Rossen,

I was looking at the samples you pointed me at and I decided to do some playing around. I have the following piece of code that is not too different from your sample.

@RequestMapping(value = "/**")
public Callable defaultMethod() {

return new Callable() {
@Override
public String call() throws Exception {
System.out.println("**************ERROR**************");
throw new UnsupportedOperationException(
"Bad Request. The service is not supported.");
}
};

}

I noticed that in the dispatcher servlet the dispatch exception is never set and thus when processDispatchResult is subsequently called the UnsupportedOperationException never makes it to a custom HandlerExceptionResolver that I have added to the application context. Am I doing something wrong here or am I supposed to handle exceptions thrown in the Callable some other way when using a custom HandlerExceptionResolver?

How do you return custom http headers? Following REST principles, you'd return a Location Header with the FUTURE url for client to poll the status of the Resource so that eventually, it would get a more permanent URL (Request-Acknowledge-Poll pattern).

Neither returning Callable or MVCAsyncTask support customizing the a HTTPResponse.

Hi Rossen,
I find this article very informative. thank you for the post. I was wondering if there's a design pattern that you can suggest as to how to implement the base class for all the Controllers that will wrap the anonymous (Callable) class.

What I am trying to avoid is to have all my methods return an anonymous Callable class.

Thank you.
Don

Hey,

We're big springheads on a new REST springMVC project that is fairly greenfield, so we're trying to spin up an async architecture with elastic cloud, blah blah blah.

We've selected Jetty for maximum embeddability and speed, and because they seemed to be at the forefront of async support, for testing flexibility, and lots of other reasons. We know tomcat is also embeddable and can do this, but Jetty just seems better.

Has the springmvc async framework been thoroughly tested with various filters (like a zipping/deflation filter, or other request and response manipulation filters) in Jetty 8 and 9? We're seeing a zip filter that only seems to activate about 10-20% of the time. I'd love to provide you a nice test example, but haven't been able to produce a reliable reproduction. Such is the nature of concurrent programming.

Any ideas or suspicions? It also appears that this doesn't happen with non-springmvc servlets. Jetty8 running inside eclipse seems to be better than not in eclipse, but we're still kind of thrashing trying to trace down the problem. Jetty9 also shows the problem, but we've broken some stuff swapping dependencies so we can't say authoritatively Jetty9 is busted in the same way.

It appears s-mvc runs its own threadpool and management for async servlets independent of how the appserver is implementing servlet 3.0 (s-mvc uses a separate response threadpool, but tomcat and jetty seem to use a common threadpool for handling requests and fulfilling responses).

Hi Rossen,

Thanks. if I create an abstract class, i will end up making a lot of 1 method concrete classes that returns Callable, right?

In the example above, you have a controller that has a methods that returns an annonymous callable. I'm just trying to think, if we can encapsulate the creation of anonymous callable class, because in this example, every controller method that I want to make asynchronous, will always have a boilerplate code (anonymous Callable) inside it.

Thanks,
Don