[JBoss JIRA] (LOGMGR-260) System loggers run with level ALL
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-260?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-260:
--------------------------------------
I do think this is a valid fix, however I noticed while looking at this with JBoss Modules the {{org.jboss.logmanager.JBossLoggerFinder}} doesn't work because it's not found on the system class path. I don't think this is fixable in the log manager. If it was fixed though this wouldn't be an issue.
> System loggers run with level ALL
> ---------------------------------
>
> Key: LOGMGR-260
> URL: https://issues.jboss.org/browse/LOGMGR-260
> Project: JBoss Log Manager
> Issue Type: Bug
> Components: core
> Environment: Java 9+
> Reporter: Philippe Marschall
> Priority: Major
>
> After migrating to Java 11 we were suddenly seeing a lot of caught exceptions {{sun.rmi.runtime.Log#getSource()}}. This was surprising to use because we WildFly which sets the "sun.rmi" logger to level WARN. Upon closer inspection the issue is that the logger used by {{sun.rmi.runtime.Log}} has level ALL ({{Integer#MIN_VALUE}}).
> The issue for this seems to be the following:
> # since Java 9 java.util.logging differentiates between system loggers (used by modules in the platform classloader) and user loggers (everything else), see {{java.util.logging#Logger.demandLogger(String, String, Class<?>)}}
> # when a system logger is created a second user logger is created and their configurations are merged, however they are merged based on internal state maintained by {{#setLevel(Level)}}, see {{java.util.logging.LogManager#demandSystemLogger(String, String, Module)}} and {{java.util.logging.Logger#mergeWithSystemLogger(Logger)}}
> # {{org.jboss.logmanager.Logger}} only ends up calling {{#setLevel(Level)}} with {{Level.ALL}} therefore the resulting system logger always has the level ALL
> The issue is quite hard to test because:
> # the effect only happens when the caller of {{#getLoggger(String)}} is a system module
> # the log output is not different, only {{#isLoggable(Level)}} checks that shouldn't succeed suddenly succeed so you only see the overhead
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFLY-12581) Optimize distributed web/ejb expiration schedulers
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12581?page=com.atlassian.jira.plugin... ]
Paul Ferraro edited comment on WFLY-12581 at 9/25/19 3:39 PM:
--------------------------------------------------------------
Attached some perf comparisons of new scheduler implementations vs current implementations for both distributed and local workloads. The charts plot the elapsed time for N concurrent clients to perform a large number of insert/disable/remove operations.
was (Author: pferraro):
Attached some perf comparisons of new scheduler implementations vs current implementations for both distributed and local workloads.
> Optimize distributed web/ejb expiration schedulers
> --------------------------------------------------
>
> Key: WFLY-12581
> URL: https://issues.jboss.org/browse/WFLY-12581
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 18.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: Schedulers for distributed workloads.png, Schedulers for local workloads.png
>
>
> WFLY-12321 added a new expiration scheduler implementation for SFSBs specifically optimized for non-distributed environments. The key features of this implementations are:
> * Uses a single scheduled task instead of a scheduled task per SFSB
> * Uses a double-linked list to track SFSBs to be expired
> Because most scheduled tasks will be canceled before they are executed, the performance of a given scheduler implementation is primarily limited by the cost of insertion and removal into the backing data structure. The goal of this jira is to generalize the scheduler implementation introduced by WFLY-12321 such that it can be used for scheduling of both local and distributed web sessions and SFSBs.
> In the scheduler implemented as part of WFLY-12321, the use of a linked queue is based on the following assumptions:
> # All SFSB using a given scheduler use the same @StatefulTimeout
> # A given call to Scheduler.schedule(...) is always the last item to be scheduled
> Unfortunately, the second assumption is not valid for distributed SFSBs as a member may assume the responsibility of expiring a SFSB previously owned by another member.
> Additionally, the second assumption is not valid for local nor distributed web sessions, as a given web session can override the default session timeout of the application.
> This jira proposes the following:
> * Generalize the Scheduler interface for reuse between SFSBs and web sessions.
> * Generalize the new local scheduler implementation such that the same scheduler can support both local and distributed objects using different data structures for tracking scheduled items
> * Replace ExpirationTracker with a ConcurrentDirectDeque to support local case, which has O(1) add/remove characteristics
> ** ConcurrentDirectDeque outperforms ExpirationTracker under concurrent load (see attached graph)
> * Local web sessions and all distributed use cases will store scheduled entries within a ConcurrentSkipListSet, which has O(log N) add/remove characteristics
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFLY-12581) Optimize distributed web/ejb expiration schedulers
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12581?page=com.atlassian.jira.plugin... ]
Paul Ferraro updated WFLY-12581:
--------------------------------
Description:
WFLY-12321 added a new expiration scheduler implementation for SFSBs specifically optimized for non-distributed environments. The key features of this implementations are:
* Uses a single scheduled task instead of a scheduled task per SFSB
* Uses a double-linked list to track SFSBs to be expired
Because most scheduled tasks will be canceled before they are executed, the performance of a given scheduler implementation is primarily limited by the cost of insertion and removal into the backing data structure. The goal of this jira is to generalize the scheduler implementation introduced by WFLY-12321 such that it can be used for scheduling of both local and distributed web sessions and SFSBs.
In the scheduler implemented as part of WFLY-12321, the use of a linked queue is based on the following assumptions:
# All SFSB using a given scheduler use the same @StatefulTimeout
# A given call to Scheduler.schedule(...) is always the last item to be scheduled
Unfortunately, the second assumption is not valid for distributed SFSBs as a member may assume the responsibility of expiring a SFSB previously owned by another member.
Additionally, the second assumption is not valid for local nor distributed web sessions, as a given web session can override the default session timeout of the application.
This jira proposes the following:
* Generalize the Scheduler interface for reuse between SFSBs and web sessions.
* Generalize the new local scheduler implementation such that the same scheduler can support both local and distributed objects using different data structures for tracking scheduled items
* Replace ExpirationTracker with a ConcurrentDirectDeque to support local case, which has O(1) add/remove characteristics
** ConcurrentDirectDeque outperforms ExpirationTracker under concurrent load (see attached graph)
* Local web sessions and all distributed use cases will store scheduled entries within a ConcurrentSkipListSet, which has O(log N) add/remove characteristics
was:
WF18 added a new expiration scheduler implementation for SFSBs specifically optimized for non-distributed environments. The key features of this implementations are:
* Uses a single scheduled task instead of a scheduled task per SFSB
* Uses a double-linked list to track SFSBs to be expired
Because most scheduled tasks will be canceled before they are executed, the performance of a given scheduler implementation is primarily limited by the cost of insertion and removal into the backing data structure. The goal of this jira is to generalize the scheduler implementation introduced by WFLY-12321 such that it can be used for scheduling of both local and distributed objects.
The use of a linked queue is based on the following assumptions:
# All SFSB using a given scheduler share the same @StatefulTimeout
# A given call to Scheduler.schedule(...) is always the last item to be scheduled
Distributed SFSBs cannot use the same implementation because the second assumption is not valid, as a member may assume the responsibility of expiring a SFSB previously owned by another member. They can, however, leverage the strategy of using a single scheduled task instead of a task per SFSB. Due to the nature of the scheduler, that most scheduled tasks will be cancelled/removed and rescheduled, this strategy outperforms the current implementation.
This jira proposes the following:
* Generalize the Scheduler interface for reuse between SFSBs and web sessions.
* Generalize the new local scheduler implementation such that the same scheduler can support both local and distributed SFSBs using different queue implementations for tracking scheduled items
* Distributed use case uses a DelayQueue, which has O(log N) add/remove characteristics
* Replace ExpirationTracker with a ConcurrentDirectDeque to support local case, which has O(1) add/remove characteristics
** ConcurrentDirectDeque outperforms ExpirationTracker under concurrent load
Local web session expiration cannot use the same expiration scheduler used by local SFSBs because the first assumption is not valid, since a given web session can override the default max inactive interval. However, we can still optimize the local web session case by delegating expiration to the PriorityBlockingQueue-based implementation if the session uses a non-default max inactive interval, and to the ConcurrentDirectDeque-based implementation if the session uses the default max inactive interval.
> Optimize distributed web/ejb expiration schedulers
> --------------------------------------------------
>
> Key: WFLY-12581
> URL: https://issues.jboss.org/browse/WFLY-12581
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 18.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: Schedulers for distributed workloads.png, Schedulers for local workloads.png
>
>
> WFLY-12321 added a new expiration scheduler implementation for SFSBs specifically optimized for non-distributed environments. The key features of this implementations are:
> * Uses a single scheduled task instead of a scheduled task per SFSB
> * Uses a double-linked list to track SFSBs to be expired
> Because most scheduled tasks will be canceled before they are executed, the performance of a given scheduler implementation is primarily limited by the cost of insertion and removal into the backing data structure. The goal of this jira is to generalize the scheduler implementation introduced by WFLY-12321 such that it can be used for scheduling of both local and distributed web sessions and SFSBs.
> In the scheduler implemented as part of WFLY-12321, the use of a linked queue is based on the following assumptions:
> # All SFSB using a given scheduler use the same @StatefulTimeout
> # A given call to Scheduler.schedule(...) is always the last item to be scheduled
> Unfortunately, the second assumption is not valid for distributed SFSBs as a member may assume the responsibility of expiring a SFSB previously owned by another member.
> Additionally, the second assumption is not valid for local nor distributed web sessions, as a given web session can override the default session timeout of the application.
> This jira proposes the following:
> * Generalize the Scheduler interface for reuse between SFSBs and web sessions.
> * Generalize the new local scheduler implementation such that the same scheduler can support both local and distributed objects using different data structures for tracking scheduled items
> * Replace ExpirationTracker with a ConcurrentDirectDeque to support local case, which has O(1) add/remove characteristics
> ** ConcurrentDirectDeque outperforms ExpirationTracker under concurrent load (see attached graph)
> * Local web sessions and all distributed use cases will store scheduled entries within a ConcurrentSkipListSet, which has O(log N) add/remove characteristics
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFLY-12581) Optimize distributed web/ejb expiration schedulers
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12581?page=com.atlassian.jira.plugin... ]
Paul Ferraro updated WFLY-12581:
--------------------------------
Description:
WF18 added a new expiration scheduler implementation for SFSBs specifically optimized for non-distributed environments. The key features of this implementations are:
* Uses a single scheduled task instead of a scheduled task per SFSB
* Uses a double-linked list to track SFSBs to be expired
Because most scheduled tasks will be canceled before they are executed, the performance of a given scheduler implementation is primarily limited by the cost of insertion and removal into the backing data structure. The goal of this jira is to generalize the scheduler implementation introduced by WFLY-12321 such that it can be used for scheduling of both local and distributed objects.
The use of a linked queue is based on the following assumptions:
# All SFSB using a given scheduler share the same @StatefulTimeout
# A given call to Scheduler.schedule(...) is always the last item to be scheduled
Distributed SFSBs cannot use the same implementation because the second assumption is not valid, as a member may assume the responsibility of expiring a SFSB previously owned by another member. They can, however, leverage the strategy of using a single scheduled task instead of a task per SFSB. Due to the nature of the scheduler, that most scheduled tasks will be cancelled/removed and rescheduled, this strategy outperforms the current implementation.
This jira proposes the following:
* Generalize the Scheduler interface for reuse between SFSBs and web sessions.
* Generalize the new local scheduler implementation such that the same scheduler can support both local and distributed SFSBs using different queue implementations for tracking scheduled items
* Distributed use case uses a DelayQueue, which has O(log N) add/remove characteristics
* Replace ExpirationTracker with a ConcurrentDirectDeque to support local case, which has O(1) add/remove characteristics
** ConcurrentDirectDeque outperforms ExpirationTracker under concurrent load
Local web session expiration cannot use the same expiration scheduler used by local SFSBs because the first assumption is not valid, since a given web session can override the default max inactive interval. However, we can still optimize the local web session case by delegating expiration to the PriorityBlockingQueue-based implementation if the session uses a non-default max inactive interval, and to the ConcurrentDirectDeque-based implementation if the session uses the default max inactive interval.
was:
WF18 added a new expiration scheduler implementation for SFSBs specifically optimized for non-distributed environments. The key features of this implementations are:
* Uses a single scheduled task instead of a scheduled task per SFSB
* Uses a double-linked list to track SFSBs to be expired
The use of a linked queue is based on the following assumptions:
# All SFSB using a given scheduler share the same @StatefulTimeout
# A given call to Scheduler.schedule(...) is always the last item to be scheduled
Distributed SFSBs cannot use the same implementation because the second assumption is not valid, as a member may assume the responsibility of expiring a SFSB previously owned by another member. They can, however, leverage the strategy of using a single scheduled task instead of a task per SFSB. Due to the nature of the scheduler, that most scheduled tasks will be cancelled/removed and rescheduled, this strategy outperforms the current implementation.
This jira proposes the following:
* Generalize the Scheduler interface for reuse between SFSBs and web sessions.
* Generalize the new local scheduler implementation such that the same scheduler can support both local and distributed SFSBs using different queue implementations for tracking scheduled items
* Distributed use case uses a DelayQueue, which has O(log N) add/remove characteristics
* Replace ExpirationTracker with a ConcurrentDirectDeque to support local case, which has O(1) add/remove characteristics
** ConcurrentDirectDeque outperforms ExpirationTracker under concurrent load
Local web session expiration cannot use the same expiration scheduler used by local SFSBs because the first assumption is not valid, since a given web session can override the default max inactive interval. However, we can still optimize the local web session case by delegating expiration to the PriorityBlockingQueue-based implementation if the session uses a non-default max inactive interval, and to the ConcurrentDirectDeque-based implementation if the session uses the default max inactive interval.
> Optimize distributed web/ejb expiration schedulers
> --------------------------------------------------
>
> Key: WFLY-12581
> URL: https://issues.jboss.org/browse/WFLY-12581
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 18.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: Schedulers for distributed workloads.png, Schedulers for local workloads.png
>
>
> WF18 added a new expiration scheduler implementation for SFSBs specifically optimized for non-distributed environments. The key features of this implementations are:
> * Uses a single scheduled task instead of a scheduled task per SFSB
> * Uses a double-linked list to track SFSBs to be expired
> Because most scheduled tasks will be canceled before they are executed, the performance of a given scheduler implementation is primarily limited by the cost of insertion and removal into the backing data structure. The goal of this jira is to generalize the scheduler implementation introduced by WFLY-12321 such that it can be used for scheduling of both local and distributed objects.
> The use of a linked queue is based on the following assumptions:
> # All SFSB using a given scheduler share the same @StatefulTimeout
> # A given call to Scheduler.schedule(...) is always the last item to be scheduled
> Distributed SFSBs cannot use the same implementation because the second assumption is not valid, as a member may assume the responsibility of expiring a SFSB previously owned by another member. They can, however, leverage the strategy of using a single scheduled task instead of a task per SFSB. Due to the nature of the scheduler, that most scheduled tasks will be cancelled/removed and rescheduled, this strategy outperforms the current implementation.
> This jira proposes the following:
> * Generalize the Scheduler interface for reuse between SFSBs and web sessions.
> * Generalize the new local scheduler implementation such that the same scheduler can support both local and distributed SFSBs using different queue implementations for tracking scheduled items
> * Distributed use case uses a DelayQueue, which has O(log N) add/remove characteristics
> * Replace ExpirationTracker with a ConcurrentDirectDeque to support local case, which has O(1) add/remove characteristics
> ** ConcurrentDirectDeque outperforms ExpirationTracker under concurrent load
> Local web session expiration cannot use the same expiration scheduler used by local SFSBs because the first assumption is not valid, since a given web session can override the default max inactive interval. However, we can still optimize the local web session case by delegating expiration to the PriorityBlockingQueue-based implementation if the session uses a non-default max inactive interval, and to the ConcurrentDirectDeque-based implementation if the session uses the default max inactive interval.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (DROOLS-4565) MVELDialectRuntimeData is not thread safe
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4565?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-4565:
-------------------------------------
I'll give a look but it would be very helpful if you could provide a reproducer for this.
> MVELDialectRuntimeData is not thread safe
> -----------------------------------------
>
> Key: DROOLS-4565
> URL: https://issues.jboss.org/browse/DROOLS-4565
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.16.0.Final
> Environment: Java 11.0.2
> Different OS
> Reporter: Timo Gutjahr
> Assignee: Mario Fusco
> Priority: Major
> Attachments: ForkJoinPool-1-worker-1.txt, NPE.txt
>
>
> MVELDialectRuntimeData#mvelReaders is accessed concurrently but is not thread safe due to the usage of a HashSet. This may cause lost updates. (See [^ForkJoinPool-1-worker-1.txt] )
> If this happens and the kie base is serialized and deserialized it results in a NullPointerException at runtime. (See [^NPE.txt] )
> We observed that the entries in this Set (mvelReaders) are serialized and important for the deserialization step because they contain information about transient objects that have to be re-initialized after deserialization.
> While losing this information due to concurrent access does not cause problems during compilation, serialization and deserialization of a kie base, they may cause NullPointerExceptions at runtime when transient fields remain uninitialized.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (DROOLS-4565) MVELDialectRuntimeData is not thread safe
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4565?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-4565:
--------------------------------
Sprint: 2019 Week 38-40 (from Sep 16)
> MVELDialectRuntimeData is not thread safe
> -----------------------------------------
>
> Key: DROOLS-4565
> URL: https://issues.jboss.org/browse/DROOLS-4565
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.16.0.Final
> Environment: Java 11.0.2
> Different OS
> Reporter: Timo Gutjahr
> Assignee: Mario Fusco
> Priority: Major
> Attachments: ForkJoinPool-1-worker-1.txt, NPE.txt
>
>
> MVELDialectRuntimeData#mvelReaders is accessed concurrently but is not thread safe due to the usage of a HashSet. This may cause lost updates. (See [^ForkJoinPool-1-worker-1.txt] )
> If this happens and the kie base is serialized and deserialized it results in a NullPointerException at runtime. (See [^NPE.txt] )
> We observed that the entries in this Set (mvelReaders) are serialized and important for the deserialization step because they contain information about transient objects that have to be re-initialized after deserialization.
> While losing this information due to concurrent access does not cause problems during compilation, serialization and deserialization of a kie base, they may cause NullPointerExceptions at runtime when transient fields remain uninitialized.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (AG-126) Don't store suppliers on the configuration
by Luis Barreiro (Jira)
Luis Barreiro created AG-126:
--------------------------------
Summary: Don't store suppliers on the configuration
Key: AG-126
URL: https://issues.jboss.org/browse/AG-126
Project: Agroal
Issue Type: Bug
Components: api
Affects Versions: 1.5
Reporter: Luis Barreiro
Assignee: Luis Barreiro
Fix For: 1.6
Having suppliers in the configuration causes a validation each time there is an access.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (LOGMGR-260) System loggers run with level ALL
by Philippe Marschall (Jira)
[ https://issues.jboss.org/browse/LOGMGR-260?page=com.atlassian.jira.plugin... ]
Philippe Marschall updated LOGMGR-260:
--------------------------------------
Description:
After migrating to Java 11 we were suddenly seeing a lot of caught exceptions {{sun.rmi.runtime.Log#getSource()}}. This was surprising to use because we WildFly which sets the "sun.rmi" logger to level WARN. Upon closer inspection the issue is that the logger used by {{sun.rmi.runtime.Log}} has level ALL ({{Integer#MIN_VALUE}}).
The issue for this seems to be the following:
# since Java 9 java.util.logging differentiates between system loggers (used by modules in the platform classloader) and user loggers (everything else), see {{java.util.logging#Logger.demandLogger(String, String, Class<?>)}}
# when a system logger is created a second user logger is created and their configurations are merged, however they are merged based on internal state maintained by {{#setLevel(Level)}}, see {{java.util.logging.LogManager#demandSystemLogger(String, String, Module)}} and {{java.util.logging.Logger#mergeWithSystemLogger(Logger)}}
# {{org.jboss.logmanager.Logger}} only ends up calling {{#setLevel(Level)}} with {{Level.ALL}} therefore the resulting system logger always has the level ALL
The issue is quite hard to test because:
# the effect only happens when the caller of {{#getLoggger(String)}} is a system module
# the log output is not different, only {{#isLoggable(Level)}} checks that shouldn't succeed suddenly succeed so you only see the overhead
was:
After migrating to Java 11 we were suddenly seeing a lot of caught exceptions {{sun.rmi.runtime.Log#getSource()}}. This was surprising to use because we use WildFly which sets the "sun.rmi" logger to level WARN. Upon closer inspection the issue is that the logger used by {{sun.rmi.runtime.Log}} has level ALL ({{Integer#MIN_VALUE}}).
The issue for this seems to be the following:
# since Java 9 java.util.logging differentiates between system loggers (used by modules in the platform classloader) and user loggers (everything else), see {{java.util.logging#Logger.demandLogger(String, String, Class<?>)}}
# when a system logger is created a second user logger is created and their configurations merge, however they are merged based on internal state maintained by {{#setLevel(Level)}}, see {{java.util.logging.LogManager#demandSystemLogger(String, String, Module)}} and {{java.util.logging.Logger#mergeWithSystemLogger(Logger)}}
# {{org.jboss.logmanager.Logger}} only ends up calling {{#setLevel(Level)}} with {{Level.ALL}} therefore the resulting system logger always has the level ALL
The issue is quite hard to test because:
# the effect only happens when the caller of {{#getLoggger(String)}} is a system module
# the log output is not different, only {{#isLoggable(Level)}} checks that shouldn't succeed suddenly succeed so you only see the overhead
> System loggers run with level ALL
> ---------------------------------
>
> Key: LOGMGR-260
> URL: https://issues.jboss.org/browse/LOGMGR-260
> Project: JBoss Log Manager
> Issue Type: Bug
> Components: core
> Environment: Java 9+
> Reporter: Philippe Marschall
> Priority: Major
>
> After migrating to Java 11 we were suddenly seeing a lot of caught exceptions {{sun.rmi.runtime.Log#getSource()}}. This was surprising to use because we WildFly which sets the "sun.rmi" logger to level WARN. Upon closer inspection the issue is that the logger used by {{sun.rmi.runtime.Log}} has level ALL ({{Integer#MIN_VALUE}}).
> The issue for this seems to be the following:
> # since Java 9 java.util.logging differentiates between system loggers (used by modules in the platform classloader) and user loggers (everything else), see {{java.util.logging#Logger.demandLogger(String, String, Class<?>)}}
> # when a system logger is created a second user logger is created and their configurations are merged, however they are merged based on internal state maintained by {{#setLevel(Level)}}, see {{java.util.logging.LogManager#demandSystemLogger(String, String, Module)}} and {{java.util.logging.Logger#mergeWithSystemLogger(Logger)}}
> # {{org.jboss.logmanager.Logger}} only ends up calling {{#setLevel(Level)}} with {{Level.ALL}} therefore the resulting system logger always has the level ALL
> The issue is quite hard to test because:
> # the effect only happens when the caller of {{#getLoggger(String)}} is a system module
> # the log output is not different, only {{#isLoggable(Level)}} checks that shouldn't succeed suddenly succeed so you only see the overhead
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months