bisakhmondal commented on issue #2170:
URL:
https://github.com/apache/apisix-dashboard/issues/2170#issuecomment-946455714
Hi @RedemptionC, to be honest, it's a great question. I also had this one a
few whiles back.
Now coming to the explanation, etcd v3 `watch` API is event-driven, i.e.
whenever a PUT or DELETE events occurs it generates an event of type
```go
message Event {
enum EventType {
PUT = 0;
DELETE = 1;
}
EventType type = 1;
KeyValue kv = 2;
KeyValue prev_kv = 3;
}
```
and this watch call on a key is a long-running request. So, for high
performance, the watch API implementation uses gRPC bidirectional streaming to
squeeze the best out of HTTP2.0.
([ref](https://etcd.io/docs/v3.2/learning/api/#watch-streams))
But in BIDI streaming, you lose the topmost reliability of the
request-response acknowledgement cycle. gRPC internally caches them most of the
time if there are a large number of stream requests coming from the server. And
that's where the problem is. It might lead to several problems in non-ideal
scenarios (from delayed delivery to buffer overflow etc.)
That's why I guess, I saw the project coming from @nic-chen. I never asked
him though. Hi Nic, is this the particular cause behind this sync or there is
something more?
Thank you!
--
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]
