[
https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17731732#comment-17731732
]
ASF GitHub Bot commented on MRESOLVER-370:
------------------------------------------
cstamas commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1227092805
##########
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockSupport.java:
##########
@@ -43,7 +43,7 @@ public abstract class NamedLockSupport implements NamedLock {
public NamedLockSupport(final String name, final NamedLockFactorySupport
factory) {
this.name = name;
this.factory = factory;
- this.state = factory.diagnostic ? new ConcurrentHashMap<>() : null;
+ this.state = factory.isDiagnosticEnabled() ? new ConcurrentHashMap<>()
: null;
Review Comment:
Am actually quite uneasy with this "logger level changes at runtime".... As
named lock instances come and go, but this is possible as well:
```
DI container
|-------------------------------------------------------------|
NamedLockFactory (as is singleton)
|-------------------------------------------------------------|
Session1
|-------------------------------|
Session2
| ---------------------|
Session3
| ---------------------|
NamedLock1
|---------------------------------------------------|
NamedLock2
|-------------|
```
As instances are cached (and ref counted), potentially they can span
multiple sessions even, without any connection to session. IF we would always
obey logger level, we could end up with "incomplete" diag data as well, as
logger debug may be disabled-enabled-disabled-enabled, but if lock instance
spans across all 4 changes, diag map would contain only part of data....
> 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: New Feature
> Components: Resolver
> Reporter: Tamas Cservenak
> Assignee: Tamas Cservenak
> Priority: Major
> Fix For: 1.9.11
>
>
> 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)
