[ https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17731613#comment-17731613 ]
ASF GitHub Bot commented on MRESOLVER-370: ------------------------------------------ gnodet commented on code in PR #299: URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1226656453 ########## maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockSupport.java: ########## @@ -32,18 +38,76 @@ public abstract class NamedLockSupport implements NamedLock { private final NamedLockFactorySupport factory; + private final ConcurrentHashMap<Thread, Deque<String>> state; + public NamedLockSupport(final String name, final NamedLockFactorySupport factory) { this.name = name; this.factory = factory; + this.state = factory.diagnostic ? new ConcurrentHashMap<>() : null; } @Override public String name() { return name; } + @Override + public boolean lockShared(long time, TimeUnit unit) throws InterruptedException { + if (state != null) { + state.computeIfAbsent(Thread.currentThread(), k -> new ArrayDeque<>()) + .push("S"); Review Comment: if we don't expect more than a few locks per thread at the same time, I would use `shared` and `exclusive`, it will not require the reader to go back to the source to understand what S/X means. > Lock factory should dump lock states on failure > ----------------------------------------------- > > Key: MRESOLVER-370 > URL: https://issues.apache.org/jira/browse/MRESOLVER-370 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver > Reporter: Tamas Cservenak > Priority: Major > > When adapter "gives up" (as it could not acquire required lock), the error > currently states "how many retries were against which lock". This gives > information only about failed lock, but lacks the "whole picture". > Proposed change: in case of lock failure, factory should dump out all lock > states (may be huge on big builds), as that would allow simpler > identification of possible problems. All this could be sorted out at "high > level" (so no need to fiddle with file locks, hazelcast or redisson), but for > memory constraints it should NOT be enabled by default, this "diagnostic" > should be turned off by default, but possible by users to turn on if needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)