[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFWIP-160:
----------------------------------
[~adamkrajcik] / [~jstourac] Please see the comment above from [~ropalka]. Is QE still able to reproduce this issue?
> Fix throughput and response time differences between TLS 1.2 and TLS 1.3
> ------------------------------------------------------------------------
>
> Key: WFWIP-160
> URL: https://issues.jboss.org/browse/WFWIP-160
> Project: WildFly WIP
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Richard Opalka
> Priority: Blocker
> Attachments: results-tlsv12.zip, results-tlsv13.zip
>
>
> Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
> Steps to reproduce (taken from EAP7-1022):
> 1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
> https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
> https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
> https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
> 2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
> 3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
> 4. Configure and start server with TLSv1.3 and JDK 11:
> {code}
> connect
> /subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
> /subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
> /subsystem=elytron/key-store=tls13:store()
> /subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
> /subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
> batch
> /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
> run-batch
> reload
> {code}
> 5. Start jmeter with JDK 11 and downloaded test plan
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
> {code}
> 6. Set server to use TLSv1.2
> {code}
> /subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
> reload
> {code}
> 7. Repeat same for TLSv1.2
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
> {code}
> 8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ]
Richard Opalka resolved WFWIP-160.
----------------------------------
Resolution: Cannot Reproduce
> Fix throughput and response time differences between TLS 1.2 and TLS 1.3
> ------------------------------------------------------------------------
>
> Key: WFWIP-160
> URL: https://issues.jboss.org/browse/WFWIP-160
> Project: WildFly WIP
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Richard Opalka
> Priority: Blocker
> Attachments: results-tlsv12.zip, results-tlsv13.zip
>
>
> Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
> Steps to reproduce (taken from EAP7-1022):
> 1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
> https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
> https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
> https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
> 2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
> 3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
> 4. Configure and start server with TLSv1.3 and JDK 11:
> {code}
> connect
> /subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
> /subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
> /subsystem=elytron/key-store=tls13:store()
> /subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
> /subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
> batch
> /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
> run-batch
> reload
> {code}
> 5. Start jmeter with JDK 11 and downloaded test plan
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
> {code}
> 6. Set server to use TLSv1.2
> {code}
> /subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
> reload
> {code}
> 7. Repeat same for TLSv1.2
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
> {code}
> 8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ]
Richard Opalka updated WFWIP-160:
---------------------------------
Attachment: results-tlsv12.zip
results-tlsv13.zip
> Fix throughput and response time differences between TLS 1.2 and TLS 1.3
> ------------------------------------------------------------------------
>
> Key: WFWIP-160
> URL: https://issues.jboss.org/browse/WFWIP-160
> Project: WildFly WIP
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Richard Opalka
> Priority: Blocker
> Attachments: results-tlsv12.zip, results-tlsv13.zip
>
>
> Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
> Steps to reproduce (taken from EAP7-1022):
> 1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
> https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
> https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
> https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
> 2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
> 3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
> 4. Configure and start server with TLSv1.3 and JDK 11:
> {code}
> connect
> /subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
> /subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
> /subsystem=elytron/key-store=tls13:store()
> /subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
> /subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
> batch
> /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
> run-batch
> reload
> {code}
> 5. Start jmeter with JDK 11 and downloaded test plan
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
> {code}
> 6. Set server to use TLSv1.2
> {code}
> /subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
> reload
> {code}
> 7. Repeat same for TLSv1.2
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
> {code}
> 8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ]
Richard Opalka commented on WFWIP-160:
--------------------------------------
I cannot reproduce this problem [~fjuma].
On my laptop TLS 1.3 is almost twice as fast as TLS 1.2.
My configuration is:
$>java -version
java version "11.0.4" 2019-07-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.4+10-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.4+10-LTS, mixed mode)
$>uname -a
Linux blackhole 5.3.6-200.fc30.x86_64 #1 SMP Mon Oct 14 13:11:01 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
https://github.com/ropalka/wildfly-elytron/tree/FJUMA-ELY-1706
https://github.com/ropalka/wildfly-core/tree/FJUMA-WFCORE-4172
https://github.com/ropalka/wildfly/tree/FJUMA-WFCORE-4172
> Fix throughput and response time differences between TLS 1.2 and TLS 1.3
> ------------------------------------------------------------------------
>
> Key: WFWIP-160
> URL: https://issues.jboss.org/browse/WFWIP-160
> Project: WildFly WIP
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Richard Opalka
> Priority: Blocker
>
> Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
> Steps to reproduce (taken from EAP7-1022):
> 1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
> https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
> https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
> https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
> 2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
> 3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
> 4. Configure and start server with TLSv1.3 and JDK 11:
> {code}
> connect
> /subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
> /subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
> /subsystem=elytron/key-store=tls13:store()
> /subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
> /subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
> batch
> /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
> run-batch
> reload
> {code}
> 5. Start jmeter with JDK 11 and downloaded test plan
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
> {code}
> 6. Set server to use TLSv1.2
> {code}
> /subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
> reload
> {code}
> 7. Repeat same for TLSv1.2
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
> {code}
> 8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (JGRP-2391) BindException on Windows
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2391?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2391:
--------------------------------
Have you seen my comment to your email on the ML? Try following the suggestions made there.
> BindException on Windows
> ------------------------
>
> Key: JGRP-2391
> URL: https://issues.jboss.org/browse/JGRP-2391
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.0, 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.1.5, 4.1.6
> Environment: Openjdk 13
> Microsoft Windows 10
> Reporter: Thorsten Marx
> Assignee: Bela Ban
> Priority: Major
>
> After updating to jgroups 4.1.6 i get the following BindException
> {code}
> java.net.BindException: Cannot assign requested address: Cannot bind
> at java.base/java.net.TwoStacksPlainDatagramSocketImpl.bind0(Native Method)
> at java.base/java.net.TwoStacksPlainDatagramSocketImpl.bind0(TwoStacksPlainDatagramSocketImpl.java:114)
> at java.base/java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:117)
> at java.base/java.net.TwoStacksPlainDatagramSocketImpl.bind(TwoStacksPlainDatagramSocketImpl.java:98)
> at java.base/java.net.DatagramSocket.bind(DatagramSocket.java:395)
> at java.base/java.net.MulticastSocket.<init>(MulticastSocket.java:176)
> at org.jgroups.util.DefaultSocketFactory.createMulticastSocket(DefaultSocketFactory.java:92)
> at org.jgroups.stack.DiagnosticsHandler.startUDP(DiagnosticsHandler.java:180)
> at org.jgroups.stack.DiagnosticsHandler.start(DiagnosticsHandler.java:122)
> at org.jgroups.protocols.TP.startDiagnostics(TP.java:1031)
> at org.jgroups.protocols.TP.start(TP.java:938)
> at org.jgroups.protocols.UDP.start(UDP.java:295)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:888)
> at org.jgroups.JChannel.startStack(JChannel.java:980)
> at org.jgroups.JChannel._preConnect(JChannel.java:844)
> at org.jgroups.JChannel.connect(JChannel.java:349)
> at org.jgroups.JChannel.connect(JChannel.java:343)
> at com.thorstenmarx.webtools.cluster.JGroupsTest.simple(JGroupsTest.java:43)
> {code}
> It seems to be caused by https://stackoverflow.com/questions/14086740/how-to-create-a-new-multicas...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4449) Visual design enhancements: Scenario/DMN error overlays
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4449?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton reassigned DROOLS-4449:
-----------------------------------------
Assignee: Brian Dellascio (was: Elizabeth Clayton)
> Visual design enhancements: Scenario/DMN error overlays
> -------------------------------------------------------
>
> Key: DROOLS-4449
> URL: https://issues.jboss.org/browse/DROOLS-4449
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor, Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Brian Dellascio
> Priority: Major
> Labels: ScenarioSimulation, Stunner, UX, UXTeam, drools-tools
> Attachments: ban-solid.svg, check-circle-regular.svg, check-circle-solid.svg, exclamation-circle-regular.svg, exclamation-circle-solid.svg
>
>
> Scenario and DMN editors share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) Support design consistency where applicable, while also documenting unique solutions per context.
> Verification conditions:
> - Review interaction design wireframes and click-thrus to offer recommendations for a consistent presentation for error overlays for the two editors (Scenario and DMN)
> - Wireframes posted at: https://issues.jboss.org/browse/DROOLS-4257 and https://issues.jboss.org/browse/DROOLS-3953.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4449) Visual design enhancements: Scenario/DMN error overlays
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4449?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton reassigned DROOLS-4449:
-----------------------------------------
Assignee: Elizabeth Clayton (was: Brian Dellascio)
> Visual design enhancements: Scenario/DMN error overlays
> -------------------------------------------------------
>
> Key: DROOLS-4449
> URL: https://issues.jboss.org/browse/DROOLS-4449
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor, Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: ScenarioSimulation, Stunner, UX, UXTeam, drools-tools
> Attachments: ban-solid.svg, check-circle-regular.svg, check-circle-solid.svg, exclamation-circle-regular.svg, exclamation-circle-solid.svg
>
>
> Scenario and DMN editors share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) Support design consistency where applicable, while also documenting unique solutions per context.
> Verification conditions:
> - Review interaction design wireframes and click-thrus to offer recommendations for a consistent presentation for error overlays for the two editors (Scenario and DMN)
> - Wireframes posted at: https://issues.jboss.org/browse/DROOLS-4257 and https://issues.jboss.org/browse/DROOLS-3953.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12695) Some .CLI commands that has been working since WF9 fails on WF18
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12695?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-12695:
-----------------------------------------
Thanks for the report!
I changed the component on this one because the problem is with the general server management layer, not particularly with the CLI. A non-CLI client would see the same problem.
It's possible it's a problem in how the undertow subsystem is set up, or it's a flaw in WildFly Core. I guessed and figured WF Core so I passed it to [~jmesnil], but [~flavia.rainone] FYI.
> Some .CLI commands that has been working since WF9 fails on WF18
> ----------------------------------------------------------------
>
> Key: WFLY-12695
> URL: https://issues.jboss.org/browse/WFLY-12695
> Project: WildFly
> Issue Type: Bug
> Components: Management, Web (Undertow)
> Affects Versions: 18.0.0.Final
> Reporter: Peter Jonsson
> Assignee: Jeff Mesnil
> Priority: Minor
>
> Error message is
> ERROR [org.jboss.as.cli.CommandContext] (CLI command) {
> "outcome" => "failed",
> "failure-description" => "java.lang.StackOverflowError:null"
> }
> And in the log
> 2019-10-21 19:14:44,377 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
> "address" => [("subsystem" => "undertow")],
> "operation" => "write-attribute",
> "name" => "statistics-enabled",
> "value" => true,
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE"
> }
> }]: java.lang.StackOverflowError
> at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:418)
> at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392)
> at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:426)
> at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12695) Some .CLI commands that has been working since WF9 fails on WF18
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12695?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-12695:
------------------------------------
Component/s: Management
Web (Undertow)
(was: CLI)
> Some .CLI commands that has been working since WF9 fails on WF18
> ----------------------------------------------------------------
>
> Key: WFLY-12695
> URL: https://issues.jboss.org/browse/WFLY-12695
> Project: WildFly
> Issue Type: Bug
> Components: Management, Web (Undertow)
> Affects Versions: 18.0.0.Final
> Reporter: Peter Jonsson
> Assignee: Jean Francois Denise
> Priority: Minor
>
> Error message is
> ERROR [org.jboss.as.cli.CommandContext] (CLI command) {
> "outcome" => "failed",
> "failure-description" => "java.lang.StackOverflowError:null"
> }
> And in the log
> 2019-10-21 19:14:44,377 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
> "address" => [("subsystem" => "undertow")],
> "operation" => "write-attribute",
> "name" => "statistics-enabled",
> "value" => true,
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE"
> }
> }]: java.lang.StackOverflowError
> at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:418)
> at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392)
> at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:426)
> at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12695) Some .CLI commands that has been working since WF9 fails on WF18
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12695?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFLY-12695:
---------------------------------------
Assignee: Jeff Mesnil (was: Jean Francois Denise)
> Some .CLI commands that has been working since WF9 fails on WF18
> ----------------------------------------------------------------
>
> Key: WFLY-12695
> URL: https://issues.jboss.org/browse/WFLY-12695
> Project: WildFly
> Issue Type: Bug
> Components: Management, Web (Undertow)
> Affects Versions: 18.0.0.Final
> Reporter: Peter Jonsson
> Assignee: Jeff Mesnil
> Priority: Minor
>
> Error message is
> ERROR [org.jboss.as.cli.CommandContext] (CLI command) {
> "outcome" => "failed",
> "failure-description" => "java.lang.StackOverflowError:null"
> }
> And in the log
> 2019-10-21 19:14:44,377 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
> "address" => [("subsystem" => "undertow")],
> "operation" => "write-attribute",
> "name" => "statistics-enabled",
> "value" => true,
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE"
> }
> }]: java.lang.StackOverflowError
> at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:418)
> at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392)
> at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:426)
> at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months