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
I have a rather obscure issue with how MountableFile is generating the temporary file for copying classpath resources. I occasionally see the following error in my log files -
2017-07-25 18:09:53,920 - [ERROR] - from org.testcontainers.utility.MountableFile in main Failed to extract classpath resource org/testcontainers/DockerClientFactory.class from JAR file /qc/my-app/lib/org.testcontainers.testcontainers-1.4.2.jar java.nio.file.FileAlreadyExistsException: .testcontainers-tmp-wYxDE at sun.nio.fs.UnixException.translateToIOException(UnixException.java:88) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214) at java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434) at java.nio.file.Files.newOutputStream(Files.java:216) at java.nio.file.Files.copy(Files.java:3016) at org.testcontainers.utility.MountableFile.copyFromJarToLocation(MountableFile.java:191) at org.testcontainers.utility.MountableFile.extractClassPathResourceToTempLocation(MountableFile.java:157) at org.testcontainers.utility.MountableFile.resolvePath(MountableFile.java:120) at org.testcontainers.utility.MountableFile.getResolvedPath(MountableFile.java:38) at org.testcontainers.DockerClientFactory.lambda$client$0(DockerClientFactory.java:122) at org.testcontainers.DockerClientFactory$$Lambda$32/976810274.accept(Unknown Source) at org.testcontainers.DockerClientFactory.runInsideDocker(DockerClientFactory.java:225) at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:118) at org.testcontainers.containers.GenericContainer.<init>(GenericContainer.java:116) at org.testcontainers.containers.GenericContainer.<init>(GenericContainer.java:156) at org.testcontainers.containers.BrowserWebDriverContainer.<init>(BrowserWebDriverContainer.java:59) at org.testcontainers.containers.BrowserWebDriverContainer.<init>(BrowserWebDriverContainer.java:70)
I'm running CentOS 7 on an EC2 instance, with Java 8u31.
The code causing the exception is here. Having debugged the issue, it looks like in some cases the temporary directory is created, but fails to be deleted. I'm not sure what the exact cause is. It's possible there's another process watching the directory, causing the directory generated to fail to be deleted, or it's some obscure permissioning issue I've not been able to get to the bottom of.
I'm wondering why it's necessary to call mkdirs() prior to generating the temporary file? Would it make sense to call mkdirs on the parent directory instead, and avoid having to delete the directory generated? Why is it necessary to create the parent directory, given that it's the same directory the application is executing in? I'm assuming the MountableFile has to be in the current directory (rather than a temporary directory) for some Docker reason. Is that correct?
I'm working on a fix for this issue, and I'll submit once I've verified.
Thanks,
Damien.
The text was updated successfully, but these errors were encountered:
Hi all,
I have a rather obscure issue with how MountableFile is generating the temporary file for copying classpath resources. I occasionally see the following error in my log files -
2017-07-25 18:09:53,920 - [ERROR] - from org.testcontainers.utility.MountableFile in main Failed to extract classpath resource org/testcontainers/DockerClientFactory.class from JAR file /qc/my-app/lib/org.testcontainers.testcontainers-1.4.2.jar java.nio.file.FileAlreadyExistsException: .testcontainers-tmp-wYxDE at sun.nio.fs.UnixException.translateToIOException(UnixException.java:88) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214) at java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434) at java.nio.file.Files.newOutputStream(Files.java:216) at java.nio.file.Files.copy(Files.java:3016) at org.testcontainers.utility.MountableFile.copyFromJarToLocation(MountableFile.java:191) at org.testcontainers.utility.MountableFile.extractClassPathResourceToTempLocation(MountableFile.java:157) at org.testcontainers.utility.MountableFile.resolvePath(MountableFile.java:120) at org.testcontainers.utility.MountableFile.getResolvedPath(MountableFile.java:38) at org.testcontainers.DockerClientFactory.lambda$client$0(DockerClientFactory.java:122) at org.testcontainers.DockerClientFactory$$Lambda$32/976810274.accept(Unknown Source) at org.testcontainers.DockerClientFactory.runInsideDocker(DockerClientFactory.java:225) at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:118) at org.testcontainers.containers.GenericContainer.<init>(GenericContainer.java:116) at org.testcontainers.containers.GenericContainer.<init>(GenericContainer.java:156) at org.testcontainers.containers.BrowserWebDriverContainer.<init>(BrowserWebDriverContainer.java:59) at org.testcontainers.containers.BrowserWebDriverContainer.<init>(BrowserWebDriverContainer.java:70)
I'm running CentOS 7 on an EC2 instance, with Java 8u31.
The code causing the exception is here. Having debugged the issue, it looks like in some cases the temporary directory is created, but fails to be deleted. I'm not sure what the exact cause is. It's possible there's another process watching the directory, causing the directory generated to fail to be deleted, or it's some obscure permissioning issue I've not been able to get to the bottom of.
I'm wondering why it's necessary to call mkdirs() prior to generating the temporary file? Would it make sense to call mkdirs on the parent directory instead, and avoid having to delete the directory generated? Why is it necessary to create the parent directory, given that it's the same directory the application is executing in? I'm assuming the MountableFile has to be in the current directory (rather than a temporary directory) for some Docker reason. Is that correct?
I'm working on a fix for this issue, and I'll submit once I've verified.
Thanks,
Damien.
The text was updated successfully, but these errors were encountered: