What is DispatcherHandler in Spring WebFlux, and what role does it play in request handling?
answer
- Reactive front controller = WebHandler
- Mapping -> Adapter -> ResultHandler
- Beans from ApplicationContext
- Mono<Void> handle(exchange)
- Analogue of DispatcherServlet
basics
~20 sDispatcherHandler is the central entry point in Spring WebFlux. For each request it finds the right handler (a controller method), invokes it, and turns the result into an HTTP response. It's the reactive equivalent of DispatcherServlet.
solid answer
~40 sDispatcherHandler is WebFlux's front controller — a WebHandler that Spring registers as a bean. For every incoming request it runs three phases: (1) ask each HandlerMapping to find the handler that matches the request (usually an @RequestMapping method or a RouterFunction); (2) pick a HandlerAdapter that knows how to invoke that handler type and call it, producing a Mono<HandlerResult>; (3) pass the HandlerResult to a matching HandlerResultHandler that writes the response (serializing a @ResponseBody, rendering a view, etc.). It's the non-blocking analogue of Spring MVC's DispatcherServlet, but everything returns reactive types (Mono/Flux) and runs on an event loop instead of a thread-per-request model. All these collaborators are ordinary beans discovered from the ApplicationContext.
go deeper
Know it's the reactive front controller that routes requests to handlers and returns a response.
Name the three collaborators (HandlerMapping/Adapter/ResultHandler) and the flow between them.
Explain bean discovery, ordering, empty-Mono 404, and reactive error propagation vs try/catch.
Contrast the WebHandler chain with the servlet model; reason about event-loop non-blocking constraints and extension points.
**DispatcherHandler** is the heart of the Spring WebFlux request-processing pipeline. WebFlux is Spring's *reactive*, non-blocking web stack (introduced in Spring 5), built on Project Reactor (`Mono`/`Flux`) and typically running on Netty rather than a servlet container. **Where it sits.** An HTTP request enters through the reactive runtime (e.g., Reactor Netty), is adapted into an `HttpHandler`, then reaches the `WebHandler` chain (which includes `WebFilter`s and exception handlers), and finally the `DispatcherHandler`. `DispatcherHandler` implements the `org.springframework.web.server.WebHandler` interface, whose single method is `Mono<Void> handle(ServerWebExchange exchange)`. **The three collaborators.** On startup, `DispatcherHandler` pulls three kinds of beans from the `ApplicationContext`: - **`HandlerMapping`** — maps a request to a *handler* object. Implementations include `RequestMappingHandlerMapping` (for `@RequestMapping`/`@GetMapping` controller methods) and `RouterFunctionMapping` (for functional `RouterFunction` routes). - **`HandlerAdapter`** — knows how to *invoke* a given handler type and returns `Mono<HandlerResult>`. `RequestMappingHandlerAdapter` invokes annotated controller methods; `HandlerFunctionAdapter` invokes functional handlers. - **`HandlerResultHandler`** — takes the `HandlerResult` and writes the response. Examples: `ResponseBodyResultHandler` (serialize return value via `HttpMessageWriter`), `ViewResolutionResultHandler` (render a view), `ResponseEntityResultHandler`, `ServerResponseResultHandler`. **The dispatch flow** (all reactive): 1. `handle(exchange)` iterates the ordered `HandlerMapping` list, calling `getHandler(exchange)`; the first non-empty `Mono` wins. 2. It finds the first `HandlerAdapter` whose `supports(handler)` returns true, then calls `handle(exchange, handler)` → `Mono<HandlerResult>`. 3. It finds the first `HandlerResultHandler` that `supports(result)` and calls `handleResult(exchange, result)` → `Mono<Void>`. **Edge cases / gotchas.** - If no `HandlerMapping` matches, the resulting `Mono` is empty and DispatcherHandler emits a `ResponseStatusException(404 NOT_FOUND)`. - Errors anywhere in the chain propagate as reactive error signals and are handled by `WebExceptionHandler`s (e.g., `DefaultErrorWebExceptionHandler` in Spring Boot), not try/catch. - Ordering matters: collaborators implement `Ordered`, so a more specific mapping/handler can take precedence. - It's fully non-blocking: your controller must not block the event-loop thread (no JDBC-style blocking calls without offloading). **When to care.** You rarely instantiate `DispatcherHandler` yourself — Spring Boot's `WebFluxAutoConfiguration` does it. You interact with the model by writing controllers/router functions and by customizing the collaborator beans (message writers, argument resolvers, etc.) via `WebFluxConfigurer`.
- What is the Spring MVC equivalent of DispatcherHandler?DispatcherServlet — same front-controller role, but servlet/blocking-based, returning ModelAndView instead of reactive Mono<HandlerResult>.
- What happens if no HandlerMapping matches the request?getHandler returns an empty Mono, and DispatcherHandler signals a ResponseStatusException with 404 NOT_FOUND, which a WebExceptionHandler turns into the response.
saying these in an interview costs you the question
- Saying DispatcherHandler uses the servlet API / DispatcherServlet under the hood
- Claiming it blocks a thread per request
- Thinking it serializes responses itself instead of delegating to HandlerResultHandler