You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Envoy sends multiple DeltaDiscoveryRequests for the same typeURL via the same stream connection to keep receiving updates for the type. However, the current incrementalXDS implementation silently ignores from the second request.
Here's what we saw from output of our integration test.(we added callbacks to print messages on delta stream open/close/request/response)
on 2021-06-11T18:40:37.591Z, the snapshot is updated to a new version that adds a new routes to RouteConfiguration along with a new Cluster/ClusterAssignment, but there is no response sent to the envoy until the test times out after 10 minutes.
if ok {
// cancel existing watch
watch.Cancel()
if len(req.GetResourceNamesSubscribe()) != 0 || len(req.GetResourceNamesUnsubscribe()) != 0 {
s.subscribe(req.GetResourceNamesSubscribe(), watch.state.ResourceVersions)
s.unsubscribe(req.GetResourceNamesUnsubscribe(), watch.state.ResourceVersions)
}
} else {
// Initialize the state of the stream.
// Since there was no previous state, we know we're handling the first request of this type
// so we set the initial resource versions if we have any, and also signal if this stream is in wildcard mode.
watch.state = stream.NewStreamState(len(req.GetResourceNamesSubscribe()) == 0, req.GetInitialResourceVersions())
if len(req.GetResourceNamesSubscribe()) != 0 {
s.subscribe(req.GetResourceNamesSubscribe(), watch.state.ResourceVersions)
s.unsubscribe(req.GetResourceNamesUnsubscribe(), watch.state.ResourceVersions)
}
}
// Code below is the same as line 173 to 199(https://github.com/envoyproxy/go-control-plane/blob/main/pkg/server/delta/v3/server.go#L173)
watch.responses, watch.cancel = s.cache.CreateDeltaWatch(req, watch.state)
...
(FYI, the tests still fail sometimes because the stream is closed unexpected by the controller, and envoy does not seem to be able to recover it. I'll post an update if I find why the stream is closed unexpected)
The text was updated successfully, but these errors were encountered:
@jparklab thanks for the solution! We're also currently investigating this since you posted: #446 previously. I'll look into what you posted above and see were we can proceed. I have a PR up now I might be able to move this into.
Seems it's not completely solved, I run into a similar issue in the latest version using envoy-gateway. Sometimes the it's just get stuck, and only responses after I restart the process.
Envoy sends multiple DeltaDiscoveryRequests for the same typeURL via the same stream connection to keep receiving updates for the type. However, the current incrementalXDS implementation silently ignores from the second request.
Here's what we saw from output of our integration test.(we added callbacks to print messages on delta stream open/close/request/response)
on 2021-06-11T18:40:37.591Z, the snapshot is updated to a new version that adds a new routes to RouteConfiguration along with a new Cluster/ClusterAssignment, but there is no response sent to the envoy until the test times out after 10 minutes.
It seems like that the logic at https://github.com/envoyproxy/go-control-plane/blob/main/pkg/server/delta/v3/server.go#L160 does not handle subsequent requests for the same typeURL well.
watch.responses
(https://github.com/envoyproxy/go-control-plane/blob/main/pkg/server/delta/v3/server.go#L182)I managed it to pass our integration tests by patching the code that handles the request(https://github.com/envoyproxy/go-control-plane/blob/main/pkg/server/delta/v3/server.go#L160-L199) like below.
(FYI, the tests still fail sometimes because the stream is closed unexpected by the controller, and envoy does not seem to be able to recover it. I'll post an update if I find why the stream is closed unexpected)
The text was updated successfully, but these errors were encountered: