Allow customization of the SSLHelper initialization timeout

[yeikel]

Describe the feature

In Vertx 4.3.4, we changed how the SSLHelper is constructed and hardcoded it to 1 minute

This change is causing problems for an application that have a great amount of blocking initialization code

Ideally, this parameter should be customizable (system property should be fine) until a better long term solution can be archived. Not all blocking code is easily replaceable at this point for us as many of the components are legacy components that we don't own

Use cases

Applications that have a great amount of blocking code during initialization will have problems to create an instance of the SSLHelper within 1 minute

Contribution

If we agree that a System property is appropriate, I can give it a shot.

[yeikel]

Besides a system property, we can also add this to the VertxServerBuilder builder

[cescoffier]

Isn't that method called on the event loop? Blocking, even for a smaller amount of time should not happen.

[yeikel]

Isn't that method called on the event loop? Blocking, even for a smaller amount of time should not happen.

During initialization it doesn't matter

[vietj]

can you show a stacktrace ? it is not clear to me what the issue is ? do you have some kind of deadlock ?

[vietj]

Isn't that method called on the event loop? Blocking, even for a smaller amount of time should not happen.

yes it's called on event-loop and we have no choice here because of the grpc-java API we are using that forces to do that, usually this is done during init time. The issue is that initialisation in grpc-java is synchronous API.

[yeikel]

can you show a stacktrace ? it is not clear to me what the issue is ? do you have some kind of deadlock ?

Initialization takes more than 1 minute because the event bus is blocked doing other Initialization and this part times out. The SSLHelper fails to be created as a result

[vietj]

can you provide a reproducer project ?

[vietj]

ping @yeikel

[yeikel]

ping @yeikel

Unfortunately I don't have a reproducer at this point because it is produced by legacy internal closed source components

I'll try to prepare one and get back to you

What I know is that downgrading to the previous version before the refactoring solved the problem for us and that initialization of the project takes more than 1 minute

[vietj]

thanks it is not clear to me what the issue is.

the event-loop initializing the helper should not be blocked for long time because the init is done on the internal worker pool.

On Tue, Oct 25, 2022 at 1:05 PM Yeikel @.***> wrote:

ping @yeikel https://github.com/yeikel

Unfortunately I don't have a reproducer at this point because it is produced by legacy internal closed source components

I'll try to prepare one and get back to you

What I know is that downgrading to the previous version before the refactoring solved the problem for us and that initialization of the project takes more than 1 minute

— Reply to this email directly, view it on GitHub https://github.com/vert-x3/vertx-grpc/issues/130#issuecomment-1290366916, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXDCXIGNDADYS5SEQFOTLWE65GHANCNFSM6AAAAAARHQDCDU . You are receiving this because you were assigned.Message ID: @.***>

[yeikel]

thanks it is not clear to me what the issue is. the event-loop initializing the helper should not be blocked for long time because the init is done on the internal worker pool. … On Tue, Oct 25, 2022 at 1:05 PM Yeikel @.> wrote: ping @yeikel https://github.com/yeikel Unfortunately I don't have a reproducer at this point because it is produced by legacy internal closed source components I'll try to prepare one and get back to you What I know is that downgrading to the previous version before the refactoring solved the problem for us and that initialization of the project takes more than 1 minute — Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXDCXIGNDADYS5SEQFOTLWE65GHANCNFSM6AAAAAARHQDCDU . You are receiving this because you were assigned.Message ID: @.>

We were able to replicate it. See the following code:

Main.java

package com.example.starter;

import io.vertx.core.AbstractVerticle;
import io.vertx.core.DeploymentOptions;
import io.vertx.core.Vertx;
import io.vertx.grpc.VertxChannelBuilder;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Main {
  private static final Logger LOGGER = LoggerFactory.getLogger(Main.class);

  public static void main(String[] args) throws Exception {
    Vertx vertx = Vertx.vertx();

    vertx.deployVerticle(GrpcVerticle.class, new DeploymentOptions()).onComplete(result -> {
      if (result.succeeded()) {
        LOGGER.info("GRPC deployment complete");
      } else {
        LOGGER.error("GRPC deployment failed", result.cause());
      }
    });

    vertx.deployVerticle(BlockingVerticle.class,new DeploymentOptions().setInstances(2 * Runtime.getRuntime().availableProcessors()))
      .onComplete(result -> {
        if (result.succeeded()) {
          LOGGER.info("Blocking deployment {} complete",result);
        } else {
          LOGGER.error("Blocking deployment {} failed",result);
        }
      });

    vertx.close();
  }

  public static class BlockingVerticle extends AbstractVerticle {
    @Override
    public void start() throws Exception {
      // Simulate long blocking initialization code
      Thread.sleep(120 * 1000L);
    }
  }

  public static class GrpcVerticle extends AbstractVerticle {
    @Override
    public void start() {
      VertxChannelBuilder.forAddress(vertx, "localhost", 8080)
        .useSsl(options -> options.setSsl(true))
        .build();
    }
  }
}

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>org.example</groupId>
  <artifactId>vertx-grpc-timeout</artifactId>
  <version>1.0-SNAPSHOT</version>

  <properties>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
  </properties>

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>io.vertx</groupId>
        <artifactId>vertx-dependencies</artifactId>
        <version>4.3.4</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <dependencies>
    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-core</artifactId>
    </dependency>
    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-grpc</artifactId>
    </dependency>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>2.0.3</version>
    </dependency>
    <dependency>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-classic</artifactId>
      <version>1.4.4</version>
    </dependency>
  </dependencies>
</project>

Stack trace :

14:39:55.115 [vert.x-eventloop-thread-23] ERROR com.example.starter.Main - GRPC deployment failed
io.vertx.core.VertxException: java.util.concurrent.TimeoutException
    at io.vertx.grpc.VertxChannelBuilder.build(VertxChannelBuilder.java:293)
    at com.example.starter.Main$GrpcVerticle.start(Main.java:51)
    at io.vertx.core.AbstractVerticle.start(AbstractVerticle.java:106)
    at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$5(DeploymentManager.java:196)
    at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:264)
    at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:246)
    at io.vertx.core.impl.EventLoopContext.lambda$runOnContext$0(EventLoopContext.java:43)
    at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
    at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
    at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
    at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
    at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
    at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.util.concurrent.TimeoutException: null
    at java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1960)
    at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2095)
    at io.vertx.grpc.VertxChannelBuilder.build(VertxChannelBuilder.java:287)
    ... 14 common frames omitted

[vietj]

can you link to a small java project :-) ?

[yeikel]

can you link to a small java project :-) ?

There you go :)

https://github.com/yeikel/vertx-grpc-issue-130

[vietj]

thanks

there you go :)

https://github.com/vert-x3/vertx-grpc/pull/132

[yeikel]

thanks

there you go :)

132

That was incredibly quickly. Thank you!

Looking forward to testing it as soon as it is released :)