java: copyFileToPod method not working in 11.0.0

Hello team! I found a problem with the Kubernetes java client while updating from 10.0.0 to 11.0.0 This call does not work anymore copy.copyFileToPod(namespace, pod, container, src, destPath) here: https://github.com/kubernetes-client/java/blob/master/util/src/main/java/io/kubernetes/client/Copy.java#L381 the file is not copied and I see this error in the logs:

i.k.client.util.WebSocketStreamHandler   : Error on flush
java.io.IOException: Socket is closed!
	at io.kubernetes.client.util.WebSocketStreamHandler$WebSocketOutputStream.flush(WebSocketStreamHandler.java:221)
	at io.kubernetes.client.util.WebSocketStreamHandler.close(WebSocketStreamHandler.java:136)
	at io.kubernetes.client.Exec$ExecProcess$1.close(Exec.java:542)
	at io.kubernetes.client.Exec$ExecProcess$1.handleMessage(Exec.java:508)
	at io.kubernetes.client.util.WebSocketStreamHandler.bytesMessage(WebSocketStreamHandler.java:75)
	at io.kubernetes.client.util.WebSockets$Listener.onMessage(WebSockets.java:142)
	at okhttp3.internal.ws.RealWebSocket.onReadMessage(RealWebSocket.java:326)
	at okhttp3.internal.ws.WebSocketReader.readMessageFrame(WebSocketReader.java:221)
	at okhttp3.internal.ws.WebSocketReader.processNextFrame(WebSocketReader.java:105)
	at okhttp3.internal.ws.RealWebSocket.loopReader(RealWebSocket.java:273)
	at okhttp3.internal.ws.RealWebSocket$1.onResponse(RealWebSocket.java:209)
	at okhttp3.RealCall$AsyncCall.execute(RealCall.java:174)
	at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)
java.io.IOException: Copy failed: 137

Environment and Kubernetes version used: eks 1.18.9 Thanks in advance!

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 21 (14 by maintainers)

Most upvoted comments

In the current flow, the stdin stream is closed after the file data is written; however, the web socket session hangs because the client never sends a CLOSE message. I believe this is why Sarvesh was suggested possibly removing the waitFor() and moving on to the destory(), which does close the WebSocketStreamHandler instance triggering the CLOSE message.

However, I agree that it is incorrect to change get() to not do the waitFor().

@brendandburns, would it be appropriate for the Exec to send a CLOSE message when the stdin stream is closed?

Note: with the current code, the Copy call hangs at the waitFor(). If I Ctrl-C the Java process then I do see the file being copied to the pod appear in the container’s file system.

Note 2: there seems to be a second problem with very large files. If I try and copy a 512MB file, then only approximately the first 12MB’s appear following the Ctrl-C.

I’m going to experiment with sending the CLOSE message as described above.

rjeberhard on Feb 8, 2021

I can repro this too. After adding ProcessFuture to Copy class, we are trying to return future object with already used process object.

sarveshkaushal on Feb 2, 2021

I’ll see if I can repro.

brendandburns on Jan 12, 2021