Skip to content
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

Seemingly indefinite wait at a get operation #4663

Closed
shawkins opened this issue Dec 12, 2022 · 0 comments · Fixed by #4678
Closed

Seemingly indefinite wait at a get operation #4663

shawkins opened this issue Dec 12, 2022 · 0 comments · Fixed by #4678
Assignees
Milestone

Comments

@shawkins
Copy link
Contributor

A get operation failed to complete, far exceeding the default request timeout - which is not directly enforced by OperationSupport.waitForResult. There's an assumption that the httpclient layer will enforce the timeout. However if okhttp has exhausted it's max requests, it will not enforce the timeout while the request is enqueued. We have seen this as an issue with websockets, which for some reason count against the request total - so watches / informers will eventually exhaust the max requests.

Two changes are possible here - some enforcement of the request / read timeout in waitForResult, and take responsibility in the okhttp httpclient logic for incrementing the max requests for long running requests (websockets, even http watches if possible, but that seems more difficult to detect).

shawkins added a commit to shawkins/kubernetes-client that referenced this issue Dec 14, 2022
@shawkins shawkins self-assigned this Dec 14, 2022
shawkins added a commit to shawkins/kubernetes-client that referenced this issue Dec 14, 2022
manusa pushed a commit to shawkins/kubernetes-client that referenced this issue Dec 21, 2022
@manusa manusa added this to the 6.4.0 milestone Dec 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants