Randomly failing maven build with WindowsException

Description of the issue: From time to time I get the following exception failing the build. It seems Windows related with some cache access error. The root exception I get is AccessDeniedException based on some WindowsExceptions. It happens quite often when the build runs through very fast. When I’m on battery with my laptop (slower CPU freq) the error doesn’t occur. Could this also be due to some concurrency in jib during the build?

Caused by: java.nio.file.AccessDeniedException: C:\Users\I506803\examples\personservice\target\jib-cache\tmp\4235202945488612732 -> C:\Users\I506803\examples\personservice\target\jib-cache\layers\b4617547f616e55fb347a9d4cf7db25dc27bf11608a4e6ef749c13df3334538b
    at sun.nio.fs.WindowsException.translateToIOException (WindowsException.java:83)
    at sun.nio.fs.WindowsException.rethrowAsIOException (WindowsException.java:97)
    at sun.nio.fs.WindowsFileCopy.move (WindowsFileCopy.java:387)
    at sun.nio.fs.WindowsFileSystemProvider.move (WindowsFileSystemProvider.java:287)
    at java.nio.file.Files.move (Files.java:1395)
    at com.google.cloud.tools.jib.cache.DefaultCacheStorageWriter.moveIfDoesNotExist (DefaultCacheStorageWriter.java:74)
    at com.google.cloud.tools.jib.cache.DefaultCacheStorageWriter.write (DefaultCacheStorageWriter.java:184)
    at com.google.cloud.tools.jib.cache.DefaultCacheStorage.write (DefaultCacheStorage.java:69)
    at com.google.cloud.tools.jib.cache.Cache.writeUncompressedLayer (Cache.java:82)
    at com.google.cloud.tools.jib.builder.steps.BuildAndCacheApplicationLayerStep.call (BuildAndCacheApplicationLayerStep.java:138)
    at com.google.cloud.tools.jib.builder.steps.BuildAndCacheApplicationLayerStep.call (BuildAndCacheApplicationLayerStep.java:40)
    at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly (TrustedListenableFutureTask.java:125)
    at com.google.common.util.concurrent.InterruptibleTask.run (InterruptibleTask.java:57)
    at com.google.common.util.concurrent.TrustedListenableFutureTask.run (TrustedListenableFutureTask.java:78)
    at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:624)
    at java.lang.Thread.run (Thread.java:748)
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

Steps to reproduce: Build container on Windows. Still hard to reproduce since the bug occurs randomly.

Environment: jib-maven-plugin 1.0.2, Windows 10

jib-maven-plugin Configuration:

<plugin>
	<groupId>com.google.cloud.tools</groupId>
	<artifactId>jib-maven-plugin</artifactId>
	<version>${jib.version}</version>
	<configuration>
		<to>
			<image>registry.hub.docker.com/${docker.repositoryname}/mongokubernetes:${project.version}</image>
			<credHelper>${jib.credentialhelper}</credHelper>
		</to>
	</configuration>
	<executions>
		<execution>
			<phase>package</phase>
			<goals>
				<goal>build</goal>
			</goals>
		</execution>
	</executions>
</plugin>

[adelinor]

@chanseokoh ,

• Yes indeed with version 2.7.1. To be more precise I was on version 2.6.0 until I got 3 consecutive build failures because of the AccessDeniedException. I upgraded but it was the same issue still.
• I set the path under the c drive where I keep tooling caches such as the local maven repo
• I can’t turn off the antivirus as I do not have rights 😦
• the new location is potentially not treated the same by the antivirus software

[chanseokoh]

I don’t think this is a concurrency issue, if you are not running multiple Jib builds in parallel or building a multi-module project. There was a similar case before (#1438), and the cause was an anti-virus software. Make sure you close any file explorer (from my experience, if you have ever opened a folder in an explorer, then even if you close and navigate away from the folder, I’ve seen cases where you cannot delete the folder until you close the explorer) and any command line windows, and disable anti-virus.

For further testing, you can do mvn -Djib.serialize=true ... to run a build serially. You can also use -Djib.applicationCache=... to use a different application cache directory than target/jib-cache (https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin#system-properties).

---

UPDATE: if the problematic directory is not an application cache directory (cache for your single project) but the central base image cache shared across Jib projects on the same machine (like in #3740), you’d try -Djib.baseImageCache=... instead of -Djib.applicationCache=... for testing. However, remember that this is changing the shared cache, so if you decide to do this for a short-term solution, you’ll want to set this for all Jib runs across projects to benefit the cache.