[JBoss JIRA] (JGRP-2494) DNS_PING and failed probes
by Dewayne McNair (Jira)
[ https://issues.redhat.com/browse/JGRP-2494?page=com.atlassian.jira.plugin... ]
Dewayne McNair updated JGRP-2494:
---------------------------------
Steps to Reproduce:
logs are below showing the DNS_PING query where the two entries are found - port 8888 is the web port, port 8889 is the jgroups port. Undertow logs a failure for the probe at DEBUG level, but jgroups is logging the failed probe at ERROR level.
{code:java}
2020-07-22 17:51:03,356 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-5,null,463dfca1ff73) 463dfca1ff73: entries collected from DNS (in 3 ms): [172.29.11.55:8889, 172.29.11.55:8888]2020-07-22 17:51:03,356 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-5,null,463dfca1ff73) 463dfca1ff73: entries collected from DNS (in 3 ms): [172.29.11.55:8889, 172.29.11.55:8888]2020-07-22 17:51:03,356 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-5,null,463dfca1ff73) 463dfca1ff73: sending discovery requests to [172.29.11.55:8889, 172.29.11.55:8888]2020-07-22 17:51:03,357 DEBUG [io.undertow.request.io] (default I/O-2) UT005014: Failed to parse request: io.undertow.util.BadRequestException: UT000165: Invalid character in request-target at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpRequestParser.handlePath(HttpRequestParser.java:389) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpRequestParser.handle(HttpRequestParser.java:248) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:187) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.jboss.xnio.nio@3.7.7.Final//org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178) at org.jboss.xnio.nio@3.7.7.Final//org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612) at org.jboss.xnio.nio@3.7.7.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:479) 2020-07-22 17:51:03,358 ERROR [org.jgroups.protocols.TCP] (Connection.Receiver [172.17.0.10:57508 - 172.29.11.55:8888]-22,ejb,463dfca1ff73) JGRP000030: 463dfca1ff73: failed handling incoming message: java.io.EOFException at java.base/java.io.DataInputStream.readFully(DataInputStream.java:202) at org.jgroups@4.1.9.Final//org.jgroups.util.Util.readMessageBatch(Util.java:1226) at org.jgroups@4.1.9.Final//org.jgroups.protocols.TP.handleMessageBatch(TP.java:1448) at org.jgroups@4.1.9.Final//org.jgroups.protocols.TP.receive(TP.java:1440) at org.jgroups@4.1.9.Final//org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171) at org.jgroups@4.1.9.Final//org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:300) at org.jboss.as.clustering.common@19.1.0.Final//org.jboss.as.clustering.context.ContextReferenceExecutor.execute(ContextReferenceExecutor.java:49) at org.jboss.as.clustering.common@19.1.0.Final//org.jboss.as.clustering.context.ContextualExecutor$1.run(ContextualExecutor.java:70) at java.base/java.lang.Thread.run(Thread.java:834)
{code}
was:
logs are below showing the DNS_PING query where the two entries are found - port 8888 is the web port, port 8889 is the jgroups port. Undertow logs a failure for the probe at DEBUG level, but jgroups is logging the failed probe at ERROR level.
{noformat}
2020-07-22 17:51:03,356 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-5,null,463dfca1ff73) 463dfca1ff73: entries collected from DNS (in 3 ms): [172.29.11.55:8889, 172.29.11.55:8888]2020-07-22 17:51:03,356 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-5,null,463dfca1ff73) 463dfca1ff73: entries collected from DNS (in 3 ms): [172.29.11.55:8889, 172.29.11.55:8888]2020-07-22 17:51:03,356 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-5,null,463dfca1ff73) 463dfca1ff73: sending discovery requests to [172.29.11.55:8889, 172.29.11.55:8888]2020-07-22 17:51:03,357 DEBUG [io.undertow.request.io] (default I/O-2) UT005014: Failed to parse request: io.undertow.util.BadRequestException: UT000165: Invalid character in request-target at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpRequestParser.handlePath(HttpRequestParser.java:389) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpRequestParser.handle(HttpRequestParser.java:248) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:187) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.jboss.xnio.nio@3.7.7.Final//org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178) at org.jboss.xnio.nio@3.7.7.Final//org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612) at org.jboss.xnio.nio@3.7.7.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:479) 2020-07-22 17:51:03,358 ERROR [org.jgroups.protocols.TCP] (Connection.Receiver [172.17.0.10:57508 - 172.29.11.55:8888]-22,ejb,463dfca1ff73) JGRP000030: 463dfca1ff73: failed handling incoming message: java.io.EOFException at java.base/java.io.DataInputStream.readFully(DataInputStream.java:202) at org.jgroups@4.1.9.Final//org.jgroups.util.Util.readMessageBatch(Util.java:1226) at org.jgroups@4.1.9.Final//org.jgroups.protocols.TP.handleMessageBatch(TP.java:1448) at org.jgroups@4.1.9.Final//org.jgroups.protocols.TP.receive(TP.java:1440) at org.jgroups@4.1.9.Final//org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171) at org.jgroups@4.1.9.Final//org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:300) at org.jboss.as.clustering.common@19.1.0.Final//org.jboss.as.clustering.context.ContextReferenceExecutor.execute(ContextReferenceExecutor.java:49) at org.jboss.as.clustering.common@19.1.0.Final//org.jboss.as.clustering.context.ContextualExecutor$1.run(ContextualExecutor.java:70) at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
> DNS_PING and failed probes
> --------------------------
>
> Key: JGRP-2494
> URL: https://issues.redhat.com/browse/JGRP-2494
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.9
> Reporter: Dewayne McNair
> Assignee: Bela Ban
> Priority: Major
>
> Using DNS_PING in a DC/OS (marathon) deployment, there are two SRV records returned - one for the web port and one for the jgroups port. When the discovery request is sent, an exception is thrown and logged. The clustering is working, but logs are filling up due to the exception happening and being logged frequently.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (JGRP-2494) DNS_PING and failed probes
by Dewayne McNair (Jira)
Dewayne McNair created JGRP-2494:
------------------------------------
Summary: DNS_PING and failed probes
Key: JGRP-2494
URL: https://issues.redhat.com/browse/JGRP-2494
Project: JGroups
Issue Type: Bug
Affects Versions: 4.1.9
Reporter: Dewayne McNair
Assignee: Bela Ban
Using DNS_PING in a DC/OS (marathon) deployment, there are two SRV records returned - one for the web port and one for the jgroups port. When the discovery request is sent, an exception is thrown and logged. The clustering is working, but logs are filling up due to the exception happening and being logged frequently.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-5061) DMN strongly typed codegen DMNContext and DMNResult
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5061?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5061:
-----------------------------------
Description:
*Motivation*: currently interacting with DMN evaluation is mostly based on dynamic (map-based) data structure to exchange IN/OUT. This is not always fully satisfactory, for instance when interacting over REST or from/back-to BPMN.
*Goals*: A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
*Impacts*: integration with BPMN, integration with Kogito for OpenAPI/Swagger, new APIs for DMN, will need documentation.
A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
Surface and interface common to:
* BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model
* Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN
** for Quarkus based, use RegisterForReflection annotation
** use MP validation for allowedvalues
* DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class
Documentation:
* the programmatic use of the generated classes, directly, is DISCOURAGED
* if anything, a programmatic use will eventually be stable by making use of the available interfaces in kie-dmn-core
was:
Motivation: currently interacting with DMN evaluation is mostly based on dynamic (map-based) data structure to exchange IN/OUT. This is not always fully satisfactory, for instance when interacting over REST or from/back-to BPMN.
Goals: A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
Impacts: integration with BPMN, integration with Kogito for OpenAPI/Swagger, new APIs for DMN, will need documentation.
A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
Surface and interface common to:
* BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model
* Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN
** for Quarkus based, use RegisterForReflection annotation
** use MP validation for allowedvalues
* DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class
Documentation:
* the programmatic use of the generated classes, directly, is DISCOURAGED
* if anything, a programmatic use will eventually be stable by making use of the available interfaces in kie-dmn-core
> DMN strongly typed codegen DMNContext and DMNResult
> ---------------------------------------------------
>
> Key: DROOLS-5061
> URL: https://issues.redhat.com/browse/DROOLS-5061
> Project: Drools
> Issue Type: Epic
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Luca Molteni
> Priority: Major
>
> *Motivation*: currently interacting with DMN evaluation is mostly based on dynamic (map-based) data structure to exchange IN/OUT. This is not always fully satisfactory, for instance when interacting over REST or from/back-to BPMN.
> *Goals*: A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
> *Impacts*: integration with BPMN, integration with Kogito for OpenAPI/Swagger, new APIs for DMN, will need documentation.
> A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
> Surface and interface common to:
> * BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model
> * Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN
> ** for Quarkus based, use RegisterForReflection annotation
> ** use MP validation for allowedvalues
> * DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class
> Documentation:
> * the programmatic use of the generated classes, directly, is DISCOURAGED
> * if anything, a programmatic use will eventually be stable by making use of the available interfaces in kie-dmn-core
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-4605) DMN alpha network
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-4605?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-4605:
-----------------------------------
Description:
*Motivation*: a DMN decision table can be evaluated faster than naive algorithm by translating it into a Rete/Phreak, but the current kie7 approach is suffering from performance bottleneck artificially induced by use of kie7 rule units, which provide more harm than benefit to perfomance (performance is actually worst for most "realistic" cases).
*Goals*: a POC to understand what’s need to be done to support the alpha network compiler (wihout kie7 rule units) in DMN. We currently estimate it will take us 1 to 2 summer sprints and the output will be more epics to implement this feature.
*Impact*: alpha network compiler code refactors for the better use of.
One part of the POC was to hard-code the alpha network for a specific table ([DROOLS-4566]) the remained of the poc is to generalize the approach further to fully assess the impacts thanks to the poc.
> DMN alpha network
> -----------------
>
> Key: DROOLS-4605
> URL: https://issues.redhat.com/browse/DROOLS-4605
> Project: Drools
> Issue Type: Epic
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> *Motivation*: a DMN decision table can be evaluated faster than naive algorithm by translating it into a Rete/Phreak, but the current kie7 approach is suffering from performance bottleneck artificially induced by use of kie7 rule units, which provide more harm than benefit to perfomance (performance is actually worst for most "realistic" cases).
> *Goals*: a POC to understand what’s need to be done to support the alpha network compiler (wihout kie7 rule units) in DMN. We currently estimate it will take us 1 to 2 summer sprints and the output will be more epics to implement this feature.
> *Impact*: alpha network compiler code refactors for the better use of.
> One part of the POC was to hard-code the alpha network for a specific table ([DROOLS-4566]) the remained of the poc is to generalize the approach further to fully assess the impacts thanks to the poc.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-5061) DMN strongly typed codegen DMNContext and DMNResult
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5061?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5061:
-----------------------------------
Description:
Motivation: currently interacting with DMN evaluation is mostly based on dynamic (map-based) data structure to exchange IN/OUT. This is not always fully satisfactory, for instance when interacting over REST or from/back-to BPMN.
Goals: A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
Impacts: integration with BPMN, integration with Kogito for OpenAPI/Swagger, new APIs for DMN, will need documentation.
A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
Surface and interface common to:
* BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model
* Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN
** for Quarkus based, use RegisterForReflection annotation
** use MP validation for allowedvalues
* DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class
Documentation:
* the programmatic use of the generated classes, directly, is DISCOURAGED
* if anything, a programmatic use will eventually be stable by making use of the available interfaces in kie-dmn-core
was:
A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
Surface and interface common to:
* BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model
* Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN
** for Quarkus based, use RegisterForReflection annotation
** use MP validation for allowedvalues
* DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class
Documentation:
* the programmatic use of the generated classes, directly, is DISCOURAGED
* if anything, a programmatic use will eventually be stable by making use of the available interfaces in kie-dmn-core
> DMN strongly typed codegen DMNContext and DMNResult
> ---------------------------------------------------
>
> Key: DROOLS-5061
> URL: https://issues.redhat.com/browse/DROOLS-5061
> Project: Drools
> Issue Type: Epic
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Luca Molteni
> Priority: Major
>
> Motivation: currently interacting with DMN evaluation is mostly based on dynamic (map-based) data structure to exchange IN/OUT. This is not always fully satisfactory, for instance when interacting over REST or from/back-to BPMN.
> Goals: A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
> Impacts: integration with BPMN, integration with Kogito for OpenAPI/Swagger, new APIs for DMN, will need documentation.
> A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
> Surface and interface common to:
> * BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model
> * Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN
> ** for Quarkus based, use RegisterForReflection annotation
> ** use MP validation for allowedvalues
> * DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class
> Documentation:
> * the programmatic use of the generated classes, directly, is DISCOURAGED
> * if anything, a programmatic use will eventually be stable by making use of the available interfaces in kie-dmn-core
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13690) InfinispanRoutingProvider generates wrong service names when server name contain a dot.
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-13690:
-----------------------------------
Summary: InfinispanRoutingProvider generates wrong service names when server name contain a dot.
Key: WFLY-13690
URL: https://issues.redhat.com/browse/WFLY-13690
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 20.0.1.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The problematic pattern:
{code:java}
BinaryRequirement requirement = ...;
ServiceName.parse(requirement.resolve(container, cache));
{code}
should be:
{code:java}
ServiceName.parse(requirement.getName()).append(container, cache);
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13433) Improve capability support in EJB3 subsystem
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13433?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz commented on WFLY-13433:
--------------------------------------------
The only differences I can see between running -DallTests locally and what the CI runs is:
* -Djboss.test.mixed.domain.dir to run the mixed domain tests, as described above
* -Dipv6 to enforce IPv6
* -Djboss.test.transformers.eap to run the EAP transformer tests
* -DlegacyBuild to require a legacy build (using Wildfly Build Tools) for Galleon feature pack purposes
* -DlegacyRelease to require a legacy release (using Wildfly Build Tools) for Galleon feature pack purposes
* -Dmaven.test.failure.ignore=true to prevent maven from stopping testsuite execution on a failure
* -DfailIfNoTests=false to prevent surefire stopping when no tests available to run
It would be nice to have a special target to represent these which would be used locally; or to make -DallTests match what the CI does.
This may also require some local configuration for running the clustering tests using IPv6, as mentioned in testsuite/pom.xml :
{noformat}
<!-- Allow loopback to multicast -->
<!-- ip -6 route add table local local ff13::/16 dev lo metric 5 -->
{noformat}
> Improve capability support in EJB3 subsystem
> --------------------------------------------
>
> Key: WFLY-13433
> URL: https://issues.redhat.com/browse/WFLY-13433
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: 20.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
>
> Survey all external subsystem dependencies and introduce capability based dependencies where required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-5053) Prometheus JMX exporter jar, stops starting the wildfly server.
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-5053?page=com.atlassian.jira.plug... ]
James Perkins commented on WFCORE-5053:
---------------------------------------
[~rakesh.shah1977] It's already been released. You can just download JBoss Modules 1.10.1 (https://search.maven.org/artifact/org.jboss.modules/jboss-modules/1.10.1....). You'll also need to modify your {{standalone.bat}} script too. You'll need to remove the reset the the {{MODULE_OPTS}} environment variable. See https://github.com/wildfly/wildfly-core/pull/4131/files#diff-ce685ca37a3d... and https://github.com/wildfly/wildfly-core/pull/4131/files#diff-0859a1503bc9....
> Prometheus JMX exporter jar, stops starting the wildfly server.
> ----------------------------------------------------------------
>
> Key: WFCORE-5053
> URL: https://issues.redhat.com/browse/WFCORE-5053
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Rakesh Kumar Shah
> Assignee: James Perkins
> Priority: Major
> Fix For: 13.0.0.Beta1
>
>
> Trying to integrate the Prometheus JMX exporter with wildfly. After spending lot of time and work around it, wildfly is not starting. It throws following exception.
> {code}
> java.lang.ClassNotFoundException: org.jboss.logmanager.LogManager
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> at java.logging/java.util.logging.LogManager$1.run(LogManager.java:239)
> at java.logging/java.util.logging.LogManager$1.run(LogManager.java:223)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.logging/java.util.logging.LogManager.<clinit>(LogManager.java:223)
> at java.logging/java.util.logging.Logger.demandLogger(Logger.java:648)
> at java.logging/java.util.logging.Logger.getLogger(Logger.java:717)
> at java.logging/java.util.logging.Logger.getLogger(Logger.java:701)
> at io.prometheus.jmx.shaded.io.prometheus.jmx.JmxCollector.<clinit>(JmxCollector.java:39)
> at io.prometheus.jmx.shaded.io.prometheus.jmx.JavaAgent.premain(JavaAgent.java:29)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:513)
> at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:525)
> WARNING: Failed to load the specified log manager class org.jboss.logmanager.LogManager
> Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/logmanager/Level
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:398)
> at org.jboss.modules.Module.run(Module.java:340)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:617)
> Caused by: java.lang.ClassNotFoundException: org.jboss.logmanager.Level
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> at org.jboss.modules.JDKSpecific.getSystemClass(JDKSpecific.java:183)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:395)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months