[
https://issues.apache.org/jira/browse/MRESOLVER-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152323#comment-17152323
]
Michael Osipov edited comment on MRESOLVER-123 at 7/6/20, 9:25 PM:
-------------------------------------------------------------------
[~rreich], can you run the following on your local repo after the project has
built:
{noformat}
osipovmi@deblndw011x:~/.m2/repository
$ find . -name maven-metadata-\*.xml -exec xml sel -t -n -c '//groupId/text()'
{} \; | sort -u > group-ids
osipovmi@deblndw011x:~/.m2/repository
$ wc -l group-ids
106 group-ids
{noformat}?
I am considering to create a fine locking after 1.5.0 on group ids.
was (Author: michael-o):
[~rreich], can you run the following on your local repo after the project has
built:
{noformat}
osipovmi@deblndw011x:~/.m2/repository
$ find . -name maven-metadata-\*.xml -exec xml sel -t -n -c '//groupId/text()'
{} \; | sort -u > group-ids
osipovmi@deblndw011x:~/.m2/repository
$ wc -l group-ids
106 group-ids
{noformat}?
I am consider to create a fine locking after 1.5.0 on group ids
> Provide a global locking sync context
> -------------------------------------
>
> 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
> Attachments: checksum-error-debug.log, mvn-debug-1.4.3-123.txt,
> 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)
