You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by GitBox <gi...@apache.org> on 2021/10/12 04:23:02 UTC
[GitHub] [apisix-dashboard] RedemptionC opened a new issue #2170: help request: when will data in cache be different with those in ETCD?
RedemptionC opened a new issue #2170:
URL: https://github.com/apache/apisix-dashboard/issues/2170
could you give some example?
--
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: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [apisix-dashboard] nic-chen commented on issue #2170: help request: when will data in cache be different with those in ETCD?
Posted by GitBox <gi...@apache.org>.
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: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [apisix-dashboard] bisakhmondal commented on issue #2170: help request: when will data in cache be different with those in ETCD?
Posted by GitBox <gi...@apache.org>.
bisakhmondal commented on issue #2170:
URL: https://github.com/apache/apisix-dashboard/issues/2170#issuecomment-946488775
> There is no other special reason. Compared to the dashboard, that tool is more useful for APISIX.
Totally agree with 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: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [apisix-dashboard] bisakhmondal commented on issue #2170: help request: when will data in cache be different with those in ETCD?
Posted by GitBox <gi...@apache.org>.
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: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [apisix-dashboard] nic-chen closed issue #2170: help request: when will data in cache be different with those in ETCD?
Posted by GitBox <gi...@apache.org>.
nic-chen closed issue #2170:
URL: https://github.com/apache/apisix-dashboard/issues/2170
--
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: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org