Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate to GrpcChannel #556

Merged
merged 13 commits into from
Aug 12, 2023
Merged

Migrate to GrpcChannel #556

merged 13 commits into from
Aug 12, 2023

Conversation

ChrisKujawa
Copy link
Collaborator

@ChrisKujawa ChrisKujawa commented Aug 10, 2023

In order to use the dotnet native grpc.net channel we have to migrate
to the new GrpcChannel. Previously, we still used the Grpc.Core
channel which is backed with C code (non-native dotnet).

There are several changes which have to be done in order to migrate to
the new GrpcChannel. Important part is that ChannelOptions and
Credentials doesn't work as before.

  1. GrpcChannel uses internally HttpClient, which means we have to set
    the keepAlive on the SocketsHttpHandler.
  2. User-agent header needs to be set via an interceptor.
  3. SslOptions set on the underlying SockerHttpHandler
  4. New configuration to allow untrusted certificates, useful for testing but dangerous for production (which is why it needs to be configured explicitly)
  5. New connect method on the ZeebeClient impl which tries to connect to the server without sending an RPC.
  6. Improve logging (give the underlying GrpcChannel the inserted logger)
  7. Adjust IT and await methods, such that it uses max retries and timeouts etc. (We had deadlocks due to retries, requests not timing out etc.)

Resources I used:

Thanks to @xlegalles for his previous PR #517, which contained already several changes. Sorry that I wasn't able to see the need for it before. I mark you as co-author on some changes :)

Closes #502
closes #554

ChrisKujawa and others added 3 commits August 10, 2023 16:46
In order to use the dotnet native grpc.net channel we have to migrate
to the new GrpcChannel. Previously, we still used the Grpc.Core
channel which is backed with C code (non-native dotnet).

There are several changes which have to be done in order to migrate to
the new GrpcChannel. Important part is that ChannelOptions and
Credentials doesn't work as before.

1. GrpcChannel uses internally HttpClient, which means we have to set
   the keepAlive on the SocketsHttpHandler.
2. User-agent header needs to be set via an interceptor.

Co-authored-by: legalles <legalles@kappaeng.com>
@camunda-community-hub camunda-community-hub deleted a comment from sonatype-lift bot Aug 10, 2023
@xlegalles
Copy link
Contributor

Thank you, but I just wanted tp help, not waiting for awards ;)

With the Grpc.net migration and the GrpcChannel we no longer can use the SslCredentials
to set our certificate. This is kept for backwards compatibility, but will not
accept any custom certificate. If we want specifiy a certificate we have to create a
X509Certificate2 and set it on the SocketsHttpHandler in the specific SslOptions.

Furthermore to allow custom self-signed certs we need to adjust the validation, otherwise
the certificates are rejected.
In order to fail commands correctly after client has been disposed we use
a ClosedGatewayClient, which directly fails on all commands.
In order to replace the client on dispose we mark it as volatile
Use new ZeebeClient.Connect method to await grpc readiness
Use Timeouts to not forever await the topology request (was problem before)
Add delays between retries
Add max retry count to not retry for ever
Add better logging to understand what happens on the await
Add new configuration to allow untrusted certificates, useful for testing but dangerious for
production so it needs to be configured explicitly.
@ChrisKujawa ChrisKujawa merged commit fb203e8 into main Aug 12, 2023
@ChrisKujawa ChrisKujawa deleted the ck-migrate-grpc-channel branch August 12, 2023 06:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants