kubernetes-client: client.pods().inNamespace("x").list(); timeouts in version 6.6.0
Describe the bug
I can not get list of pods in version 6.6.0 but it works in 6.5.0 and on 6.5.1 it happens on a few percent of the attempts. I have tried to set log level to trace to get more information but that do not add any additional information regarding what is happening.
This is the request that timeout: client.pods().inNamespace(“x”).list();
Kubernetes version not in list: Client Version: version.Info{Major:“1”, Minor:“26”, GitVersion:“v1.26.1”, GitCommit:“e01e27ba1fcd49adae44ef0984abfc6ee999c99a”, GitTreeState:“clean”, BuildDate:“2023-03-13T18:01:50Z”, GoVersion:“go1.19.5”, Compiler:“gc”, Platform:“linux/amd64”}
Fabric8 Kubernetes Client version
6.6.0
Steps to reproduce
create a client then run: client.pods().inNamespace(“x”).list();
Expected behavior
Get a PodList object.
Runtime
Kubernetes (vanilla)
Kubernetes API Server version
next (development version)
Environment
Linux
Fabric8 Kubernetes Client Logs
class io.fabric8.kubernetes.client.KubernetesClientException: An error has occurred.
at io.fabric8.kubernetes.client.KubernetesClientException.launderThrowable(KubernetesClientException.java:129)
at io.fabric8.kubernetes.client.KubernetesClientException.launderThrowable(KubernetesClientException.java:122)
at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.waitForResult(OperationSupport.java:530)
at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.list(BaseOperation.java:424)
at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.list(BaseOperation.java:392)
at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.list(BaseOperation.java:93)
...
Caused By:
class java.util.concurrent.TimeoutException: null
at java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1960)
at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2095)
at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.waitForResult(OperationSupport.java:507)
at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.list(BaseOperation.java:424)
at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.list(BaseOperation.java:392)
at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.list(BaseOperation.java:93)
...
Additional context
The namespace is containing 104 pods. Pod Security Standards is enabled in the namespace at baseline level.
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 24 (11 by maintainers)
Commits related to this issue
- fix #5117: limiting the body bytes more and — committed to shawkins/kubernetes-client by shawkins a year ago
- fix #5117: limiting the body bytes more and showing bytes received — committed to shawkins/kubernetes-client by shawkins a year ago
- fix #5117: limiting the message size more and showing bytes received — committed to shawkins/kubernetes-client by shawkins a year ago
- fix #5117: limiting the message size more and showing bytes received — committed to shawkins/kubernetes-client by shawkins a year ago
- fix #5117: correcting the call to the actual consumer, showing bytes — committed to shawkins/kubernetes-client by shawkins a year ago
- fix #5117: correcting the call to the actual consumer, showing bytes — committed to shawkins/kubernetes-client by shawkins a year ago
- fix #5117: correcting the call to the actual consumer, showing bytes — committed to shawkins/kubernetes-client by shawkins a year ago
- fix #5117: correcting the call to the actual consumer, showing bytes — committed to fabric8io/kubernetes-client by shawkins a year ago
Thank you for the follow up, it’s good to have a definitive diagnosis. We’ll probably want to be more conservative with the size of message we’re attempting to log.
Interesting that there’s some extremely subtle behavioral change rather than a more noticeable error. If possible can you provide a pom or the dependencies that caused this, so that we can see if there’s something more defensive that would be easy to include?
I found the problem, it is a dependency conflict, when I created a new empty project and run the test from there it worked and I added one dep at the time and run the test until it froze then added some excludes and continued. The conflicts I found was on: com.squareup.okhttp3 and com.squareup.okio.
Thank you for your help! You can close this now.
The TimeoutException is probably hiding something else (#5095)
Could you please try with the newly released v6.6.1?