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:
$ curl -sq 
 | sha256sum
09b999a969e73525a6cc3ad2868ea744766e1d93b25c6c656d61a5ff9c881da9  -
But for some reason Resolver hs calculated: 

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

Reply via email to