Support for the Servlet Async API

[mdeinum]

Currently Spring WS only leverages the regular Servlet API with blocking the request handling thread. This could be improved by also allowing support for the async features of the Servlet API. Maybe parts of the async support in Spring MVC can be leveraged for this.

[snicoll]

I don't know how involved that would be but I'd rather move Spring-WS higher in the stack and make it a better citizen of Spring MVC. @rstoyanchev mentioned that this should be doable so we need to find quality time to investigate what to do.

[mdeinum]

It would probably involve copying/reusing some parts of the Async processing that is available in the DispatcherServlet.

There is a reason that the MessageDispatcherServlet is the way it is (or that it even exists). I don't recall the exact reason but I do remember that @poutsma did a presentation on this years ago (probably during the inception of Spring WS). So maybe he has some recollection and tips for this.

[rstoyanchev]

Spring WS contracts are blocking. We created WebFlux alongside to Spring MVC for similar reasons, but we're not going as far here. The Servlet API is also blocking, but it enables async handling through over imperative contracts by using multiple dispatches (initial REQUEST vs subsequent ASYNC). We can't do the same in Spring WS since the Servlet API is transport level only, and there is no concept of multiple dispatches.

This unfortunately means that annotated handler methods themselves cannot do async handling (e.g. return Future, Mono). That said, MessageDispatcher could allow async handling by offloading the dispatch to an Executor thread, and using the Servlet API async support to complete when ready. This is something that could be configured centrally on MessageDispatcher, or possibly by checking hints on annotated handler methods, and deciding independently for each request whether to handle async or not.

I'm not sure there is a need to copy much of anything from Spring MVC, but we may borrow some of our experience with protecting concurrent use of the response, e.g. in case of a request timeout, disconnected clients, etc.