Container start hangs intermittently during file transfer

As discussed with @bsideup, I've seen a situation where starting a container hangs while transferring a file into it. Here's the stack of the hang:

"Test worker" #19 prio=5 os_prio=31 tid=0x00007f8ad098d000 nid=0x9d03 in Object.wait() [0x000070000ad74000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.io.PipedInputStream.awaitSpace(PipedInputStream.java:273)
	at java.io.PipedInputStream.receive(PipedInputStream.java:231)
	- locked <0x00000007ae57cd20> (a java.io.PipedInputStream)
	at java.io.PipedOutputStream.write(PipedOutputStream.java:149)
	at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:253)
	at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:211)
	at java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:145)
	- locked <0x00000007ae57f528> (a java.util.zip.GZIPOutputStream)
	at org.apache.commons.compress.utils.CountingOutputStream.write(CountingOutputStream.java:48)
	at org.apache.commons.compress.utils.FixedLengthBlockOutputStream$BufferAtATimeOutputChannel.write(FixedLengthBlockOutputStream.java:244)
	at org.apache.commons.compress.utils.FixedLengthBlockOutputStream.writeBlock(FixedLengthBlockOutputStream.java:92)
	at org.apache.commons.compress.utils.FixedLengthBlockOutputStream.maybeFlush(FixedLengthBlockOutputStream.java:86)
	at org.apache.commons.compress.utils.FixedLengthBlockOutputStream.write(FixedLengthBlockOutputStream.java:122)
	at org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.write(TarArchiveOutputStream.java:454)
	at java.nio.file.Files.copy(Files.java:2909)
	at java.nio.file.Files.copy(Files.java:3069)
	at org.testcontainers.utility.MountableFile.recursiveTar(MountableFile.java:326)
	at org.testcontainers.utility.MountableFile.transferTo(MountableFile.java:300)
	at org.testcontainers.images.builder.ImageFromDockerfile.resolve(ImageFromDockerfile.java:130)
	at org.testcontainers.images.builder.ImageFromDockerfile.resolve(ImageFromDockerfile.java:37)
	at org.testcontainers.utility.LazyFuture.getResolvedValue(LazyFuture.java:20)
	- locked <0x00000007ae578a90> (a java.util.concurrent.atomic.AtomicReference)
	at org.testcontainers.utility.LazyFuture.get(LazyFuture.java:27)
	at org.testcontainers.shaded.com.google.common.util.concurrent.Futures$3.get(Futures.java:1332)
	at org.testcontainers.images.RemoteDockerImage.getImageName(RemoteDockerImage.java:97)
	at org.testcontainers.images.RemoteDockerImage.resolve(RemoteDockerImage.java:56)
	at org.testcontainers.images.RemoteDockerImage.resolve(RemoteDockerImage.java:26)
	at org.testcontainers.utility.LazyFuture.getResolvedValue(LazyFuture.java:20)
	- locked <0x00000007ae57c750> (a java.util.concurrent.atomic.AtomicReference)
	at org.testcontainers.utility.LazyFuture.get(LazyFuture.java:27)
	at org.testcontainers.containers.GenericContainer.getDockerImageName(GenericContainer.java:1277)
	at org.testcontainers.containers.GenericContainer.logger(GenericContainer.java:613)
	at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:320)
	at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:311)
	at sample.DeploymentIntegrationTests$DeployedApplication.test(DeploymentIntegrationTests.java:104)
	…

This is the test that's starting the container. The hang occurred using Testcontainers 1.14.3. I've said that it's intermittent in the issue title, but that's something of an exaggeration. I've only seen this once. Unfortunately, that means I'm not sure what caused it or how to reproduce it. I'll update this issue if I see it again.

MountableFile.recursiveTar と MountableFile.transferTo のスタックから始め、次に ImageFromDockerfile.resolve と、参照されている DeploymentIntegrationTests.java の104行目を調べます。ファイル転送中のコンテナ起動時のハングを再現してみてください。完了の条件は、ハングを特定して対処し、デプロイメント統合テストが引き続き確実に起動することです。