Use NettyChannelBuilder to enable blocking calls in callbacks#1559
Use NettyChannelBuilder to enable blocking calls in callbacks#1559lburgazzoli merged 1 commit intoetcd-io:mainfrom
Conversation
NettyChannelBuilder delegates onNext/onError/onCompleted to a thread-pool with ordering guarantees. It makes it possible to block in jetcd callbacks which is not possible with VertxChannelBuilder as that blocks the vertx event loop. Signed-off-by: cbornet <cbornet@hotmail.com>
cbornet
force-pushed
the
use-grpc-netty
branch
from
1358598 to
5ba597a
Compare
cbornet
changed the title
|
Hi @lburgazzoli, would you have time to review ? |
|
hope by the end of the week, please ping me again in case I won't |
Hi @lburgazzoli, gentle ping. |
|
@lburgazzoli , gentle ping ? |
|
hey sorry, I promise I'll look into this before EOW, sorry again |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cbornet, lburgazzoli The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@cbornet merged it (sorry for the long delay), Can you also look at: |
|
Awesome, thanks! |
Yes, I already proposed a way to support blocking calls in listener handlers when using Vert.x : lburgazzoli#1 |
3 participants
It's currently not possible to do blocking calls in listener handlers while preserving back-pressure as that blocks the vertx event loop (see #1089 #1285).
Instead of
VertxChannelBuilder, we can useNettyChannelBuilderdelegatesonNext/onError/onCompletedto a thread-pool with ordering guarantees.It is OK to do it as the vertx-grpc stubs are just wrappers around the grpc-java ones and don't actually use the vertx loop. So they are compatible with any
ManagedChannelBuilder(eg. in unit testsInProcessChannelBuilderis used).Alternatives: