[ 
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)

Reply via email to