Blocking calls in the Vert.x IO event loop.

[cbornet]

Jetcd uses vertx-grpc which makes calls being executed on the Vert.x IO event loop.
This means it's a bad thing to chain the response of a unary call with a blocking operation or to execute a blocking operation in a streaming call response handling.
For instance, doing:

clent.put(key, value).thenApply(() -> blockingCall());

or

Watch.listener(response -> blockingCall(), ...)

is very bad.

Before, Jetcd was using grpc-java which was delegating answers handling to a gRPC thread-pool.

So it would be nice to have an option to make answers be handled in the vert.x blocking worker pool (through vertx.executeBlocking() ?).
And to document clearly the default behavior so people are aware of the possible performance issue.
WDYT ?

[lburgazzoli]

So it would be nice to have an option to make answers be handled in the vert.x blocking worker pool

this can probably be achieved by using something like thenApplyAsync(..., executor) and we can provide an executor backed by Vert.x

And to document clearly the default behavior so people are aware of the possible performance issue.

Yep, that is absolutely required

[cbornet]

this can probably be achieved by using something like thenApplyAsync(..., executor) and we can provide an executor backed by Vert.x

Yes, the user can of course submit to its own executor where blocking is allowed. It would be nice though if there would be an option to have jetcd do it internally.

[lburgazzoli]

yes, I do have very limited time, if you can help doing it, then I'd be happily review the code

[cbornet]

this can probably be achieved by using something like thenApplyAsync(..., executor) and we can provide an executor backed by Vert.x

Yes, the user can of course submit to its own executor where blocking is allowed.

Actually this doesn't make it as in the case of streaming calls (watch) it breaks the back-pressure chain. The stream must be paused before doing the blocking call and resumed after it's finished. I think this can only be done in jetcd's internals.

[cbornet]

yes, I do have very limited time, if you can help doing it, then I'd be happily review the code

I'll see what I can do.
grpc-java publishes on a worker thread by default and there is a directExecutor() option to instead get the results on the IO thread.
There could maybe be an option like this on the jetcd client ?

[lburgazzoli]

no objection, but I need to see how it actually would work

[cbornet]

It's something like: recreating a per-call SerializingExecutor, pausing the stream, submitting to that executor, submit to the worker-pool, then resuming the stream.
Basically reimplementing what exists in grpc-java... Was there a big reason to switch to vertx-grpc ?

[lburgazzoli]

Was there a big reason to switch to vertx-grpc ?

The main reason is that I'm the only maintainer left on the project with a limited amount of time, so at the time I was more involved in vertx and grpc-java was giving me a lot of headache (dependencies, breaking changes, not very java idiomatic way of doing thing, etc).

Btw I have a plan to move to vertx-client and get rid of grcp-java entirely once I have time

[lburgazzoli]

It's something like: recreating a per-call SerializingExecutor, pausing the stream, submitting to that executor, submit to the worker-pool, then resuming the stream.

I guess that maybe you can probably just implement your own event queuing mechanism if you need to execute blocking calls on a watch event.

[cbornet]

Btw I have a plan to move to vertx-client and get rid of grcp-java entirely once I have time

I have sent you a PR on this work to support blocking calls in handlers with back-pressure lburgazzoli#1 .
LMK what you think.

[cbornet]

The main reason is that I'm the only maintainer left on the project with a limited amount of time, so at the time I was more involved in vertx and grpc-java was giving me a lot of headache (dependencies, breaking changes, not very java idiomatic way of doing thing, etc).

Makes sense. Thanks for the context.

I guess that maybe you can probably just implement your own event queuing mechanism if you need to execute blocking calls on a watch event.

I started a WIP PR with inspiration from what is done by grpc-java: #1558
Happy to discuss and get feedback.

[cbornet]

Actually my PR was not OK because the vertx stubs are just wrappers around grpc-java stubs and we can't handle flow control manually with these stubs.
On the other hand the vertx stubs actually don't use the vertx event loop (that's why they work with InProcessChannelBuilder), so they can be used with the NettyChannelBuilder instead of the VertxChannelBuilder.
@lburgazzoli Would you accept a PR to use NettyChannelBuilder instead of VertxChannelBuilder ? With maybe a switch to VertxChannelBuilder if a Vertx instance is passed in the builder, and maybe a useVertx() to switch back to the default VertxChannelBuilder.
This would fix #1297 #1089 #1285 and solve a lot of headaches for people who want to upgrade from jetcd 0.6.

Btw I have a plan to move to vertx-client and get rid of grcp-java entirely once I have time

Nice. I think flow control can be easily implemented with the vertx-grpc-client. I'll have a look.

[cbornet]

I opened #1559.
LMK what you think.