[JBoss JIRA] (WFLY-12446) Memory leak in StatelessSessionComponent
by Matěj Novotný (Jira)
[ https://issues.jboss.org/browse/WFLY-12446?page=com.atlassian.jira.plugin... ]
Matěj Novotný commented on WFLY-12446:
--------------------------------------
[~jaikiran] you are welcome, hope you have it running smoothly now.
Handling dynamic resolution with dependent instances can get rough indeed.
To confirm that this is expected flow, here is a spec quote, namely [5.6.1 The {{Instance}} interface|https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#dynamic_lookup]:
{quote}
The iterator() method must:
Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Performing typesafe resolution, resolving ambiguities according to Unsatisfied and ambiguous dependencies.
Return an Iterator, that iterates over the set of contextual references for the resulting beans and required type, as defined in Contextual reference for a bean.
{quote}
And getting a contextual reference for a dependent bean means creating new instance every time, hence the behaviour we are seeing in this issue.
> Memory leak in StatelessSessionComponent
> ----------------------------------------
>
> Key: WFLY-12446
> URL: https://issues.jboss.org/browse/WFLY-12446
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 17.0.1.Final
> Reporter: Joerg Baesner
> Assignee: Cheng Fang
> Priority: Major
> Attachments: dump-weld.png, playground-jee8.zip, server.log.gz, wfly-12446-heap-dump.png
>
>
> When running the attached reproducer application and doing a memory analysis afterwards, it looks like a memory leak, e. g.
> {code}
> One instance of "org.jboss.as.ejb3.component.stateless.StatelessSessionComponent" loaded by "org.jboss.modules.ModuleClassLoader @ 0x5e0fbc2e0" occupies 936,593,520 (96.13%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentLinkedQueue$Node" loaded by "<system class loader>".
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFLY-12446) Memory leak in StatelessSessionComponent
by Jaikiran Pai (Jira)
[ https://issues.jboss.org/browse/WFLY-12446?page=com.atlassian.jira.plugin... ]
Jaikiran Pai commented on WFLY-12446:
-------------------------------------
Thank you [~manovotn] for these details. This indeed makes sense now. The only surprising part to me (as someone who isn't familiar with CDI spec) is that using the same {{Iterable}} (which is the {{Instance}}) multiple times, creates new instances of the underlying bean returned by that Iterable/Instance.
> Memory leak in StatelessSessionComponent
> ----------------------------------------
>
> Key: WFLY-12446
> URL: https://issues.jboss.org/browse/WFLY-12446
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 17.0.1.Final
> Reporter: Joerg Baesner
> Assignee: Cheng Fang
> Priority: Major
> Attachments: dump-weld.png, playground-jee8.zip, server.log.gz, wfly-12446-heap-dump.png
>
>
> When running the attached reproducer application and doing a memory analysis afterwards, it looks like a memory leak, e. g.
> {code}
> One instance of "org.jboss.as.ejb3.component.stateless.StatelessSessionComponent" loaded by "org.jboss.modules.ModuleClassLoader @ 0x5e0fbc2e0" occupies 936,593,520 (96.13%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentLinkedQueue$Node" loaded by "<system class loader>".
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (JGRP-2382) JGroups version 4.0.13.Final.jar is causing memory leaks
by Rashmi Acharya (Jira)
[ https://issues.jboss.org/browse/JGRP-2382?page=com.atlassian.jira.plugin.... ]
Rashmi Acharya edited comment on JGRP-2382 at 9/21/19 12:08 AM:
----------------------------------------------------------------
Hi Bela,
For now we made further changes on the property and saw Cluster Load distribution is working fine.
Support is going to share the new changes to customer and wait until tomorrow to see whether it is solving the memory leak.
Here are the changes we made further:
1: Removing use_mcast_xmit="false" from NACACK2 protocol
2:Removed UNICAST3 sine heap memory growth was due to these messages.. This is actually not required for Workflow load distribution
3: Added FD_ALL parameter
4: Removed BARRIER
New Change:
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd"> <TCP bind_port="&MULTICAST_NODE_PORT1;" /> <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true" /> <MERGE3 min_interval="3000" max_interval="5000"/><FD_ALL timeout="20000" interval="15000" /> <FD_SOCK/> <FD timeout="5000" max_tries="48" /> <VERIFY_SUSPECT timeout="1500" /> <pbcast.NAKACK2 discard_delivered_msgs="true"/> <pbcast.STABLE desired_avg_gossip="20000" max_bytes="0" stability_delay="1000" /> <pbcast.GMS print_local_addr="true" join_timeout="15000"/></config>
We need to understand
1: why we saw issues with load distribution when we had use_mcast_xmit in NACACK2.
2 What is the equivalent parameter for NACACK retransmit_timeout="5000" in NACACK2
3: What is the use of FD_ALL parameter
4: Why UNICAST3 objects were lying on memory and is there any way it can be GCed with timeout settings ?
was (Author: rashmia5):
Hi Bella,
For now we made further changes on the property and saw Cluster Load distribution is working fine.
Support is going to share the new changes to customer and wait until tomorrow to see whether it is solving the memory leak.
Here are the changes we made further:
1: Removing use_mcast_xmit="false" from NACACK2 protocol
2:Removed UNICAST3 sine heap memory growth was due to these messages.. This is actually not required for Workflow load distribution
3: Added FD_ALL parameter
4: Removed BARRIER
New Change:
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd"> <TCP bind_port="&MULTICAST_NODE_PORT1;" /> <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true" /> <MERGE3 min_interval="3000" max_interval="5000"/><FD_ALL timeout="20000" interval="15000" /> <FD_SOCK/> <FD timeout="5000" max_tries="48" /> <VERIFY_SUSPECT timeout="1500" /> <pbcast.NAKACK2 discard_delivered_msgs="true"/> <pbcast.STABLE desired_avg_gossip="20000" max_bytes="0" stability_delay="1000" /> <pbcast.GMS print_local_addr="true" join_timeout="15000"/></config>
We need to understand
1: why we saw issues with load distribution when we had use_mcast_xmit in NACACK2.
2 What is the equivalent parameter for NACACK retransmit_timeout="5000" in NACACK2
3: What is the use of FD_ALL parameter
4: Why UNICAST3 objects were lying on memory and is there any way it can be GCed with timeout settings ?
> JGroups version 4.0.13.Final.jar is causing memory leaks
> --------------------------------------------------------
>
> Key: JGRP-2382
> URL: https://issues.jboss.org/browse/JGRP-2382
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.13
> Environment: AIX machine 7.1 with JDK 1.8
> Reporter: Rashmi Acharya
> Assignee: Bela Ban
> Priority: Major
> Attachments: dumps_TEST_node1_20190918_after_3_hours.zip, dumps_TEST_node1_20190918_right_after_restart.zip, dumps_TEST_node2_20190918_after_3_hours.zip, dumps_TEST_node2_20190918_right_after_restart.zip
>
>
> We are observing a constant memory growth and leak with JGroup version 4.0.13 ..
> One of our customer is having two node cluster environment and in one node we are observing org.Group.Messages which contain org.groups.Header and org.groups.Stack.ipAddress objects.. these are not getting cleared from memory..
> We dont see any exception related to Jgroups from logs and but it is causing a gradual emory growth and OOM.
> Here is the Jgroups cluster configuration we have:
> dynamic.cluster.property_string
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
> <TCP bind_addr="&HOST_ADDR;" bind_port="&MULTICAST_NODE_PORT2;"/>
> <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true"/>
> <MERGE3 min_interval="3000" max_interval="5000" />
> <FD_ALL timeout="20000" interval="15000"/>
> <FD_SOCK/>
> <FD timeout="5000" max_tries="48" />
> <VERIFY_SUSPECT timeout="1500"/>
> <BARRIER/>
> <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/>
> <UNICAST3/>
> <pbcast.STABLE desired_avg_gossip="20000" max_bytes="0" stability_delay="1000"/>
> <pbcast.GMS print_local_addr="true" join_timeout="15000" />
> </config>
> =================================
> dynamic.cluster.distribution_property_string
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
> <TCP bind_port="&MULTICAST_NODE_PORT1;" />
> <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true"/>
> <MERGE3 min_interval="3000" max_interval="5000"/>
> <FD_SOCK/>
> <FD timeout="5000" max_tries="48"/>
> <VERIFY_SUSPECT timeout="1500"/>
> <BARRIER/>
> <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/>
> <UNICAST3/>
> <pbcast.STABLE desired_avg_gossip="20000" max_bytes="0" stability_delay="1000" />
> <pbcast.GMS print_local_addr="true" join_timeout="5000"/>
> </config>
> ================================
> dynamic.cluster.lock.protocolStack
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
> <TCP bind_addr="&HOST_ADDR;" bind_port="&MULTICAST_NODE_PORT3;"/>
> <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true"/>
> <MERGE3 min_interval="3000" max_interval="5000"/>
> <FD_ALL timeout="20000" interval="5000"/>
> <FD timeout="5000" max_tries="48"/>
> <VERIFY_SUSPECT timeout="1500"/>
> <BARRIER/>
> <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/>
> <UNICAST3 /> <pbcast.STABLE desired_avg_gossip="20000" />
> <pbcast.GMS print_local_addr="true" join_timeout="5000"/>
> <FRAG2 frag_size="8096"/>
> <CENTRAL_LOCK2/>
> </config>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFLY-12581) Optimize web/ejb expiration schedulers
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-12581:
-----------------------------------
Summary: Optimize 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
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 PriorityBlockingQueue, 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] (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:
--------------------------------
Summary: Optimize distributed web/ejb expiration schedulers (was: Optimize web/ejb expiration schedulers)
> 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
>
> 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 PriorityBlockingQueue, 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-4257) DMN UX - overlay information about an entire simulation execution
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4257?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-4257:
-------------------------------------------
Updated visuals and focusing on only entire scenario test: https://marvelapp.com/cg2dhi4
> DMN UX - overlay information about an entire simulation execution
> -----------------------------------------------------------------
>
> Key: DROOLS-4257
> URL: https://issues.jboss.org/browse/DROOLS-4257
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Affects Versions: 7.24.0.Final
> Reporter: Daniele Zonca
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam, drools-tools
>
> Related to https://issues.jboss.org/browse/DROOLS-3731
> This task will cover this use case:
> - user creates a DMN model
> - user creates a Test Scenario with some scenarios
> - user executes the Test Scenario
> - user open Coverage Report
> - user wants to analyze coverage information of {color:red}the *whole* simulation{color}
> - user clicks on "a link" near global coverage information
> - user lands on DMN editor with overlay information about number of time each decision has been executed, number of time each decision succeed/fail (maybe with different colors?)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (DROOLS-4513) s2i build fails at KieServerContainerVerifier without appropriate logging when kmodule.xml schema validation fails
by David Ward (Jira)
[ https://issues.jboss.org/browse/DROOLS-4513?page=com.atlassian.jira.plugi... ]
David Ward commented on DROOLS-4513:
------------------------------------
[~volothamp], [~hiroko], [~filippe.spolti], If I remember correctly, I wrote the KieServerContainerVerifier, and all it really does is just create a new KieContainer and see if there were any errors. When I first saw this jira (and talked to [~KrisVerlaenen] about it), I suspected an xml schema issue given the fact that changing the order of elements made the problem go away, so this is not a problem with our OpenShift images. Wouldn't the simple (and correct) fix just be to change the xml schema to allow for any order of the listener elements?
> s2i build fails at KieServerContainerVerifier without appropriate logging when kmodule.xml schema validation fails
> ------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-4513
> URL: https://issues.jboss.org/browse/DROOLS-4513
> Project: Drools
> Issue Type: Bug
> Components: build, kie server
> Affects Versions: 7.14.0.Final, 7.18.0.Final, 7.24.0.Final
> Environment: OpenShift 3.11 with rhdm72-prod-immutable-kieserver.yaml/rhdm73-prod-immutable-kieserver.yaml
> Reporter: Hiroko Miura
> Assignee: Ant Stephenson
> Priority: Major
> Labels: support
> Attachments: ruleTest.zip
>
>
> If multiple ksession are defined in kmodule.xml and Event Lister is set more than one ksession, s2i build fails at KieServerContainerVerifier with the following error.
> {noformat}
> [main] ERROR org.kie.server.services.impl.KieServerContainerVerifier - Cannot find KieModule: com.redhat.gss:ruleTest:1.0.0-SNAPSHOT
> java.lang.RuntimeException: Cannot find KieModule: com.redhat.gss:ruleTest:1.0.0-SNAPSHOT
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:186)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:172)
> at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:65)
> at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:53)
> at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:40)
> at org.kie.server.services.impl.KieServerContainerVerifier.main(KieServerContainerVerifier.java:119)
> at org.kie.server.services.impl.KieServerContainerVerifier.main(KieServerContainerVerifier.java:101)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> [main] ERROR org.kie.server.services.impl.KieServerContainerVerifier - com.redhat.gss:ruleTest:1.0.0-SNAPSHOT not verified.
> ERROR Aborting due to error code 1 from kie server container verification
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (LOGMGR-261) If a module is defined and the log manager is on boot class path the log manager will fail to configure
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-261?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-261:
---------------------------------
Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/278, https://github.com/jboss-logging/jboss-logmanager/pull/279
> If a module is defined and the log manager is on boot class path the log manager will fail to configure
> -------------------------------------------------------------------------------------------------------
>
> Key: LOGMGR-261
> URL: https://issues.jboss.org/browse/LOGMGR-261
> Project: JBoss Log Manager
> Issue Type: Bug
> Components: core
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Critical
> Labels: jdk11
>
> If the log manager is on the boot class path and a module is defined in the {{logging.properties}} or defined in the configuration API the log manager will fail to configure. This seems due to the fact that the log manager is on the boot class path and jboss-modules is on the system class path.
> Example exception:
> {code}
> Failed to read or configure the org.jboss.logmanager.LogManager
> java.lang.IllegalArgumentException: Failed to load module "org.jboss.logmanager" for formatter "JSON"
> at org.jboss.logmanager.config.AbstractPropertyConfiguration.<init>(AbstractPropertyConfiguration.java:65)
> at org.jboss.logmanager.config.FormatterConfigurationImpl.<init>(FormatterConfigurationImpl.java:30)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.addFormatterConfiguration(LogContextConfigurationImpl.java:172)
> at org.jboss.logmanager.PropertyConfigurator.configureFormatter(PropertyConfigurator.java:631)
> at org.jboss.logmanager.PropertyConfigurator.configureHandler(PropertyConfigurator.java:701)
> at org.jboss.logmanager.PropertyConfigurator.configureLogger(PropertyConfigurator.java:583)
> at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:521)
> at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:97)
> at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:170)
> at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:132)
> at java.util.logging.LogManager$3.run(LogManager.java:399)
> at java.util.logging.LogManager$3.run(LogManager.java:396)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.logging.LogManager.readPrimordialConfiguration(LogManager.java:396)
> at java.util.logging.LogManager.access$800(LogManager.java:145)
> at java.util.logging.LogManager$2.run(LogManager.java:345)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.logging.LogManager.ensureLogManagerInitialized(LogManager.java:338)
> at java.util.logging.LogManager.getLogManager(LogManager.java:378)
> at org.jboss.modules.Main.main(Main.java:523)
> Caused by: java.lang.NoClassDefFoundError: org/jboss/modules/ModuleLoader
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$ModuleFinder.getClassLoader(AbstractPropertyConfiguration.java:556)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration.<init>(AbstractPropertyConfiguration.java:63)
> ... 19 more
> {code}
> The only real resolution to this will be to create some kind of {{ModuleFinder}} API in the log manager which allows something like jboss-modules to implement a version which knows how to log the modules.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months