imbajin commented on PR #3130:
URL: https://github.com/apache/hugegraph/pull/3130#issuecomment-5282450334
## Design direction to validate: keep Store identity at the DNS target layer
The current head (`bdd8df11`) proves that explicit address fingerprinting and
pool replacement can be made increasingly defensive, but the accumulated
concurrency and lifecycle machinery suggests that we should first re-check
the
ownership boundary.
In Kubernetes, HugeGraph should ideally know a stable logical target such as
`store-1.<headless-service>:8500`, not the Pod IP currently behind it:
```mermaid
flowchart LR
HG["HugeGraph Store client<br/>stable DNS target only"]
CH["gRPC ManagedChannel"]
NR["gRPC NameResolver<br/>re-resolution / reconnect"]
DNS["Kubernetes DNS / Endpoint"]
OLD["old Store Pod<br/>10.0.0.8"]
NEW["replacement Store Pod<br/>10.0.0.19"]
HG --> CH --> NR --> DNS
DNS -. "before replacement" .-> OLD
DNS -- "after replacement" --> NEW
```
The intended responsibility split would be:
```text
Kubernetes assigns the new Pod IP and updates DNS/Endpoints
Java DNS policy permits a fresh answer (#3126)
gRPC owns name resolution, reconnect/backoff and transport state
HugeGraph owns logical Store identity, bounded business retry and
close
```
Under that model, HugeGraph would not normally maintain resolved IP
fingerprints, refresh deadlines, DNS worker pools, or a second connection
replacement state machine. It would retain the stable target and use the
smallest gRPC lifecycle trigger needed after a retryable transport failure.
This is a hypothesis, not yet a replacement proposal. Before changing this
PR,
we should validate it against the repository's effective gRPC version and the
original Store-replacement failure:
1. Start from merged #3126 and #3128 without this PR's explicit DNS
fingerprint/pool-replacement machinery.
2. Create and keep the same `ManagedChannel` for a stable Store DNS target.
3. Replace the Store Pod so the DNS name and Store node ID remain unchanged
but
the IP changes.
4. Keep the Server JVM and channel alive; capture whether gRPC requests fresh
name resolution and reconnects after `UNAVAILABLE`.
5. If it recovers, reduce this PR to the missing retry/lifecycle/cleanup
boundary and focused regressions.
6. If it does not recover, locate the exact failed boundary (JVM DNS cache,
gRPC resolver refresh, reconnect/backoff, HugeGraph retry, or client
cache)
and add only the minimum explicit invalidation/replacement mechanism
proven
necessary.
The key acceptance test is:
```text
same Store DNS + same node ID + new Pod IP
-> no Server restart
-> bounded read/write recovery
-> no data-integrity regression
```
I am running three independent validation tracks next: gRPC/JDK source and
version behavior, a minimal runtime experiment, and a blind root-cause/design
analysis that is not given this proposal. I will report whether they converge
before recommending a rewrite of the current implementation.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
