You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here's my theory. We create the stdin stream and immediately start copying local stdin to the container. We do the same for stdout and stderr (create stream, start copying immediately). In the kubelet, we wait to receive all the streams before we start the exec and copy between the streams and the container.
The spdy connection frame handling code has 5 frame workers, each with a queue of up to 50 frames. In this case, we try to push more than 50 frames to a single queue, and the 51st attempt to push a frame blocks until there is space available in the queue. But there won't be any space until the server starts reading from the streams, which won't happen until all the streams have been received, so we're stuck at this point.
I think the fix is to create all the streams first, and only start copying after all the streams have been created and the server is ready to copy between the streams and the container. I'll prepare a fix for this.
This is happening only on streaming input. Output has no such issue. And of course, only on Windows.
Here's output of the exec command with DEBUG=1 (on windows and linux):
https://gist.github.com/csrwng/79a1b9a7af384130147e
The text was updated successfully, but these errors were encountered: