We have DiscoveryClientNameResolver which allows to specify grpc client target like discovery:///service-name. Actual ip:port data is fetched from consul. Port also taken from gRPC_port metadata.
I suggest adding gRPC_service_config metadata key, similar to gRPC_port. Under this key grpc servers may publish service config.
This feature already present in standard DNS name resolver (details).
I already implement this in my custom name resolver and it work just fine.
On server side I specify my desired service config:
We have DiscoveryClientNameResolver which allows to specify grpc client target like
discovery:///service-name
. Actual ip:port data is fetched from consul. Port also taken fromgRPC_port
metadata.I suggest adding
gRPC_service_config
metadata key, similar togRPC_port
. Under this key grpc servers may publish service config.This feature already present in standard DNS name resolver (details).
I already implement this in my custom name resolver and it work just fine.
On server side I specify my desired service config:
Server's application.yml
```yaml spring: cloud: consul: discovery: metadata: gRPC_service_config: | { "loadBalancingConfig": [ {"round_robin": {}} ], "methodConfig": [ { "name": [{}], "retryPolicy": { "maxAttempts": 5, "initialBackoff": "0.05s", "maxBackoff": "1s", "backoffMultiplier": 2, "retryableStatusCodes": [ "UNAVAILABLE", "ABORTED", "DATA_LOSS", "INTERNAL", "DEADLINE_EXCEEDED" ] }, "timeout": "5s" } ] } ```On client side my name resolver parse it and pass to listener:
Code sample
```java var result = ResolutionResult.newBuilder().setAddresses(list); if (!serviceConfig.isEmpty()) { try { @SuppressWarnings("unchecked") Map