[JBoss JIRA] (WFLY-13447) Undertow request failure happens due to "IllegalArgumentException: Comparison method violates its general contract!" when many filter-ref are defined
by Masafumi Miura (Jira)
[ https://issues.redhat.com/browse/WFLY-13447?page=com.atlassian.jira.plugi... ]
Masafumi Miura updated WFLY-13447:
----------------------------------
Attachment: test.cli
> Undertow request failure happens due to "IllegalArgumentException: Comparison method violates its general contract!" when many filter-ref are defined
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13447
> URL: https://issues.redhat.com/browse/WFLY-13447
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 19.1.0.Final
> Reporter: Masafumi Miura
> Assignee: Flavia Rainone
> Priority: Major
> Attachments: generate-cli.sh, test.cli
>
>
> When many filter-ref are defined (theoretically more than 32 filter-ref are defined), Undertow has a possibility fail to process a request with the following ERROR:
> {code}
> ERROR [io.undertow.request] (default I/O-12) UT005071: Undertow request failed HttpServerExchange{ GET /}: java.lang.IllegalArgumentException: Comparison method violates its general contract!
> at java.util.TimSort.mergeLo(TimSort.java:777)
> at java.util.TimSort.mergeAt(TimSort.java:514)
> at java.util.TimSort.mergeCollapse(TimSort.java:441)
> at java.util.TimSort.sort(TimSort.java:245)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1462)
> at org.wildfly.extension.undertow.LocationService.configureHandlerChain(LocationService.java:93)
> at org.wildfly.extension.undertow.Host.configureRootHandler(Host.java:174)
> at org.wildfly.extension.undertow.Host.getOrCreateRootHandler(Host.java:263)
> at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:430)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at org.wildfly.extension.undertow.Server$DefaultHostHandler.handleRequest(Server.java:190)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:102)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:370)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
> {code}
> The IllegalArgumentException happens when Java's TimSort algorithm happens to detect inconsistency in the comparison. This happens because [the comparator implementation for sorting filter-ref|https://github.com/wildfly/wildfly/blob/19.1.0.Final/undertow/...] does not follow the contract for comparison.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13447) Undertow request failure happens due to "IllegalArgumentException: Comparison method violates its general contract!" when many filter-ref are defined
by Masafumi Miura (Jira)
[ https://issues.redhat.com/browse/WFLY-13447?page=com.atlassian.jira.plugi... ]
Masafumi Miura updated WFLY-13447:
----------------------------------
Attachment: generate-cli.sh
> Undertow request failure happens due to "IllegalArgumentException: Comparison method violates its general contract!" when many filter-ref are defined
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13447
> URL: https://issues.redhat.com/browse/WFLY-13447
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 19.1.0.Final
> Reporter: Masafumi Miura
> Assignee: Flavia Rainone
> Priority: Major
> Attachments: generate-cli.sh, test.cli
>
>
> When many filter-ref are defined (theoretically more than 32 filter-ref are defined), Undertow has a possibility fail to process a request with the following ERROR:
> {code}
> ERROR [io.undertow.request] (default I/O-12) UT005071: Undertow request failed HttpServerExchange{ GET /}: java.lang.IllegalArgumentException: Comparison method violates its general contract!
> at java.util.TimSort.mergeLo(TimSort.java:777)
> at java.util.TimSort.mergeAt(TimSort.java:514)
> at java.util.TimSort.mergeCollapse(TimSort.java:441)
> at java.util.TimSort.sort(TimSort.java:245)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1462)
> at org.wildfly.extension.undertow.LocationService.configureHandlerChain(LocationService.java:93)
> at org.wildfly.extension.undertow.Host.configureRootHandler(Host.java:174)
> at org.wildfly.extension.undertow.Host.getOrCreateRootHandler(Host.java:263)
> at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:430)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at org.wildfly.extension.undertow.Server$DefaultHostHandler.handleRequest(Server.java:190)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:102)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:370)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
> {code}
> The IllegalArgumentException happens when Java's TimSort algorithm happens to detect inconsistency in the comparison. This happens because [the comparator implementation for sorting filter-ref|https://github.com/wildfly/wildfly/blob/19.1.0.Final/undertow/...] does not follow the contract for comparison.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13448) [GSS](7.3.z) Undertow request failure happens due to "IllegalArgumentException: Comparison method violates its general contract!" when many filter-ref are defined
by Masafumi Miura (Jira)
Masafumi Miura created WFLY-13448:
-------------------------------------
Summary: [GSS](7.3.z) Undertow request failure happens due to "IllegalArgumentException: Comparison method violates its general contract!" when many filter-ref are defined
Key: WFLY-13448
URL: https://issues.redhat.com/browse/WFLY-13448
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 19.1.0.Final
Reporter: Masafumi Miura
Assignee: Flavia Rainone
When many filter-ref are defined (theoretically more than 32 filter-ref are defined), Undertow has a possibility fail to process a request with the following ERROR:
{code}
ERROR [io.undertow.request] (default I/O-12) UT005071: Undertow request failed HttpServerExchange{ GET /}: java.lang.IllegalArgumentException: Comparison method violates its general contract!
at java.util.TimSort.mergeLo(TimSort.java:777)
at java.util.TimSort.mergeAt(TimSort.java:514)
at java.util.TimSort.mergeCollapse(TimSort.java:441)
at java.util.TimSort.sort(TimSort.java:245)
at java.util.Arrays.sort(Arrays.java:1512)
at java.util.ArrayList.sort(ArrayList.java:1462)
at org.wildfly.extension.undertow.LocationService.configureHandlerChain(LocationService.java:93)
at org.wildfly.extension.undertow.Host.configureRootHandler(Host.java:174)
at org.wildfly.extension.undertow.Host.getOrCreateRootHandler(Host.java:263)
at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:430)
at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54)
at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
at org.wildfly.extension.undertow.Server$DefaultHostHandler.handleRequest(Server.java:190)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211)
at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:102)
at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:370)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
{code}
The IllegalArgumentException happens when Java's TimSort algorithm happens to detect inconsistency in the comparison. This happens because [the comparator implementation for sorting filter-ref|https://github.com/wildfly/wildfly/blob/19.1.0.Final/undertow/...] does not follow the contract for comparison.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13447) Undertow request failure happens due to "IllegalArgumentException: Comparison method violates its general contract!" when many filter-ref are defined
by Masafumi Miura (Jira)
Masafumi Miura created WFLY-13447:
-------------------------------------
Summary: Undertow request failure happens due to "IllegalArgumentException: Comparison method violates its general contract!" when many filter-ref are defined
Key: WFLY-13447
URL: https://issues.redhat.com/browse/WFLY-13447
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 19.1.0.Final
Reporter: Masafumi Miura
Assignee: Flavia Rainone
When many filter-ref are defined (theoretically more than 32 filter-ref are defined), Undertow has a possibility fail to process a request with the following ERROR:
{code}
ERROR [io.undertow.request] (default I/O-12) UT005071: Undertow request failed HttpServerExchange{ GET /}: java.lang.IllegalArgumentException: Comparison method violates its general contract!
at java.util.TimSort.mergeLo(TimSort.java:777)
at java.util.TimSort.mergeAt(TimSort.java:514)
at java.util.TimSort.mergeCollapse(TimSort.java:441)
at java.util.TimSort.sort(TimSort.java:245)
at java.util.Arrays.sort(Arrays.java:1512)
at java.util.ArrayList.sort(ArrayList.java:1462)
at org.wildfly.extension.undertow.LocationService.configureHandlerChain(LocationService.java:93)
at org.wildfly.extension.undertow.Host.configureRootHandler(Host.java:174)
at org.wildfly.extension.undertow.Host.getOrCreateRootHandler(Host.java:263)
at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:430)
at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54)
at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
at org.wildfly.extension.undertow.Server$DefaultHostHandler.handleRequest(Server.java:190)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211)
at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:102)
at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:370)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
{code}
The IllegalArgumentException happens when Java's TimSort algorithm happens to detect inconsistency in the comparison. This happens because [the comparator implementation for sorting filter-ref|https://github.com/wildfly/wildfly/blob/19.1.0.Final/undertow/...] does not follow the contract for comparison.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13446) Dependency of wildfly-weld-common would be better to be ${project.groupId}
by Lin Gao (Jira)
[ https://issues.redhat.com/browse/WFLY-13446?page=com.atlassian.jira.plugi... ]
Lin Gao updated WFLY-13446:
---------------------------
Labels: downstream_dependency (was: )
> Dependency of wildfly-weld-common would be better to be ${project.groupId}
> --------------------------------------------------------------------------
>
> Key: WFLY-13446
> URL: https://issues.redhat.com/browse/WFLY-13446
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System
> Reporter: Lin Gao
> Assignee: Lin Gao
> Priority: Minor
> Labels: downstream_dependency
>
> A new depenency :
> {code:xml}
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-weld-common</artifactId>
> </dependency>
> {code}
> was added to +ejb3/+ subsystem. The dependency comes from different module of the same project, so it is better to have the groupId to +${project.groupId}+, so that it is easier when updating the project's groupId to like: +org.jboss.eap+
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13444) Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
by Srinivas ev (Jira)
[ https://issues.redhat.com/browse/WFLY-13444?page=com.atlassian.jira.plugi... ]
Srinivas ev edited comment on WFLY-13444 at 5/11/20 3:08 AM:
-------------------------------------------------------------
Hi [~pferraro],
Just added below snapshot using visual VM. Let me know in case if anything needs to be addressed for avoiding this default I/O thread invocation in Wildfly. Not sure why this thread is triggered.
!stack trace from snapshot.PNG|thumbnail!
was (Author: ev.srinivas):
Hi [~pferraro],
Just added below snapshot using visual VM. Let me know in case if anything needs to be addressed for avoiding this thread invocation in Wildfly. Not sure why this thread is triggered.
!stack trace from snapshot.PNG|thumbnail!
> Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
> -------------------------------------------------------------------
>
> Key: WFLY-13444
> URL: https://issues.redhat.com/browse/WFLY-13444
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, IO
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Paul Ferraro
> Priority: Blocker
> Attachments: IO thread memory.PNG, IO thread.PNG, Thread consuming high CPU.PNG, ThreadDump1set.zip, ThreadDump2set.zip, stack trace from snapshot.PNG, stack trace in thread dump.PNG, top command output.PNG
>
>
> Facing high CPU by one of the default I/O thread In Wildfly 10.1.0 Final. Looks none of our application component thread is consuming.
> Can somebody check what is triggering this issue? I attached the thread stack to this Jira. This is blocking our releases. When the CPU cores are high in number, multiple default I/O threads will kick in consuming the CPU in 90~100% range continuously.
> Wildfly 10.1.0 Final
> Java -
> openjdk version "1.8.0_232"
> OpenJDK Runtime Environment (build 1.8.0_232-b09)
> OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode
> ---------------------------------------------------------------------------------------------------
> at java.lang.Throwable.fillInStackTrace(Native Method)
> at java.lang.Throwable.fillInStackTrace(Throwable.java:784)
> at java.lang.Throwable.<init>(Throwable.java:251)
> at java.lang.Exception.<init>(Exception.java:54)
> at java.io.IOException.<init>(IOException.java:47)
> at java.nio.channels.ClosedChannelException.<init>(ClosedChannelException.java:52)
> at org.xnio.ssl.JsseStreamConduit.write(JsseStreamConduit.java:1022)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:393)
> at org.xnio.ssl.JsseStreamConduit.readReady(JsseStreamConduit.java:547)
> at org.xnio.ssl.JsseStreamConduit$2.readReady(JsseStreamConduit.java:319)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> -------------------------------------------------------------------------------------------
> at sun.nio.ch.EPollArrayWrapper.epollCtl(Native Method)
> at sun.nio.ch.EPollArrayWrapper.updateRegistrations(EPollArrayWrapper.java:299)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:268)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> -----------------------------------------------------------------------------------
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4965) Error loading a PKCS12 keystore inside a security-realm when using a credential-reference
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFCORE-4965?page=com.atlassian.jira.plug... ]
Ricardo Martin Camarero moved JBEAP-19448 to WFCORE-4965:
---------------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-4965 (was: JBEAP-19448)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 11.1.0.Final
(was: 7.3.0.GA)
> Error loading a PKCS12 keystore inside a security-realm when using a credential-reference
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-4965
> URL: https://issues.redhat.com/browse/WFCORE-4965
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.1.0.Final
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Major
>
> When using a security-realm configured with SSL like this:
> {code:xml}
> <security-realm name="CertificateRealm">
> <server-identities>
> <ssl>
> <keystore provider="PKCS12" path="${jboss.server.config.dir}/keystore.p12" alias="jboss">
> <keystore-password-credential-reference store="sample-store" alias="p12-password"/>
> </keystore>
> </ssl>
> </server-identities>
> </security-realm>
> {code}
> The EAP startup fails with the following exception:
> {noformat}
> org.wildfly.core.management.security.realm.CertificateRealm.key-manager: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException: invalid null input
> at java.security.KeyStore$PrivateKeyEntry.<init>(KeyStore.java:524)
> at sun.security.pkcs12.PKCS12KeyStore.engineGetEntry(PKCS12KeyStore.java:1311)
> at sun.security.provider.KeyStoreDelegator.engineGetEntry(KeyStoreDelegator.java:172)
> at sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetEntry(JavaKeyStore.java:70)
> at java.security.KeyStore.getEntry(KeyStore.java:1521)
> at org.jboss.as.domain.management.security.FileKeystore.load(FileKeystore.java:134)
> at org.jboss.as.domain.management.security.FileKeyManagerService.loadKeyStore(FileKeyManagerService.java:175)
> at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:128)
> at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:93)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> ... 6 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5252) [DMN Designer] Copy of a imported node shouldn't have a prefix
by Valentino Pellegrino (Jira)
[ https://issues.redhat.com/browse/DROOLS-5252?page=com.atlassian.jira.plug... ]
Valentino Pellegrino commented on DROOLS-5252:
----------------------------------------------
Hi [~jomarko],
With the fix provided by https://issues.redhat.com/browse/DROOLS-5253 every copied node should have a different name from the original one.
Do you think that it is enough to cover also this ticket?
Please let me know.
> [DMN Designer] Copy of a imported node shouldn't have a prefix
> --------------------------------------------------------------
>
> Key: DROOLS-5252
> URL: https://issues.redhat.com/browse/DROOLS-5252
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.37.0.Final
> Reporter: Jozef Marko
> Assignee: Valentino Pellegrino
> Priority: Minor
> Labels: drools-tools
> Attachments: imported-node-copy.webm
>
>
> This issue is related to two features of DMN editor.
> - Copy and paste diagram node
> - Nodes of imported model
> If user imported another DMN model into his DMN model, he can use imported nodes in his diagram. They can be easily distinguished by prefix of the imported model. The issue is if we copy and paste such imported node. Created copy shouldn't have the prefix of the original node.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13386) Hung process instances and associated server.log WARN "Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' "
by Enrique González Martínez (Jira)
[ https://issues.redhat.com/browse/WFLY-13386?page=com.atlassian.jira.plugi... ]
Enrique González Martínez commented on WFLY-13386:
--------------------------------------------------
# It does not require cluster neither in DB or wildfly (just 1 database and 1 wildfly instance)
# it requires the refresh task to be active
The race condition is caused because both of them are triggering the function registers a timer The problem happens
when the registering in wildfly memory is not finish and the registering the timer in the database has already finish. If the order
is changed it might happen that the refresh task is trying to register the timer even before the registering the timer in wildfly memory
causing this duplicate resource problem. This is because the operation is not atomic (registering a timer in memory + registering in databse)
the trace would be like
# registering timer in memory (main thread)
# registering timer in database (main thread)
# read timer from database (timer thread refresh task)
# register timer in memory (timer thread refresh task))
# register timer in resource (timer thread refresh task))
# register time in resource (main thread)
so refresh task is being executed at the same time as the timer thread is trying to register the timer.
keep in mind that operations in db are not linked to ejb tx (it is its own lifecycle)
> Hung process instances and associated server.log WARN "Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' "
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13386
> URL: https://issues.redhat.com/browse/WFLY-13386
> Project: WildFly
> Issue Type: Bug
> Reporter: Enrique González Martínez
> Assignee: Enrique González Martínez
> Priority: Major
>
> When a timer is reloaded for the first time in other node there are no listeners attached to it causing this problem (only in cluster environments with db timers)
> {code}
> 2020-04-15 16:43:57,733 WARN [org.jboss.as.ejb3.timer] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=33170e5f-3b34-4503-8796-9b5e6871c074) from its persistent state: java.lang.NullPointerException
> at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:851)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13444) Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
by Srinivas ev (Jira)
[ https://issues.redhat.com/browse/WFLY-13444?page=com.atlassian.jira.plugi... ]
Srinivas ev edited comment on WFLY-13444 at 5/11/20 2:13 AM:
-------------------------------------------------------------
Hi [~pferraro],
Just added below snapshot using visual VM. Let me know in case if anything needs to be addressed for avoiding this thread invocation in Wildfly. Not sure why this thread is triggered.
!stack trace from snapshot.PNG|thumbnail!
was (Author: ev.srinivas):
Hi [~pferraro],
Just added below snapshot using visual VM. Let me know in case if anything needs to be addressed for avoiding this thread invocation in Wildfly. Not sure who is triggering this thread.
!stack trace from snapshot.PNG|thumbnail!
> Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
> -------------------------------------------------------------------
>
> Key: WFLY-13444
> URL: https://issues.redhat.com/browse/WFLY-13444
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, IO
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Paul Ferraro
> Priority: Blocker
> Attachments: IO thread memory.PNG, IO thread.PNG, Thread consuming high CPU.PNG, ThreadDump1set.zip, ThreadDump2set.zip, stack trace from snapshot.PNG, stack trace in thread dump.PNG, top command output.PNG
>
>
> Facing high CPU by one of the default I/O thread In Wildfly 10.1.0 Final. Looks none of our application component thread is consuming.
> Can somebody check what is triggering this issue? I attached the thread stack to this Jira. This is blocking our releases. When the CPU cores are high in number, multiple default I/O threads will kick in consuming the CPU in 90~100% range continuously.
> Wildfly 10.1.0 Final
> Java -
> openjdk version "1.8.0_232"
> OpenJDK Runtime Environment (build 1.8.0_232-b09)
> OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode
> ---------------------------------------------------------------------------------------------------
> at java.lang.Throwable.fillInStackTrace(Native Method)
> at java.lang.Throwable.fillInStackTrace(Throwable.java:784)
> at java.lang.Throwable.<init>(Throwable.java:251)
> at java.lang.Exception.<init>(Exception.java:54)
> at java.io.IOException.<init>(IOException.java:47)
> at java.nio.channels.ClosedChannelException.<init>(ClosedChannelException.java:52)
> at org.xnio.ssl.JsseStreamConduit.write(JsseStreamConduit.java:1022)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:393)
> at org.xnio.ssl.JsseStreamConduit.readReady(JsseStreamConduit.java:547)
> at org.xnio.ssl.JsseStreamConduit$2.readReady(JsseStreamConduit.java:319)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> -------------------------------------------------------------------------------------------
> at sun.nio.ch.EPollArrayWrapper.epollCtl(Native Method)
> at sun.nio.ch.EPollArrayWrapper.updateRegistrations(EPollArrayWrapper.java:299)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:268)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> -----------------------------------------------------------------------------------
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years