[docs] Document threading model in Spring WebFlux [SPR-16538]

[spring-projects-issues]

Brian Clozel opened SPR-16538 and commented

Because the Spring team is communicating about the pros/cons of the async, non-blocking runtime model, developers are paying more attention to available threads in their WebFlux applications.

Here is an example of a StackOverflow question about this theme.

Per my comment on that question, I don't think we can document everything here, since we rely on the underlying web server, datastore drivers, and much more (and all of those might depend on the operating system). Developers can also apply scheduling operators on the pipeline, which will change the picture when looking at application threads.

Currently, libraries like Reactor and Reactor Netty don't document this in details.

On the other hand, our reference documentation could have a few pointers and explain:

• the general threading model and how libraries, choice of operators and operating systems can change the picture
• that one should not use block or subscribe operators within WebFlux Controllers
• how publishOn and subscribeOn operators should be used with great care

---

Affects: 5.0.4

Reference URL: https://stackoverflow.com/questions/45019486/threading-model-of-spring-webflux-and-reactor

Referenced from: commits 19875d8

1 votes, 3 watchers

[spring-projects-issues]

Marc-Christian Schulze commented

I agree, documentation about the high level threading architecture and potential pitfalls imposed by it would be very helpful. In addition I would like to request documenting the known thread pools and how to customize and monitor them. Especially in case you violated the threading model e.g. by using block() inside of a WebFlux Controller it would be very handy to have some basic debugging features around the thread pools, e.g. allowing to detect if a pool has been depleted due to long running (potential forever) blocking calls.

[spring-projects-issues]

Rossen Stoyanchev commented

There is now a Concurrency Model section.

Marc-Christian Schulze, Reactor has a new feature that rejects the use of operators with blocking semantics on threads where blocking is not expected. That should come quite handy and will automatically apply with Reactor Netty. Beyond that there is really no way to detect calls to blocking APIs.