dapr / dapr/java-sdk

Recommendation for planned deprecation of `DaprClientHttp`

オープン
#898 コメント 5 件 リアクション 0 件 担当者 0 名 GitHub で見る
good first issue kind/bug P1
主要言語
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

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。