Open jaygazula27 opened 3 months ago
/cc @alesj (grpc), @cescoffier (grpc), @geoand (kubernetes), @iocanel (kubernetes), @radcortez (config)
I'm not sure the Vert.x server have these options? As we are more and more recommending this server, it would make sense to add these options there too.
@vietj ^^
@jaygazula27 Sorry to come back to this so late. It totally went of my radar.
It is only supported by the classic server. However, we can still support these properties and say in the documentation that is requires use-separate-server=true
.
Fancy to open a PR? @alesj and I would help you to get it in.
@cescoffier No worries. Is there any recommendation on what to do when using the new server? I'm concerned that scaling out the Quarkus app pods won't make a difference if the managed channel is cached by the client. Do you recommend that I ask in https://github.com/eclipse-vertx/vertx-grpc?
And regarding the PR, sure, I can take a crack at it even if it is just for the classic server!
@jaygazula27 Yes, that's the right place to post questions about the Vert.x server.
Description
I would like to be able to configure these options documented in gRPC's keepalive docs:
These properties can be set via the
ServerBuilder
class.Use case: As seen in the discussion here, this appears to be the recommendation for allowing clients to recognize new server instances. This is especially relevant in Kubernetes where the number of server pods may increase, but the gRPC client will have no idea about them because of the nature of the long lived HTTP/2 TCP connection. This happens regardless of the load balancing strategy. More info can be found here.
Implementation ideas
Ideally, I would like to be able to configure these via application properties as such:
quarkus.grpc.server.max-connection-age
quarkus.grpc.server.max-connection-age-grace
This seems like a fairly simple change in
GrpcServerRecorder#buildServer
? If so, I'm happy to contribute via a PR.