Recommendation for planned deprecation of `DaprClientHttp`
- 主要言語
- Java
- スター
- 300
- フォーク
- 230
- 平均マージ
- 5日 1時間
- マージ済み PR(30日)
- 5
説明
Given a DaprClient created like this...
```java
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.
```java
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 `waitForSidecar` in `DaprClientGrpc` to use `v1.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 calling `v1.0/healthz`
This will allow a migration path for us, and also bring [parity with the dotnet SDK](https://github.com/dapr/dotnet-sdk/blob/17f849b17505b9a61be1e7bd3e69586718b9fdd3/src/Dapr.Client/DaprClientGrpc.cs#L1742-L1785)
コントリビューションガイド
調査の方向性
まず DaprClientGrpc の waitForSidecar を読み、その動作を DaprClientHttp および参照されている .NET 実装と比較します。v1.0/healthz と v1.0/healthz/outbound の違いを確認し、次に healthCheck API を定義して、アプリのチャネルが確立される前に waitForSidecar がシークレットの読み取りをサポートしていることを検証します。issue 897 も関連しています。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- java
- 領域
- api
- issue の種類
- 機能追加
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 35/100