Upload InputStream To Pod with java.io.InterruptedIOException: interrupted (6.0.0-RC1)

[neuropaddy]

Describe the bug

An unexpected ERROR InterruptedIOException occurred while using 'upload' API in kubernetesClient 6.0.0-RC1, but, this exception does not occur in v5.12.2.

Fabric8 Kubernetes Client version

6.0.0-RC1

Steps to reproduce

1. In 6.0.0-RC1, run the following code
   try (KubernetesClient client = new KubernetesClientBuilder().build()) {
   client.pods().inNamespace(nameSpace) // <- Namespace of Pod
   .withName(podName) // <- Name of Pod
   .file(podFileLocation) // <- Target location of copied file inside Pod
   .upload(new ByteArrayInputStream(content.getBytes()));
   }
2. Then, a ERROR InterruptedIOException triggered.
3. Rollback to v5.12.2, run the following code, the above ERROR exception is not happened
   try (KubernetesClient client = new DefaultKubernetesClient()) {
   client.pods().inNamespace(nameSpace) // <- Namespace of Pod
   .withName(podName) // <- Name of Pod
   .file(podFileLocation) // <- Target location of copied file inside Pod
   .upload(new ByteArrayInputStream(content.getBytes()));
   }

Expected behavior

Suppose the ERROR InterruptedIOException does not occurred in v.6.0.0-RC1.

Runtime

minikube

Kubernetes API Server version

other (please specify in additional context)

Environment

Linux

Fabric8 Kubernetes Client Logs

{"log":"20220705 03:40:53.323 ERROR - [OkHttp https://10.96.0.1/...]  i.f.k.c.d.i.ExecWebSocketListener        : Exec Failure\n","stream":"stdout","time":"2022-07-05T03:40:53.324556993Z"}
{"log":"\n","stream":"stdout","time":"2022-07-05T03:40:53.324585428Z"}
{"log":"java.io.InterruptedIOException: interrupted\n","stream":"stdout","time":"2022-07-05T03:40:53.324587792Z"}
{"log":"\u0009at okio.Timeout.throwIfReached(Timeout.kt:98)\n","stream":"stdout","time":"2022-07-05T03:40:53.324589736Z"}
{"log":"\u0009at okio.InputStreamSource.read(JvmOkio.kt:87)\n","stream":"stdout","time":"2022-07-05T03:40:53.324605265Z"}
{"log":"\u0009at okio.AsyncTimeout$source$1.read(AsyncTimeout.kt:129)\n","stream":"stdout","time":"2022-07-05T03:40:53.324607129Z"}
{"log":"\u0009at okio.RealBufferedSource.request(RealBufferedSource.kt:206)\n","stream":"stdout","time":"2022-07-05T03:40:53.324608842Z"}
{"log":"\u0009at okio.RealBufferedSource.require(RealBufferedSource.kt:199)\n","stream":"stdout","time":"2022-07-05T03:40:53.324610535Z"}
{"log":"\u0009at okio.RealBufferedSource.readByte(RealBufferedSource.kt:209)\n","stream":"stdout","time":"2022-07-05T03:40:53.324612199Z"}
{"log":"\u0009at okhttp3.internal.ws.WebSocketReader.readHeader(WebSocketReader.kt:119)\n","stream":"stdout","time":"2022-07-05T03:40:53.324613892Z"}
{"log":"\u0009at okhttp3.internal.ws.WebSocketReader.processNextFrame(WebSocketReader.kt:102)\n","stream":"stdout","time":"2022-07-05T03:40:53.324615625Z"}
{"log":"\u0009at okhttp3.internal.ws.RealWebSocket.loopReader(RealWebSocket.kt:293)\n","stream":"stdout","time":"2022-07-05T03:40:53.324617328Z"}
{"log":"\u0009at okhttp3.internal.ws.RealWebSocket$connect$1.onResponse(RealWebSocket.kt:195)\n","stream":"stdout","time":"2022-07-05T03:40:53.324619002Z"}
{"log":"\u0009at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519)\n","stream":"stdout","time":"2022-07-05T03:40:53.324620705Z"}
{"log":"\u0009at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)\n","stream":"stdout","time":"2022-07-05T03:40:53.324622358Z"}
{"log":"\u0009at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)\n","stream":"stdout","time":"2022-07-05T03:40:53.324624061Z"}
{"log":"\u0009at java.base/java.lang.Thread.run(Thread.java:833)\n","stream":"stdout","time":"2022-07-05T03:40:53.324625805Z"}

Additional context

API server version: k8s.gcr.io/kube-apiserver:v1.23.3

[shawkins]

@neuropaddy I haven't reproduced this yet. From what I can see, this exception is just being logged - it's not causing the upload to fail, is that correct?

This looks like a timing issue with websocket resources not being fully closed by the time the client is closing. However the ExecWatch should have already been closed at that point.

[neuropaddy]

Yes, the upload operation is success and the content can be written to the pod.
As I observed the log is appeared before the socket close, I wonder if there is a async effect.

[sunix]

I could not reproduce this (jbang + minikube).
@shawkins do you have any hints?

[shawkins]

@sunix we probably just need to filter this - check if the exitCode future is done, if it is then there's no need to call the listener method or log.