You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Michael Osipov (Jira)" <ji...@apache.org> on 2020/07/02 20:12:00 UTC

[jira] [Comment Edited] (MRESOLVER-123) Concurrency issues

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

Michael Osipov edited comment on MRESOLVER-123 at 7/2/20, 8:11 PM:
-------------------------------------------------------------------

bq. Are you still interested in a log of a successful run?
Yes, please provide the log file. Please also increase the number of threads, I'd like to know whether one might suffer from lock contention. Also, did you notice a change in build time (increase) since this is a global lock? How many builds did you run? [~emueller-coremedia] wrote about 1000 with a few failures. Can you run more to increase the failure probablity?

bq. We would definitely be very happy to see this fix in the next Maven version.

I plan to deliver this with Resolver 1.5.0 and put this into Maven 3.7.0.

bq. Regarding Nexus compatibility, I don't know if we find out where the wrong checksums came from but we might not be the only ones with problems like these, so I hope the checksum option is going to get documented and officially supported.

I am quite certain that the checksum issue is on the Nexus side, but w/o a clean reproducer we cannot report to Sonatype. Also, the checksum option is fully documented now with MRESOLVER-116.


was (Author: michael-o):
bq. Are you still interested in a log of a successful run?
Yes, please provide the log file. Please also increate the number of threads, I'd like to know whether one might suffer from lock contention. Also, did you notice a change in build time (increase) since this is a global lock? How many build did you run? [~emueller-coremedia] wrote about 1000 with a few failures. Can you run more to increase the failure probablity?

bq. We would definitely be very happy to see this fix in the next Maven version.

I plan to deliver this with Resolver 1.5.0 and put this into Maven 3.7.0.

Regarding Nexus compatibility, I don't know if we find out where the wrong checksums came from but we might not be the only ones with problems like these, so I hope the checksum option is going to get documented and officially supported.

I am quite certain that the checksum issue is on the Nexus side, but w/o a clean reproducer we cannot report to Sonatype. Also, the checksum option is fully documented now with MRESOLVER-116.

> 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
>         Attachments: checksum-error-debug.log
>
>
> 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)