December 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4695) [DMN Designer] BC DOs as DMN DTs - Show a success message after the import operation

by Daniel José dos Santos (Jira)

[ https://issues.redhat.com/browse/DROOLS-4695?page=com.atlassian.jira.plug... ] Daniel José dos Santos commented on DROOLS-4695: ------------------------------------------------ The message was changed to "The Data Object (java class) was successfully imported and converted to DMN data type." as discussed in GChat. > [DMN Designer] BC DOs as DMN DTs - Show a success message after the import operation > ------------------------------------------------------------------------------------ > > Key: DROOLS-4695 > URL: https://issues.redhat.com/browse/DROOLS-4695 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Daniel José dos Santos > Priority: Major > Labels: drools-tools > Attachments: success.png > > > Show the following success message after the import operation: > !success.png|width=600! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 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.redhat.com/browse/WFWIP-160?page=com.atlassian.jira.plugin... ] Farah Juma commented on WFWIP-160: ---------------------------------- Thanks, [~aph]. > 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

1
0
0 / 0

[JBoss JIRA] (WFLY-12881) Cannot customize split detection and merge policy for Infinispan partition handling

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12881?page=com.atlassian.jira.plugi... ] Radoslav Husar reassigned WFLY-12881: ------------------------------------- Assignee: Radoslav Husar (was: Paul Ferraro) > Cannot customize split detection and merge policy for Infinispan partition handling > ----------------------------------------------------------------------------------- > > Key: WFLY-12881 > URL: https://issues.redhat.com/browse/WFLY-12881 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 18.0.1.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Priority: Critical > > Currently, partition handling of an Infinispan cache is hard coded. When enabled, both reads and writes are denied on minority partitions (of a given segment) and, more critically, upon partition merge, no reconciliation of any data conflicts occurs. > Users need to be able to configure this, at least to support the built in read/write on split policy and the built-in merge policies. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12882) Add user API to handle merging HttpSession attributes/metadata on partition merge

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-12882?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-12882: -------------------------------- Description: When partition handling of a web session cache is enabled, users need a mechanism to control how to resolve conflicting session attributes on merge. Something like: {code:java} public interface SessionAttributeMergePolicy<T>() { T prefer(String attributeName, T primaryPartitionAttribute, List<T> minorityPartitionAttributes); } {code} was: When partition handling of a web session cache is enabled, users need a mechanism to control how to resolve conflicting session attributes on merge. Something like: public interface SessionAttributeMergePolicy<T>() { T prefer(String attributeName, T primaryPartitionAttribute, List<T> minorityPartitionAttributes); } > Add user API to handle merging HttpSession attributes/metadata on partition merge > --------------------------------------------------------------------------------- > > Key: WFLY-12882 > URL: https://issues.redhat.com/browse/WFLY-12882 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 18.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > When partition handling of a web session cache is enabled, users need a mechanism to control how to resolve conflicting session attributes on merge. > Something like: > {code:java} > public interface SessionAttributeMergePolicy<T>() { > T prefer(String attributeName, T primaryPartitionAttribute, List<T> minorityPartitionAttributes); > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12882) Add user API to handle merging HttpSession attributes/metadata on partition merge

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-12882?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-12882: -------------------------------- Description: When partition handling of a web session cache is enabled, users need a mechanism to control how to resolve conflicting session attributes on merge. Something like: public interface SessionAttributeMergePolicy<T>() { T prefer(String attributeName, T primaryPartitionAttribute, List<T> minorityPartitionAttributes); } > Add user API to handle merging HttpSession attributes/metadata on partition merge > --------------------------------------------------------------------------------- > > Key: WFLY-12882 > URL: https://issues.redhat.com/browse/WFLY-12882 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 18.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > When partition handling of a web session cache is enabled, users need a mechanism to control how to resolve conflicting session attributes on merge. > Something like: > public interface SessionAttributeMergePolicy<T>() { > T prefer(String attributeName, T primaryPartitionAttribute, List<T> minorityPartitionAttributes); > } -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12881) Cannot customize split detection and merge policy for Infinispan partition handling

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-12881?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-12881: -------------------------------- Description: Currently, partition handling of an Infinispan cache is hard coded. When enabled, both reads and writes are denied on minority partitions (of a given segment) and, more critically, upon partition merge, no reconciliation of any data conflicts occurs. Users need to be able to configure this, at least to support the built in read/write on split policy and the built-in merge policies. was: Currently, partition handling of an Infinispan cache is hard coded. When enabled, both reads and writes are denied on minority partitions (of a given segment) and, more critically, upon partition merge, no reconciliation of data conflicts occur. Users need to be able to configure this, at least to support the built in read/write on split policy and the built-in merge policies. > Cannot customize split detection and merge policy for Infinispan partition handling > ----------------------------------------------------------------------------------- > > Key: WFLY-12881 > URL: https://issues.redhat.com/browse/WFLY-12881 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 18.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > Currently, partition handling of an Infinispan cache is hard coded. When enabled, both reads and writes are denied on minority partitions (of a given segment) and, more critically, upon partition merge, no reconciliation of any data conflicts occurs. > Users need to be able to configure this, at least to support the built in read/write on split policy and the built-in merge policies. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12881) Cannot customize split detection and merge policy for Infinispan partition handling

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-12881?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-12881: -------------------------------- Description: Currently, partition handling of an Infinispan cache is hard coded. When enabled, both reads and writes are denied on minority partitions (of a given segment) and, more critically, upon partition merge, no reconciliation of data conflicts occur. Users need to be able to configure this, at least to support the built in read/write on split policy and the built-in merge policies. was: Currently, partition handling of an Infinispan cache is hard coded. When enabled, both reads and writes are denied on minority partitions (of a given segment) and, more critically, upon partition merge, no data reconciliation occurs. Users need to be able to configure this, at least to support the built in read/write on split policy and the built-in merge policies. > Cannot customize split detection and merge policy for Infinispan partition handling > ----------------------------------------------------------------------------------- > > Key: WFLY-12881 > URL: https://issues.redhat.com/browse/WFLY-12881 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 18.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > Currently, partition handling of an Infinispan cache is hard coded. When enabled, both reads and writes are denied on minority partitions (of a given segment) and, more critically, upon partition merge, no reconciliation of data conflicts occur. > Users need to be able to configure this, at least to support the built in read/write on split policy and the built-in merge policies. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12884) Invalidation caches should always remove entries on partition merge

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-12884: ----------------------------------- Summary: Invalidation caches should always remove entries on partition merge Key: WFLY-12884 URL: https://issues.redhat.com/browse/WFLY-12884 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 18.0.1.Final Reporter: Paul Ferraro Assignee: Paul Ferraro When a partition merges, invalidation-caches should always remove entries in the case of a data conflict. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12881) Cannot customize split detection and merge policy for Infinispan partition handling

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-12881?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-12881: -------------------------------- Description: Currently, partition handling of an Infinispan cache is hard coded. When enabled, both reads and writes are denied on minority partitions (of a given segment) and, more critically, upon partition merge, no data reconciliation occurs. Users need to be able to configure this, at least to support the built in read/write on split policy and the built-in merge policies. was:Currently, when partition handling is enabled on a cache, both reads and writes are denied on minority partitions (of a given segment) and upon partition merge, and critically, no data reconciliation occurs. This is effectively hard coded, and users do not have the ability to customize this. Users need to be able to configure this, at least to support the built in read/write on split policy and the built-in merge policies. > Cannot customize split detection and merge policy for Infinispan partition handling > ----------------------------------------------------------------------------------- > > Key: WFLY-12881 > URL: https://issues.redhat.com/browse/WFLY-12881 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 18.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > Currently, partition handling of an Infinispan cache is hard coded. When enabled, both reads and writes are denied on minority partitions (of a given segment) and, more critically, upon partition merge, no data reconciliation occurs. > Users need to be able to configure this, at least to support the built in read/write on split policy and the built-in merge policies. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12883) Add user API to handle merging @Stateful EJB instances on partition merge

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-12883: ----------------------------------- Summary: Add user API to handle merging @Stateful EJB instances on partition merge Key: WFLY-12883 URL: https://issues.redhat.com/browse/WFLY-12883 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 18.0.1.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 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 December 2019