[ https://issues.apache.org/jira/browse/MRESOLVER-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17148463#comment-17148463 ]
Michael Osipov commented on MRESOLVER-123: ------------------------------------------ The lock has to be in the factory, because it needs to be passed around within calls otherwise it would not lock thread invocations. The exception is weird I do not yet fully understand how this could be related to the locking. Can you enable HTTP wire logs for this build? Something is fishy with the checksums: {noformat} $ curl -sq https://repo1.maven.org/maven2/org/codehaus/plexus/plexus/1.0.10/plexus-1.0.10.pom | sha256sum 09b999a969e73525a6cc3ad2868ea744766e1d93b25c6c656d61a5ff9c881da9 - {noformat} But for some reason Resolver hs calculated: {{1bcea46372e9256cbeb68b1bde54a4730120cf6e135861abe76272e5107ede9c}}. I will try this build with our Nexus instance at work too: 2.14.18. > Concurrency issues > ------------------ > > Key: MRESOLVER-123 > URL: https://issues.apache.org/jira/browse/MRESOLVER-123 > Project: Maven Resolver > Issue Type: Bug > Components: resolver > Affects Versions: 1.4.2 > Reporter: Michael Osipov > Priority: Critical > > 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 message was sent by Atlassian Jira (v8.3.4#803005)