[ 
https://issues.apache.org/jira/browse/MRESOLVER-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17629177#comment-17629177
 ] 

ASF GitHub Bot commented on MRESOLVER-285:
------------------------------------------

cstamas commented on code in PR #216:
URL: https://github.com/apache/maven-resolver/pull/216#discussion_r1014407116


##########
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/providers/FileLockNamedLockFactory.java:
##########
@@ -49,6 +52,33 @@
 {
     public static final String NAME = "file-lock";
 
+    /**
+     * Tweak: on Windows, the presence of {@link 
StandardOpenOption#DELETE_ON_CLOSE} causes concurrency issues. This
+     * flag allows to have it removed from effective flags, at the cost that 
lockfile directory becomes crowded
+     * with 0 byte sized lock files that are never cleaned up. Default value 
is {@code true}.
+     *
+     * @see <a 
href="https://bugs.openjdk.org/browse/JDK-8252883";>JDK-8252883</a>
+     */
+    private static final boolean DELETE_LOCK_FILES = Boolean.parseBoolean(
+            System.getProperty( "aether.named.file-lock.deleteLockFiles", 
Boolean.TRUE.toString() ) );
+
+    /**
+     * Tweak: on Windows, the presence of {@link 
StandardOpenOption#DELETE_ON_CLOSE} causes concurrency issues. This
+     * flag allows to implement similar fix as referenced JDK bug report: 
retry and hope the best. Default value is
+     * 5 attempts (will retry 4 times).
+     *
+     * @see <a 
href="https://bugs.openjdk.org/browse/JDK-8252883";>JDK-8252883</a>
+     */
+    private static final int ATTEMPTS = Integer.parseInt(
+            System.getProperty( "aether.named.file-lock.attempts", "5" ) );
+
+    /**
+     * Tweak: When {@link #ATTEMPTS} used, the amount of milliseconds to sleep 
between subsequent retries. Default
+     * value is 50 milliseconds.
+     */
+    private static final long SLEEP_MILLIS = Long.parseLong(
+            System.getProperty( "aether.named.file-lock.sleepMillis", "50" ) );
+

Review Comment:
   Also, adapter (hence, factory) is created way before session.





> File locking on Windows knows to misbehave
> ------------------------------------------
>
>                 Key: MRESOLVER-285
>                 URL: https://issues.apache.org/jira/browse/MRESOLVER-285
>             Project: Maven Resolver
>          Issue Type: Bug
>          Components: Resolver
>            Reporter: Tamas Cservenak
>            Assignee: Tamas Cservenak
>            Priority: Major
>             Fix For: 1.9.0
>
>
> Maven Mvnd user reported how file locking sporadically knows to fail on 
> Windows.
> Discussion here: [https://github.com/apache/maven-mvnd/issues/728]
> Investigated solutions:
>  * prevent "delete concurrency" 
> [https://github.com/apache/maven-resolver/pull/211] is OK, but has a problem: 
> leaves lock files undeleted
>  * do what Java dolks do: repeat and hope the best 
> [https://github.com/apache/maven-resolver/pull/214] is ? (waiting for 
> response)
>  Related links:
>  * [https://bugs.openjdk.org/browse/JDK-8252883]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to