nic-chen commented on issue #2170:
URL:
https://github.com/apache/apisix-dashboard/issues/2170#issuecomment-946463771
> 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!
Definitely!
There is no other special reason. Compared to the dashboard, that tool is
more useful for APISIX.
--
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]
