[JBoss JIRA] (WFLY-12865) .CLI command to write attribute is giving a StackOverflow Exception
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-12865?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFLY-12865:
---------------------------------------
Component/s: Management
Assignee: Yeray Borges (was: Flavia Rainone)
[~yersan] Unless [~flavia.rainone] objects I'd like you to handle this as it looks much the same as WFLY-12695 and I suspect it has the same underlying cause.
> .CLI command to write attribute is giving a StackOverflow Exception
> -------------------------------------------------------------------
>
> Key: WFLY-12865
> URL: https://issues.redhat.com/browse/WFLY-12865
> Project: WildFly
> Issue Type: Bug
> Components: Management, Web (Undertow)
> Affects Versions: 18.0.1.Final
> Reporter: Jonathan Vila Lopez
> Assignee: Yeray Borges
> Priority: Blocker
> Fix For: 19.0.0.Beta1
>
>
> In the RHAMT team we are trying to migrate the application from WF 15 to WF 18.
> As part of the build the process starts WF and execute few .cli commands .
> I get a StackOverflowError in a command :
> {code:java}
> /subsystem=undertow/server=default-server/host=default-host/location=\//:write-attribute(name=handler,value=windup-web-redirect)
> Error
> Command execution failed for command '/subsystem=undertow/server=default-server/host=default-host/location=\//:write-attribute(name=handler,value=windup-web-redirect)'. {
> [ERROR] "outcome" => "failed",
> [ERROR] "failure-description" => "java.lang.StackOverflowError:null"
> [ERROR] }
> ^[[0m^[[31m17:48:42,651 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
> "address" => [
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("host" => "default-host"),
> ("location" => "/")
> ],
> "operation" => "write-attribute",
> "name" => "handler",
> "value" => "windup-web-redirect",
> "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)
> at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:426)
> at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392)
> at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:426)
> {code}
> If I connect to WF 18, using jboss-cli.sh and this is the result of the read command :
> {code}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/location=\//:read-attribute(name=handler)
> {
> "outcome" => "success",
> "result" => "welcome-content",
> "response-headers" => {"process-state" => "restart-required"}
> }
> {code}
> But if I do the write command :
> {code}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/location=\//:write-attribute(name=handler,value=windup-web-redirect)
> {
> "outcome" => "failed",
> "failure-description" => "java.lang.StackOverflowError:null"
> }
> {code}
> Even if I try to write the same value as I get from the read command it gives the same error.
> If I try to use *add* instead of *write-attribute*, I get a resource duplicated error.
> *This is stopping our current migration of RHAMT 4.3.0 to WF 18*
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-12865) .CLI command to write attribute is giving a StackOverflow Exception
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-12865?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-12865:
------------------------------------
Fix Version/s: 19.0.0.Beta1
> .CLI command to write attribute is giving a StackOverflow Exception
> -------------------------------------------------------------------
>
> Key: WFLY-12865
> URL: https://issues.redhat.com/browse/WFLY-12865
> Project: WildFly
> Issue Type: Bug
> Components: Management, Web (Undertow)
> Affects Versions: 18.0.1.Final
> Reporter: Jonathan Vila Lopez
> Assignee: Yeray Borges
> Priority: Blocker
> Fix For: 19.0.0.Beta1
>
>
> In the RHAMT team we are trying to migrate the application from WF 15 to WF 18.
> As part of the build the process starts WF and execute few .cli commands .
> I get a StackOverflowError in a command :
> {code:java}
> /subsystem=undertow/server=default-server/host=default-host/location=\//:write-attribute(name=handler,value=windup-web-redirect)
> Error
> Command execution failed for command '/subsystem=undertow/server=default-server/host=default-host/location=\//:write-attribute(name=handler,value=windup-web-redirect)'. {
> [ERROR] "outcome" => "failed",
> [ERROR] "failure-description" => "java.lang.StackOverflowError:null"
> [ERROR] }
> ^[[0m^[[31m17:48:42,651 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
> "address" => [
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("host" => "default-host"),
> ("location" => "/")
> ],
> "operation" => "write-attribute",
> "name" => "handler",
> "value" => "windup-web-redirect",
> "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)
> at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:426)
> at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392)
> at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:426)
> {code}
> If I connect to WF 18, using jboss-cli.sh and this is the result of the read command :
> {code}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/location=\//:read-attribute(name=handler)
> {
> "outcome" => "success",
> "result" => "welcome-content",
> "response-headers" => {"process-state" => "restart-required"}
> }
> {code}
> But if I do the write command :
> {code}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/location=\//:write-attribute(name=handler,value=windup-web-redirect)
> {
> "outcome" => "failed",
> "failure-description" => "java.lang.StackOverflowError:null"
> }
> {code}
> Even if I try to write the same value as I get from the read command it gives the same error.
> If I try to use *add* instead of *write-attribute*, I get a resource duplicated error.
> *This is stopping our current migration of RHAMT 4.3.0 to WF 18*
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFWIP-280) Warnings propagated from io.smallrye.jwt.auth.* don't have assigned ID
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFWIP-280?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFWIP-280:
----------------------------------------
There are many projects in WildFly that do not follow that standard.
Re "Messages generated by third-party code should be caught by the consumer, which will typically be a JBoss project. The consumer should then map the third-party framework error into something that is both meaningful to the user and follows this convention." -- that's totally impractical. For messages that basically means the logging layer has some sort of callout for every INFO or above message where we analyze or something and do a translation. Probably some pluggable set of translators, one per subsystem, that can be invoked until one marks the message as translated. Most messages not needing translation as they were produced with an id. For errors we stick catch (Throwable) blocks all over the place where we call into external code?
> Warnings propagated from io.smallrye.jwt.auth.* don't have assigned ID
> ----------------------------------------------------------------------
>
> Key: WFWIP-280
> URL: https://issues.redhat.com/browse/WFWIP-280
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Warning which are propagated to log from io.smallrye.jwt.auth package don't have assigned logging ID.
> Example:
> {code}
> 11:52:50,705 WARN [io.smallrye.jwt.auth.mechanism.JWTHttpAuthenticationMechanism] (default task-1) Unable to validate bearer token: Failed to verify token: io.smallrye.jwt.auth.principal.ParseException: Failed to verify token
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-12871) System Exception (EJBException) should be thrown instead of ApplicationException when rollback=false
by Ilia Vassilev (Jira)
[ https://issues.redhat.com/browse/WFLY-12871?page=com.atlassian.jira.plugi... ]
Ilia Vassilev moved JBEAP-18282 to WFLY-12871:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-12871 (was: JBEAP-18282)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
(was: EJB)
Affects Version/s: (was: 7.2.5.GA)
Fix Version/s: (was: 7.3.1.GA)
> System Exception (EJBException) should be thrown instead of ApplicationException when rollback=false
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-12871
> URL: https://issues.redhat.com/browse/WFLY-12871
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Ilia Vassilev
> Assignee: Panagiotis Sotiropoulos
> Priority: Major
> Labels: downstream_dependency
>
> During an EJB call throwing an application exception (rollback=false), if an exception occurs during transaction commit (such as in beforeCompletion) the original application exception is incorrectly being thrown to the caller instead of the tx exception.
> This bug appears to be caused by WFLY-10146
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3
by Andrew Haley (Jira)
[ https://issues.redhat.com/browse/WFWIP-160?page=com.atlassian.jira.plugin... ]
Andrew Haley commented on WFWIP-160:
------------------------------------
By the way, we are backporting full TLS 1.3 support to OpenJDK 8. I don't
have any idea why it'd be slower: the cryptographic functions are the same.
So it might make the most sense to wait until we have real 1.3 support
next year.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> Fix throughput and response time differences between TLS 1.2 and TLS 1.3
> ------------------------------------------------------------------------
>
> Key: WFWIP-160
> URL: https://issues.redhat.com/browse/WFWIP-160
> Project: WildFly WIP
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Richard Opalka
> Priority: Blocker
> Attachments: jstourac-report.zip, performance-hotspot.png, 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. Start server with JDK11 and configure with TLSv1.3:
> {code}
> $ JAVA_HOME=/path/to/java/openjdk-11.0.2 <EAP_HOME>/bin/standalone.sh
> $ <EAP_HOME>/bin/jboss-cli.sh -c
> /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, 5 months
[JBoss JIRA] (WFLY-11481) EL expressions that contain unnecessary parentheses fail
by Brad Maxwell (Jira)
[ https://issues.redhat.com/browse/WFLY-11481?page=com.atlassian.jira.plugi... ]
Brad Maxwell reassigned WFLY-11481:
-----------------------------------
Assignee: Ricardo Martin Camarero (was: Teresa Miyar Gil)
> EL expressions that contain unnecessary parentheses fail
> --------------------------------------------------------
>
> Key: WFLY-11481
> URL: https://issues.redhat.com/browse/WFLY-11481
> Project: WildFly
> Issue Type: Bug
> Reporter: Teresa Miyar Gil
> Assignee: Ricardo Martin Camarero
> Priority: Major
> Labels: el-expresion
> Attachments: helloworld.war
>
>
> EL with unnecessary parentheses fail. For instance:
> {code}
> <c:set var = "i" scope = "session" value = "1"/>
> <c:if test="${(i) == '1'}">
> <p>i is: <c:out value = "${i}"/><p>
> </c:if>
> {code}
> The root exception clarified by byteman is:
> {code}
> 15:16:51,903 INFO [stdout] (http_8080 task-1) ----------------------->ParseException.init
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ParseException.<init>(ParseException.java:179)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.generateParseException(ELParser.java:2963)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.jj_consume_token(ELParser.java:2845)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.LambdaExpression(ELParser.java:295)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.Assignment(ELParser.java:226)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.SemiColon(ELParser.java:181)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.Expression(ELParser.java:174)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.DynamicExpression(ELParser.java:146)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.CompositeExpression(ELParser.java:43)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.lang.ExpressionBuilder.createNodeInternal(ExpressionBuilder.java:182)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.lang.ExpressionBuilder.build(ExpressionBuilder.java:237)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.lang.ExpressionBuilder.createValueExpression(ExpressionBuilder.java:295)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.ExpressionFactoryImpl.createValueExpression(ExpressionFactoryImpl.java:112)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$JspAttribute.validateEL(Node.java:2151)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator$ValidateVisitor.getJspAttribute(Validator.java:1400)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator$ValidateVisitor.checkXmlAttributes(Validator.java:1204)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:855)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1535)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2375)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2427)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2433)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Root.accept(Node.java:464)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2375)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1834)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> {code}
> Parser seems confused as if there's a Lamda expression to resolve. Seems tomcat had a similar issue:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=56179
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months