The previous code read

HttpServer.create().host(host).port(port).handle(adapter).bind().block();

Which doesn't block and terminates after the block The proper way to block is to register on the dispose callback. See https://projectreactor.io/docs/netty/release/reference/index.html#_starting_and_stopping

HttpServer.create().host(host).port(port).handle(adapter).bindNow().onDispose().block();

Comment From: rstoyanchev

The main purpose of those snippets is to show how to plug HttpHandler into each server, and that includes starting the server. It doesn't aim to show how to handle the full server lifecycle, so in that sense, the Reactor Netty sample as it is currently is not wrong. I can, however, change it to use bindNow() which is a bit shorter.

Comment From: mdeinum

It isn't the bindNow. The current sample doesn't block and thus nothing waits for an incoming request. It runs and stops, no wait, no possibility to fire a request and have it handled. So it does start and immediately quits, in earlier versions of Netty this wasn't the case (if remembered correctly).

Hence the update in the code sample.

Comment From: rstoyanchev

I'm not sure I follow. We use the same code here as what the sample shows, as far as I can see, and all our WebFlux integration tests run with that.

Comment From: mdeinum

Now that is weird. I have the same code in a main and it just passes through, no waiting.

public class ReactorNettyBootstrap {

    public static void main(String[] args) {
        var context = new AnnotationConfigApplicationContext(WebFluxConfiguration.class);
        var handler = WebHttpHandlerBuilder.applicationContext(context).build();

        var adapter = new ReactorHttpHandlerAdapter(handler);
        HttpServer.create().host("localhost").port(8090).handle(adapter).bind().block();
    }
}

This just runs and finishes. No waiting, no possibility to serve something.

I do recall this working in the past, for some reason, for me, it doesn't work anymore. However if this is working for Spring it must be me, so then please close this PR (I probably need to do more digging then, but I wouldn't know where to look anymore?).

Comment From: rstoyanchev

bind waits just long enough for the connection to be established and returns immediately after. In your case, the main method does nothing else, and exits.

Comment From: mdeinum

As stated it must be me. It was updated code from the Spring 5 sample to Spring 6 (with updated dependencies) which apparently needed to change differently.

I was expecting the code from the reference guide to create a server that would block and wait for requests to come in, but maybe that expectation was wrong.