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.