[
https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17731667#comment-17731667
]
ASF GitHub Bot commented on MRESOLVER-370:
------------------------------------------
gnodet commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1226865171
##########
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockFactorySupport.java:
##########
@@ -34,6 +35,8 @@
public abstract class NamedLockFactorySupport implements NamedLockFactory {
protected final Logger logger = LoggerFactory.getLogger(getClass());
+ final boolean diagnostic = logger.isDebugEnabled();
Review Comment:
That's a bad idea. Loggers level can be updated at runtime, and the call to
`isDebugEnabled()` should be quite enough to not warrant caching the value.
##########
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockFactorySupport.java:
##########
@@ -34,6 +35,8 @@
public abstract class NamedLockFactorySupport implements NamedLockFactory {
protected final Logger logger = LoggerFactory.getLogger(getClass());
+ final boolean diagnostic = logger.isDebugEnabled();
Review Comment:
That's a bad idea. Loggers level can be updated at runtime, and the call to
`isDebugEnabled()` should be fast enough to not warrant caching the value.
> 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)
