dapr
Recommendation for planned deprecation of `DaprClientHttp`
Given a DaprClient created like this...
try (DaprClient client = (new DaprClientBuilder()).build()) {
...
}
...will result in a DaprClientGrpc by default.
When using waitForSidecar method, this exhibits the same behaviour as calling v1.0/healthz -- as this endpoint won't return success until both the components are initialised and the app channel is established.
We discovered this because in our Java app we are trying to read secrets from the secret component as part of the app initialisation, therefore before the app channel becomes available.
The impact was the app dead locked with the sidecar. Eventually waitForSidecar timeout elapsed, and the App crashed as it wasn't able to read the secrets that were depended later on.
I did some digging in the Java SDK code, and found that I could force the DaprClientBuilder to return a DaprClientHttp by doing the following.
System.getProperties().setProperty(Properties.API_PROTOCOL.getName(), DaprApiProtocol.HTTP.name());
try (DaprClient client = (new DaprClientBuilder()).build()) {
...
}
In this case, when using waitForSidecar method, this exhibits the same behaviour as calling v1.0/healthz/outbound -- this endpoint returns successfully when the components are established, but the app channel is not yet established. which is exactly what we needed.
The impact was that we could successfully read secrets during the init phase of our Java App, without causing a Deadlock.
Unfortunately, now this means our code depends on a deprecated capability (DaprClientHttp), which is planned to be removed in the next version of the Java SDK, 1.10
My ask is that the following changes are made before DaprClientHttp is removed from the SDK.
- Migrate
waitForSidecarinDaprClientGrpcto usev1.0/healthz/outbound- This would then allow this issue to be closed without fix https://github.com/dapr/java-sdk/issues/897
- Introduce a new method called
healthCheck, which has the same behaviour as callingv1.0/healthz
This will allow a migration path for us, and also bring parity with the dotnet SDK
I agree with this. Having parity with .Net seems the right thing hung here.
@olitomlinson Thank you for having such detailed issues in the Dapr project 🙌 I'm adding this one to a hackathon we're running tomorrow for the Grace Hopper Conference Open Source Day, so hopefully we can get some eyes on it 🤞 😁
@d195 Hope you are enjoying the Grace Hopper Conference Open Source Day event! Please let us know if you need help with anything (and when you open a PR with the changes) so we can move this issue in the board to "In review"! Thank youuuuu :)
