-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The Pod WatchAll will fail in about half an hour #157
Comments
var eventStream = kubeApiClient.PodsV1()
.WatchAll(kubeNamespace: kubeNamespace);
eventStream.Select(resourceEvent => resourceEvent.Resource).Subscribe(subsequentEvent =>
{
// do ....
},
error => LogError($"Listening to pod fail."),
() =>
{
LogInfo("Listening to pod completed.");
}); The code above will execute OnCompleted after about 0.5-1 hours |
Does the OnError handler ever get called? Are there any events in that time? |
The client mostly uses HTTP/HTTPS, but uses Websockets for some actions (such as Exec).
Not currently but this is a good idea; we should be able to hide it behind the Maybe we need a slightly more granular API surface here; something to optionally maintain the connection, reopening it if it is closed by the server? It’s been a while, but I think Watch can also be done via WebSockets; maybe it’s worth looking into that. |
What version of Kubernetes are you using? Do you get the same behaviour when watching pods in a single namespace? |
Just had a look at the implementation; we use the k8s |
Possibly related: |
Kubernetes v1.23.6
No OnError events were raised, and the connection should be disconnected normally If the connection timeout is caused, an exception message is caught After about 40-50 minutes, the OnCompleted will be triggered
void InternalWatch()
{
var eventStream = kubeApiClient.PodsV1()
.WatchAll(kubeNamespace: kubeNamespace);
eventStream.Select(resourceEvent => resourceEvent.Resource).Subscribe(subsequentEvent =>
{
// do ...
},
error => LogError($"Listening to pod fail."),
() =>
{
LogInfo("Listening to pod completed.");
// Retrigger Watch
InternalWatch();
});
} Do you plan fix this problem in the next step? Thank you for your positive reply |
Thanks, that confirms my initial impression. I’ll look into adding a flag argument to automatically reconnect (since it’s a change in behaviour I’ll be making it opt-in). 🙂 |
Could you do me a favor and call |
@tintoy |
…due to server-side request GC) #157
This will require targeting |
If you have time, would you be able to try out the latest development version ( Development package feed is at https://www.myget.org/F/dotnet-kube-client/api/v3/index.json |
I’ll be publishing these changes to NuGet in a day or 2. |
Fixed in v2.5.10. |
Hello, how does the client communicate with api-server? Is there a retry mechanism
The text was updated successfully, but these errors were encountered: