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
We have 20+ Jib Maven projects that normally build successfully on our Windows laptops, but intermittently (every 10 builds or less) fail with AccessDeniedException indicating a file move from the user's tmpdir to the Jib application cache. Please see the Maven log excerpt below with the stack trace (using mvn -X). The failure happens to us often when using Maven Jib from "skaffold dev", due to the large number of builds done as code is changed.
Expected behavior:
Builds succeed consistently.
Steps to reproduce:
Run mvn -X -l jib.log -pl :<child module name> -am -DskipTests package jib:build -Djib.containerize=:<child module name> up to 10 times in Maven root project dir.
Caused by: java.nio.file.AccessDeniedException: C:\Users\xxx\AppData\Local\Temp\13220281918294591275.tmp -> C:\Users\xxx\git\fork\prj-fork\prj-web\target\jib-cache\selectors\03c4a7469349f7d32e62b59980815fa56031a31f405e9490fd6ec3d28d51770c
at sun.nio.fs.WindowsException.translateToIOException (WindowsException.java:89)
at sun.nio.fs.WindowsException.rethrowAsIOException (WindowsException.java:103)
at sun.nio.fs.WindowsFileCopy.move (WindowsFileCopy.java:317)
at sun.nio.fs.WindowsFileSystemProvider.move (WindowsFileSystemProvider.java:293)
at java.nio.file.Files.move (Files.java:1432)
at com.google.cloud.tools.jib.cache.CacheStorageWriter.writeSelector (CacheStorageWriter.java:471)
at com.google.cloud.tools.jib.cache.CacheStorageWriter.writeUncompressed (CacheStorageWriter.java:300)
at com.google.cloud.tools.jib.cache.Cache.writeUncompressedLayer (Cache.java:145)
at com.google.cloud.tools.jib.builder.steps.BuildAndCacheApplicationLayerStep.call (BuildAndCacheApplicationLayerStep.java:108)
at com.google.cloud.tools.jib.builder.steps.BuildAndCacheApplicationLayerStep.call (BuildAndCacheApplicationLayerStep.java:38)
at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly (TrustedListenableFutureTask.java:131)
at com.google.common.util.concurrent.InterruptibleTask.run (InterruptibleTask.java:75)
at com.google.common.util.concurrent.TrustedListenableFutureTask.run (TrustedListenableFutureTask.java:82)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1136)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:635)
at java.lang.Thread.run (Thread.java:840)
Additional Information:
This looks like a combination of issue #1635 and #3572. It is happening to us with AccessDeniedException (rather than e.g. FileAlreadyExistsException) and in jib-cache/selectors rather than in jib-cache/layers.
We tried the following with no success:
Changing the application cache location (the move destination)
Changing the tmpdir location (the move source - MAVEN_OPTS=-Djava.io.tmpdir=...)
Closing all apps and signing out and signing back in
I think that multiple places in the Jib code were updated to use moveIfDoesNotExist and its retry logic, e.g. the code for jib-cache/layers, but not writeSelector and jib-cache/selectors. Could writeSelector use the same moveIfDoesNotExist retry approach?
The text was updated successfully, but these errors were encountered:
@chanseokoh - thanks for taking a look! I see you what you mean now - that writeSelector requires different logic from moveIfDoesNotExist. I'm thinking retry would help writeSelector, because we are only seeing the AccessDeniedException on the selectors directory and not anywhere else (like layers), so if retry is used for the layers directory, it's probably helping there.
Environment:
Description of the issue:
We have 20+ Jib Maven projects that normally build successfully on our Windows laptops, but intermittently (every 10 builds or less) fail with AccessDeniedException indicating a file move from the user's tmpdir to the Jib application cache. Please see the Maven log excerpt below with the stack trace (using mvn -X). The failure happens to us often when using Maven Jib from "skaffold dev", due to the large number of builds done as code is changed.
Expected behavior:
Builds succeed consistently.
Steps to reproduce:
Run
mvn -X -l jib.log -pl :<child module name> -am -DskipTests package jib:build -Djib.containerize=:<child module name>
up to 10 times in Maven root project dir.jib-maven-plugin
Configuration:Log output:
Additional Information:
This looks like a combination of issue #1635 and #3572. It is happening to us with AccessDeniedException (rather than e.g. FileAlreadyExistsException) and in jib-cache/selectors rather than in jib-cache/layers.
We tried the following with no success:
MAVEN_OPTS=-Djava.io.tmpdir=...
)I think that multiple places in the Jib code were updated to use moveIfDoesNotExist and its retry logic, e.g. the code for jib-cache/layers, but not writeSelector and jib-cache/selectors. Could writeSelector use the same moveIfDoesNotExist retry approach?
The text was updated successfully, but these errors were encountered: