November 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4755) Need a more clear way to use RestWorkItemHandler to POST to an external service that uses application/x-www-form-urlencoded content-type

by Jonathan Fisher (Jira)

[ https://issues.jboss.org/browse/DROOLS-4755?page=com.atlassian.jira.plugi... ] Jonathan Fisher commented on DROOLS-4755: ----------------------------------------- https://github.com/kiegroup/jbpm/pull/1560 > Need a more clear way to use RestWorkItemHandler to POST to an external service that uses application/x-www-form-urlencoded content-type > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-4755 > URL: https://issues.jboss.org/browse/DROOLS-4755 > Project: Drools > Issue Type: Bug > Reporter: Danny Rucker > Assignee: Mario Fusco > Priority: Minor > > Need a more clear way to POST to application/x-www-form-urlencoded endpoint. > By passing an object that contains the data needed for the endpoint. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12718) Clustering: replicated-cache sampling errors

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12718?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-12718: ------------------------------------- Thanks [~tommaso-borgato]. I'll take a closer look at that specific commit. > Clustering: replicated-cache sampling errors > -------------------------------------------- > > Key: WFLY-12718 > URL: https://issues.jboss.org/browse/WFLY-12718 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 18.0.0.Final > Reporter: Tommasso Borgato > Assignee: Paul Ferraro > Priority: Blocker > > The issue is about replicated-cache in fail-over tests. > WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script: > {noformat} > embed-server --server-config=standalone-ha.xml > /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp) > /subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add() > /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ) > /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH) > /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add() > /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl) > {noformat} > The test is run with wildfly-18.0.0.Final.zip; > The same tests run with version wildfly-17.0.1.Final.zip do not have any problem; > hence this looks like a regression; > As usual, we test that the serial value stored in the replicated cache is incremented at every call: when this is not true, we say we have a sampling error; > Here are the runs that exhibit this issue: > - **22.82% Fail Rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...] > - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...] > We also repeated the tests to make sure it can be reproduced: > - **22.75% Fail rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#26|https://eap-qe-jenkins.r...] > - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#25|https://eap-qe-jenkins.r...] -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12691) Upgrade WildFly Core to 10.0.2.Final (Resolves CVE-2019-9515 and CVE-2019-14838)

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12691?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12691: ------------------------------------ Summary: Upgrade WildFly Core to 10.0.2.Final (Resolves CVE-2019-9515 and CVE-2019-14838) (was: Upgrade WildFly Core to 10.0.2.Final) > Upgrade WildFly Core to 10.0.2.Final (Resolves CVE-2019-9515 and CVE-2019-14838) > -------------------------------------------------------------------------------- > > Key: WFLY-12691 > URL: https://issues.jboss.org/browse/WFLY-12691 > Project: WildFly > Issue Type: Component Upgrade > Components: Server > Reporter: Brian Stansberry > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 18.0.1.Final > > > Upgrade tracker for 18.0.1.Final fixes coming in via WildFly Core. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4709) Upgrade Undertow to 2.0.27.Final (Resolves CVE-2019-9515)

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-4709?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-4709: ------------------------------------- Summary: Upgrade Undertow to 2.0.27.Final (Resolves CVE-2019-9515) (was: Upgrade Undertow to 2.0.27.Final) > Upgrade Undertow to 2.0.27.Final (Resolves CVE-2019-9515) > --------------------------------------------------------- > > Key: WFCORE-4709 > URL: https://issues.jboss.org/browse/WFCORE-4709 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Ivo Studensky > Assignee: Flavia Rainone > Priority: Blocker > Labels: downstream_dependency > Fix For: 10.0.2.Final, 11.0.0.Beta1 > > > Upgrade Undertow to 2.0.27.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4677) [DMN Designer] Data Types - Handle read-only Data Types in the drag and drop list

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-4677?page=com.atlassian.jira.plugi... ] Elizabeth Clayton updated DROOLS-4677: -------------------------------------- Story Points: 3 > [DMN Designer] Data Types - Handle read-only Data Types in the drag and drop list > --------------------------------------------------------------------------------- > > Key: DROOLS-4677 > URL: https://issues.jboss.org/browse/DROOLS-4677 > Project: Drools > Issue Type: Task > Components: DMN Editor > Affects Versions: 7.29.0.Final > Reporter: Guilherme Gomes > Assignee: Elizabeth Clayton > Priority: Major > Labels: UXTeam, drools-tools, ux > > The new drag and drop mechanism, added by the [Data Type UI enhancements|https://docs.google.com/presentation/u/1/d/10GZUd6oLaQohK27i...] does not specify how to handle read-only data types. > Scenarios: > - A User drags a regular data type to a position inside of read-only data type > - A User drags a read-only data type to a position inside of regular data type > _Notice: Read only data types appear when a DMN model has another DMN model included, and the external one has some data types._ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4449) Visual design enhancements: Scenario/DMN error overlays

by Brian Dellascio (Jira)

[ https://issues.jboss.org/browse/DROOLS-4449?page=com.atlassian.jira.plugi... ] Brian Dellascio commented on DROOLS-4449: ----------------------------------------- [~tirelli] I added two mockups to the end of this marvel prototype based on our conversation. Let me know if this matches your expectations. Thanks! https://marvelapp.com/7cjbjgb @[~uxdlc] > 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, 8 months

1
0
0 / 0

[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: ---------------------------------- Thanks for checking this [~jstourac]. [~ropalka] I'm going to re-open this issue. Any ideas what the difference could be caused by? > 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: jstourac-report.zip, 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, 8 months

1
0
0 / 0

[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 reopened WFWIP-160: ------------------------------ > 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: jstourac-report.zip, 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12796) Upgrade PicketLink from 2.5.5.SP12-redhat-00006 to 2.5.5.SP12-redhat-00009

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFLY-12796?page=com.atlassian.jira.plugin... ] Ilia Vassilev updated WFLY-12796: --------------------------------- Summary: Upgrade PicketLink from 2.5.5.SP12-redhat-00006 to 2.5.5.SP12-redhat-00009 (was: Upgrade PicketLink from 2.5.5.SP12-redhat-00007 to 2.5.5.SP12-redhat-00009) > Upgrade PicketLink from 2.5.5.SP12-redhat-00006 to 2.5.5.SP12-redhat-00009 > -------------------------------------------------------------------------- > > Key: WFLY-12796 > URL: https://issues.jboss.org/browse/WFLY-12796 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Affects Versions: 18.0.0.Final > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > > Branch: https://github.com/jbossas/redhat-picketlink/tree/2.5.5.SP > https://github.com/jbossas/redhat-picketlink/tree/v2.5.5.SP12-23-g954c19f58 > Commit hash: 954c19f58f61307bf1fed25e4147099dffaba5d4 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12796) Upgrade PicketLink from 2.5.5.SP12-redhat-00006 to 2.5.5.SP12-redhat-00009

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFLY-12796?page=com.atlassian.jira.plugin... ] Ilia Vassilev updated WFLY-12796: --------------------------------- Affects Version/s: 18.0.0.Final > Upgrade PicketLink from 2.5.5.SP12-redhat-00006 to 2.5.5.SP12-redhat-00009 > -------------------------------------------------------------------------- > > Key: WFLY-12796 > URL: https://issues.jboss.org/browse/WFLY-12796 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Affects Versions: 18.0.0.Final > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > > Branch: https://github.com/jbossas/redhat-picketlink/tree/2.5.5.SP > https://github.com/jbossas/redhat-picketlink/tree/v2.5.5.SP12-23-g954c19f58 > Commit hash: 954c19f58f61307bf1fed25e4147099dffaba5d4 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2019