[ https://issues.apache.org/jira/browse/MRESOLVER-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17174068#comment-17174068 ]
Dan Tran edited comment on MRESOLVER-123 at 8/10/20, 4:21 AM: -------------------------------------------------------------- some thing like below {code:java} [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project xxxxxxx: Compilation failure: Compilation failure: [ERROR] /path/to/a/java/file.java:[16,35] package x.y.z does not exist {code} The package paths include both internal and external packages and it is not possible to see if they can occur without lock ( too slow) was (Author: dantran): some thing like below {code:java} [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project xxxxxxx: Compilation failure: Compilation failure: [ERROR] /path/to/a/java/file.java:[16,35] package x.y.z does not exist {code} The package paths include both internal and external packages and it is not possible to see if they can occur without lock ( to slow) > Provide a global locking sync context by default > ------------------------------------------------ > > Key: MRESOLVER-123 > URL: https://issues.apache.org/jira/browse/MRESOLVER-123 > Project: Maven Resolver > Issue Type: New Feature > Components: resolver > Affects Versions: 1.4.2 > Reporter: Michael Osipov > Assignee: Michael Osipov > Priority: Critical > Fix For: 1.5.0 > > Attachments: checksum-error-debug.log, mvn-debug-1.4.3-123.txt.gz > > > This is an umbrella ticket for a long standing issue with Maven Resolver: Our > concurrency support is mediocre in a way that if two or more threads try to > download the same file and fail to queue those write actions nicely. The > problem is that The {{SyncContext}} and the its factory provided by Maven > Resolver does not employ any locking at all. As layed out in detail in > MRESOLVER-114 we need striped read write locks on artifacts and its metadata. > This issue shall track progress on it. Even Takari Concurrent Repository > extension does not help because it is only intended to synchronize concurrent > access by multple JVMs and not threads. > This improvement will provide solely a global locking sync context which will > work in *single* JVM. It is a non-goal to make it work with mulitple JVMs. A > downside of this solution is that is coarse, possible degregation of > performance for the sake of stability. -- This message was sent by Atlassian Jira (v8.3.4#803005)