[
https://issues.apache.org/jira/browse/MRESOLVER-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339136#comment-17339136
]
Tamás Cservenák edited comment on MRESOLVER-179 at 5/4/21, 4:44 PM:
--------------------------------------------------------------------
Loosely related to this is planned change
[https://github.com/apache/maven-resolver/pull/97] (PR is just a rough draft)
that makes things more obvious (currently sorting is done by NameMapper) and
better on spot (IMO, doing this in NameMapper is eror prone, easy to forget and
hard to find as happened here). Idea of ResolverLock is to make things more
obvious.
was (Author: cstamas):
Loosely related to this change
[https://github.com/apache/maven-resolver/pull/97] that makes things more
obvious (currently sorting is done by NameMapper) and better on spot (IMO,
doing this in NameMapper is eror prone, easy to forget and hard to find as
happened here). Idea of ResolverLock is to make things more obvious.
> NamedLocks should be acquired in an ordered way
> -----------------------------------------------
>
> Key: MRESOLVER-179
> URL: https://issues.apache.org/jira/browse/MRESOLVER-179
> Project: Maven Resolver
> Issue Type: Bug
> Reporter: Guillaume Nodet
> Priority: Major
>
> [~michael-o] [~cstamas] I was about to start porting my simple SyncContext to
> maven-resolver and start working on a PR when I saw that the API has changed
> a lot with the introduction of NamedLocks.
> I see some design problems in the new API. Multiple locks are now acquired in
> sequence instead of using a coarse grained call. This can lead to deadlocks
> as one client could try to lock {{a}} then {{b}} while another one could try
> to lock {{b}} then {{a}}, leading to a possible deadlock.
> It should be just a matter to order them inside the
> {{AdaptedLockSyncContext.acquire}} call which is the only location where the
> API is used.
> I'll provide a PR asap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
