jetcd use only one event-loop thread

[Wackerle]

Versions

• etcd: 3.4.10
• jetcd: 0.7.7
• java: 1.8

Describe the bug
There is only one event-loop thread, which may cause performance and other problems.

To Reproduce
Code:

    public void test1() throws InterruptedException {
        System.out.println("test start in thread: " + Thread.currentThread().getName());
        for (int i = 0; i < 10; i++) {
            getResponse("key" + i);
        }
        Thread.sleep(5000);
        System.out.println("test end in thread: " + Thread.currentThread().getName());
    }

    private void getResponse(String key) {
        client.getKVClient()
            .get(ByteSequence.from(key, StandardCharsets.UTF_8))
            .whenComplete((getResponse, throwable) -> System.out
                .println("getResponse in thread: " + Thread.currentThread().getName()));
    }

Result:

test start in thread: main
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
test end in thread: main

Similar problem here

Expected behavior
The number of event-loop threads should be the number of CPU cores * 2.

Additional context

[Wackerle]

This is the code source of the problem I found.

When the jetcd creates a managedChannel for the first time, the vertx related methods are used.(io.etcd.jetcd.impl.ClientConnectionManager#getChannel)

    ManagedChannel getChannel() {
        if (managedChannel == null) {
            synchronized (lock) {
                if (managedChannel == null) {
                    managedChannel = defaultChannelBuilder().build();
                }
            }
        }

        return managedChannel;
    }

The implementation of the build method is as follows(io.vertx.grpc.VertxChannelBuilder#build):

  public ManagedChannel build() {
    // some code
    return builder
      .eventLoopGroup(context.nettyEventLoop())
      .channelFactory(transport.channelFactory(false))
      .executor(command -> {
      if (Context.isOnEventLoopThread()) {
        context.dispatch(event -> command.run());
      } else {
        command.run();
      }
    }).build();
  }

This code(.eventLoopGroup(context.nettyEventLoop())) causes grpc and netty to use only one eventloop thread.

I haven't figured out why vertx is doing this yet. But I wonder why jetcd switched from grpc to vertx? Or if there's something we're using incorrectly?

[lburgazzoli]

But I wonder why jetcd switched from grpc to vertx?

This had to do with maintenance, as I'm almost the only contributor left, I had to make some decision and switch to vert.x helped me to reduce some boilerplate and maintenance troubles.

Or if there's something we're using incorrectly?

Any help to figure it out would be really appreciated.

[barryzhang-cloud]

Is this issu solved? I have the same problem

[lburgazzoli]

@barryzhang-cloud no it is not, any help would be very appreciated

[Wackerle]

I suspect that there is a problem with the way jetcd integrates vert.x-grpc. So I asked for help in the vert.x user group, but no response. So I don't have any other ideas.