Vert.x HTTP server on port 0 and MQTT client issue

[cescoffier]

Questions

This issue has been reproduced in Quarkus, but looks Vert.x specific.

In this use case, the HTTP verticle (start the HTTP server) instances (depending on the machine, but 8 in my case) are configured to listen on the port 0 (so dynamic binding). At the same time as the HTTP verticle start, an MQTT client is created and connect to an MQTT server.

The HTTP server cannot bind to the port, failing with a Bind exception.

Version

The code works with Quarkus 1.7 (Vert.x 3.8.5) and fails with Quarkus 1.8.1 (Vert.x 3.9.2).

Do you have a reproducer?

Reproducer available on:
smallrye/smallrye-reactive-messaging#778

Steps to reproduce

1. Download an unzip
2. Start MQTT server - docker run -p 8080:8080 -p 1883:1883 hivemq/hivemq4
3. mvn compile quarkus:dev
4. Boom

You can override the Vert.x version by declaring a dependency in the pom.xml file.

Extra

• if you start the MQTT client before or after it works
• if you debug, it works - probably a timing exception

[vietj]

do you know if that happens with only Vert.x and if the reproducer can be adapted ?

[cescoffier]

I don’t believe it can be easily adapted without writing a lot of code to reproduce what’s happening.

…

On Mon 28 Sep 2020 at 21:58, Julien Viet ***@***.***> wrote: do you know if that happens with only Vert.x and if the reproducer can be adapted ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3584 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADCG7J5SOHPOOI43PGS6RDSIDTGPANCNFSM4R4UZZCQ> .

[vietj]

I tried reproducing it using Mosquito public server and it worked correctly.

The reproducer does not have explanations on how to reproduce it.

I commented on the referenced issue.

[vietj]

note: the reproducer binds HTTP server on a random port

[cescoffier]

I provided the steps to reproduce in this issue description:

1. Download an unzip
2. Start MQTT server - docker run -p 8080:8080 -p 1883:1883 hivemq/hivemq4
3. mvn compile quarkus:dev
4. Boom

[cescoffier]

With the public mosquitto server it works (for me) in runner mode, but not with mvn compile quarkus:dev. Can you try with that mode?

With hive, it fails in both cases (for me).

[vietj]

I will have a try

[vietj]

Here is what happens:

1/ a WebDeploymentVerticle is deployed by VertxHttpRecorder with multiple instances using a Supplier returning the same verticle instance
2/ all instances start an HTTP server with an HttpServerOptions argument
3/ the first instance to call listen and enter the synchronized section will actually bind an HTTP server
4/ when the HTTP server is actually started, the callback will update the HttpServerOptions with the actual port that was bound

It happens that one deployment of the WebDeploymentVerticle will call listen after the actual HTTP server is bound and use the updated HttpServerOptions and try to bind the verticle using now the port. This will not be detected as a shared port by the HttpServer because one uses the port 0 scoped to the deployment ID and ther other uses the actual port that it provided.

The most appropriate way to solve this is that WebDeploymentVerticle either does not update the HttpServerOptions on a callback, or that the Supplier does not return a single of the same verticle (the javadoc says It must not return the same instance twice.)

[cescoffier]

Thanks a lot @vietj! That sounds easily fixable! I will change the Quarkus supplier. Any idea why it was not happening in Vert.x 3.8.5? Le mar. 29 sept. 2020 à 14:26, Julien Viet <notifications@github.com> a écrit :

…

Here is what happens: 1/ a WebDeploymentVerticle is deployed by VertxHttpRecorder with multiple instances using a Supplier returning the *same* verticle instance 2/ all instances start an HTTP server with an HttpServerOptions argument 3/ the first instance to call listen and enter the synchronized section will actually bind an HTTP server 4/ when the HTTP server is actually started, the callback will update the HttpServerOptions with the actual port that was bound It happens that one deployment of the WebDeploymentVerticle will call listen *after* the actual HTTP server is bound and use the updated HttpServerOptions and try to bind the verticle using now the port. This will not be detected as a shared port by the HttpServer because of the modification done previously with new shared HTTP server ID, the initial server ID is something like localhost/${deploymentId} and the server with the explicit port is localhost (because we use the deployment id only when the port is 0). The most appropriate way to solve this is that WebDeploymentVerticle either does not update the HttpServerOptions on a callback, or that the Supplier does not return a single of the same verticle (the javadoc says It must not return the same instance twice.) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3584 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADCG7MWRNVUPEURKOEQABDSIHG6DANCNFSM4R4UZZCQ> .

[cescoffier]

I don't believe it return the same instance:

vertx.deployVerticle(new Supplier<Verticle>() {
            @Override
            public Verticle get() {
                return new WebDeploymentVerticle(httpServerOptions, sslConfig, domainSocketOptions, launchMode,
                        httpConfiguration.insecureRequests);
            }
        }, new DeploymentOptions().setInstances(ioThreads), new Handler<AsyncResult<String>>() {
            @Override
            public void handle(AsyncResult<String> event) {
                if (event.failed()) {
                    futureResult.completeExceptionally(event.cause());
                } else {
                    futureResult.complete(event.result());
                }
            }
        });

[cescoffier]

@vietj Closing this issue. I opened a PR in Quarkus directly: quarkusio/quarkus#12401

[vietj]

no specific idea, this is racy, so it could happen before but was not visible.

…

On Tue, Sep 29, 2020 at 2:47 PM Clement Escoffier ***@***.***> wrote: Thanks a lot @vietj! That sounds easily fixable! I will change the Quarkus supplier. Any idea why it was not happening in Vert.x 3.8.5? Le mar. 29 sept. 2020 à 14:26, Julien Viet ***@***.***> a écrit : > Here is what happens: > > 1/ a WebDeploymentVerticle is deployed by VertxHttpRecorder with multiple > instances using a Supplier returning the *same* verticle instance > 2/ all instances start an HTTP server with an HttpServerOptions argument > 3/ the first instance to call listen and enter the synchronized section > will actually bind an HTTP server > 4/ when the HTTP server is actually started, the callback will update the > HttpServerOptions with the actual port that was bound > > It happens that one deployment of the WebDeploymentVerticle will call > listen *after* the actual HTTP server is bound and use the updated > HttpServerOptions and try to bind the verticle using now the port. This > will not be detected as a shared port by the HttpServer because of the > modification done previously with new shared HTTP server ID, the initial > server ID is something like localhost/${deploymentId} and the server with > the explicit port is localhost (because we use the deployment id only > when the port is 0). > > The most appropriate way to solve this is that WebDeploymentVerticle > either does not update the HttpServerOptions on a callback, or that the > Supplier does not return a single of the same verticle (the javadoc says It > must not return the same instance twice.) > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > < #3584 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AADCG7MWRNVUPEURKOEQABDSIHG6DANCNFSM4R4UZZCQ > > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3584 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABXDCRQBW6MKPMUQ7ERHKTSIHJOTANCNFSM4R4UZZCQ> .