October 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5684) DMN DT Analysis Misleading rule definition refinements

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5684?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5684: ----------------------------------- Description: The original definition is: bq. P tables can be “misleading” when rule contains hyphen input entry (“irrelevant”) and output is not lowest priority which was implemented with [DROOLS-3785]. Further refinements checked to avoid duplicating "Misleading rule" reports when in fact the rules were already reported as "Masked", with: [DROOLS-5368] However, a table such as the below would inadvertently still report misleading rules: !screenshot-1.png|thumbnail! So the new definition is refined to: {quote}P tables can be “misleading” when: * rule contains hyphen input entry (“irrelevant”) * and output is not lowest priority * the hyphen in the misleading rule, correspond to a value (not an hyphen) in the mislead('d) rule {quote} was: The original definition is: bq. P tables can be “misleading” when rule contains hyphen input entry (“irrelevant”) and output is not lowest priority which was implemented with [DROOLS-3785]. Further refinements checked to avoid duplicating "Misleading rule" reports when in fact the rules were already reported as "Masked", with: [DROOLS-5368] However, a table such as the below would inadvertently still report misleading rules: !screenshot-1.png! So the new definition is refined to: {quote}P tables can be “misleading” when: * rule contains hyphen input entry (“irrelevant”) * and output is not lowest priority * the hyphen in the misleading rule, correspond to a value (not an hyphen) in the mislead('d) rule {quote} > DMN DT Analysis Misleading rule definition refinements > ------------------------------------------------------ > > Key: DROOLS-5684 > URL: https://issues.redhat.com/browse/DROOLS-5684 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > Attachments: screenshot-1.png > > > The original definition is: > bq. P tables can be “misleading” when rule contains hyphen input entry (“irrelevant”) and output is not lowest priority > which was implemented with [DROOLS-3785]. > Further refinements checked to avoid duplicating "Misleading rule" reports when in fact the rules were already reported as "Masked", with: [DROOLS-5368] > However, a table such as the below would inadvertently still report misleading rules: > !screenshot-1.png|thumbnail! > So the new definition is refined to: > {quote}P tables can be “misleading” when: > * rule contains hyphen input entry (“irrelevant”) > * and output is not lowest priority > * the hyphen in the misleading rule, correspond to a value (not an hyphen) in the mislead('d) rule > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5684) DMN DT Analysis Misleading rule definition refinements

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5684?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5684: ----------------------------------- Description: The original definition is: bq. P tables can be “misleading” when rule contains hyphen input entry (“irrelevant”) and output is not lowest priority which was implemented with [DROOLS-3785]. Further refinements checked to avoid duplicating "Misleading rule" reports when in fact the rules were already reported as "Masked", with: [DROOLS-5368] However, a table such as the below would inadvertently still report misleading rules: !screenshot-1.png! So the new definition is refined to: {quote}P tables can be “misleading” when: * rule contains hyphen input entry (“irrelevant”) * and output is not lowest priority * the hyphen in the misleading rule, correspond to a value (not an hyphen) in the mislead('d) rule {quote} was: The original definition is: bq. P tables can be “misleading” when rule contains hyphen input entry (“irrelevant”) and output is not lowest priority which was implemented with [https://issues.redhat.com/browse/DROOLS-3785] > DMN DT Analysis Misleading rule definition refinements > ------------------------------------------------------ > > Key: DROOLS-5684 > URL: https://issues.redhat.com/browse/DROOLS-5684 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > Attachments: screenshot-1.png > > > The original definition is: > bq. P tables can be “misleading” when rule contains hyphen input entry (“irrelevant”) and output is not lowest priority > which was implemented with [DROOLS-3785]. > Further refinements checked to avoid duplicating "Misleading rule" reports when in fact the rules were already reported as "Masked", with: [DROOLS-5368] > However, a table such as the below would inadvertently still report misleading rules: > !screenshot-1.png! > So the new definition is refined to: > {quote}P tables can be “misleading” when: > * rule contains hyphen input entry (“irrelevant”) > * and output is not lowest priority > * the hyphen in the misleading rule, correspond to a value (not an hyphen) in the mislead('d) rule > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5684) DMN DT Analysis Misleading rule definition refinements

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5684?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5684: ----------------------------------- Attachment: screenshot-1.png > DMN DT Analysis Misleading rule definition refinements > ------------------------------------------------------ > > Key: DROOLS-5684 > URL: https://issues.redhat.com/browse/DROOLS-5684 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > Attachments: screenshot-1.png > > > The original definition is: > bq. P tables can be “misleading” when rule contains hyphen input entry (“irrelevant”) and output is not lowest priority > which was implemented with [https://issues.redhat.com/browse/DROOLS-3785] -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13912) Upgrade RESTEasy to 3.13.2.Final

by Alessio Soldano (Jira)

[ https://issues.redhat.com/browse/WFLY-13912?page=com.atlassian.jira.plugi... ] Alessio Soldano closed WFLY-13912. ---------------------------------- Resolution: Duplicate Issue > Upgrade RESTEasy to 3.13.2.Final > -------------------------------- > > Key: WFLY-13912 > URL: https://issues.redhat.com/browse/WFLY-13912 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Priority: Critical > Fix For: 21.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5684) DMN DT Analysis Misleading rule definition refinements

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5684?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5684: ----------------------------------- Description: The original definition is: bq. P tables can be “misleading” when rule contains hyphen input entry (“irrelevant”) and output is not lowest priority which was implemented with [https://issues.redhat.com/browse/DROOLS-3785] > DMN DT Analysis Misleading rule definition refinements > ------------------------------------------------------ > > Key: DROOLS-5684 > URL: https://issues.redhat.com/browse/DROOLS-5684 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > The original definition is: > bq. P tables can be “misleading” when rule contains hyphen input entry (“irrelevant”) and output is not lowest priority > which was implemented with [https://issues.redhat.com/browse/DROOLS-3785] -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5684) DMN DT Analysis Misleading rule definition refinements

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5684: -------------------------------------- Summary: DMN DT Analysis Misleading rule definition refinements Key: DROOLS-5684 URL: https://issues.redhat.com/browse/DROOLS-5684 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured

by Andrew Skalski (Jira)

[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ] Andrew Skalski commented on JGRP-2504: -------------------------------------- Here's what I found based on further research. The Linux kernel manages the TCP receive window in two different ways (this is a simplification) depending on whether or not the SO_RCVBUF socket option was explicitly set by the application. By default, the kernel automatically manages the receive buffer and window clamp (an internal per-socket variable that acts as a ceiling on window size) based on the min/default/max sizes defined in the net.ipv4.tcp_rmem sysctl. If the application explicitly configures SO_RCVBUF, this automatic management is disabled. The window clamp is initialized once at handshake time, and does not change, even if SO_RCVBUF is subsequently updated. In the case where the application configures SO_RCVBUF "too late" (after the handshake), the socket ends up in a state where: * Window clamp was initialized based on a small default value * Automatic growth of window clamp is disabled Consequently, throughput is actually worse than if SO_RCVBUF was left unconfigured. (This also explains why recent versions of JGroups performed better for me _by default_ than older versions: the builtin default value for recv_buf_size was removed.) Regarding whether or not the SO_RCVBUF setting is inherited from the listening socket, I found this in chapter 7 of _UNIX Network Programming, Volume 1: The Sockets Networking API, Third Edition_: {quote}The following socket options are inherited by a connected TCP socket from the listening socket (pp. 462–463 of TCPv2): {{SO_DEBUG}}, {{SO_DONTROUTE}}, {{SO_KEEPALIVE}}, {{SO_LINGER}}, {{SO_OOBINLINE}}, {{SO_RCVBUF}}, {{SO_RCVLOWAT}}, {{SO_SNDBUF}}, {{SO_SNDLOWAT}}, {{TCP_MAXSEG}}, and {{TCP_NODELAY}}. This is important with TCP because the connected socket is not returned to a server by {{accept}} until the three-way handshake is completed by the TCP layer. To ensure that one of these socket options is set for the connected socket when the three-way handshake completes, we must set that option for the listening socket. {quote} > Poor throughput over high latency TCP connection when recv_buf_size is configured > --------------------------------------------------------------------------------- > > Key: JGRP-2504 > URL: https://issues.redhat.com/browse/JGRP-2504 > Project: JGroups > Issue Type: Bug > Affects Versions: 5.0.0.Final > Reporter: Andrew Skalski > Assignee: Bela Ban > Priority: Minor > Fix For: 5.1 > > Attachments: SpeedTest.java, bla5.java, bla6.java, bla7.java, delay-ip.sh > > > I recently finished troubleshooting a unidirectional throughput bottleneck involving a JGroups application (Infinispan) communicating over a high-latency (~45 milliseconds) TCP connection. > The root cause was JGroups improperly configuring the receive/send buffers on the listening socket. According to the tcp(7) man page: > {code:java} > On individual connections, the socket buffer size must be set prior to > the listen(2) or connect(2) calls in order to have it take effect. > {code} > However, JGroups does not set the buffer size on the listening side until after accept(). > The result is poor throughput when sending data from client (connecting side) to server (listening side.) Because the issue is a too-small TCP receive window, throughput is ultimately latency-bound. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13922) Upgrade RESTEasy to 3.13.2.Final

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13922?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-13922: --------------------------------- Description: Upgrade from 3.11.2.Final to 3.12.0.Final Diff: https://github.com/resteasy/Resteasy/compare/3.13.1.Final...3.13.2.Final was:Upgrade from 3.11.2.Final to 3.12.0.Final > Upgrade RESTEasy to 3.13.2.Final > -------------------------------- > > Key: WFLY-13922 > URL: https://issues.redhat.com/browse/WFLY-13922 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Ronald Sigal > Assignee: Ronald Sigal > Priority: Major > Labels: downstream_dependency > Fix For: 21.0.0.Beta1 > > > Upgrade from 3.11.2.Final to 3.12.0.Final > Diff: https://github.com/resteasy/Resteasy/compare/3.13.1.Final...3.13.2.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5133) SNICombinedWithALPNTestCase fails with oracle JDK 8 261

by Jan Stourac (Jira)

[ https://issues.redhat.com/browse/WFCORE-5133?page=com.atlassian.jira.plug... ] Jan Stourac edited comment on WFCORE-5133 at 9/30/20 8:05 PM: -------------------------------------------------------------- [Comment here|https://issues.redhat.com/browse/JBEAP-20279?focusedCommentId=152030...] may explain the different results we can see when property is defined and when not. Sonia correctly mentioned issue with 'java.lang.NoSuchFieldException: handshaker' exception from [JDK8AlpnProvider|https://github.com/undertow-io/undertow/blob/master/core...] in her first comment in this issue. As such, my thoughts: # [JDK8AlpnProvider|https://github.com/undertow-io/undertow/blob/master/core...] may need to be updated to work with Oracle JDK8_261+. Although, since JDK8 251+ supports the ALPN natively, we shall try to exploit this native implementation, probably via [JDK9AlpnProvider|https://github.com/undertow-io/undertow/blob/master/core...] (now need to be enforced via the 'io.undertow.protocols.alpn.jdk8' property). # It looks like there is some issue in [JDK9AlpnProvider|https://github.com/undertow-io/undertow/blob/master/core...] to support HTTP2 protocol in this test scenario as HTTP/1.1 is used instead. was (Author: jstourac): [Comment here|https://issues.redhat.com/browse/JBEAP-20279?focusedCommentId=152030...] may explain the different results we can see when property is defined and when not. Sonia correctly mentioned issue with 'java.lang.NoSuchFieldException: handshaker' exception from [JDK8AlpnProvider|https://github.com/undertow-io/undertow/blob/master/core...] in her first comment in this issue. As such, my thoughts: # [JDK8AlpnProvider|https://github.com/undertow-io/undertow/blob/master/core...] may need to be updated to work with Oracle JDK8_261+. Although, since JDK8 251+ supports the ALPN natively, we shall try to exploit this native implementation, probably via [JDK9AlpnProvider|https://github.com/undertow-io/undertow/blob/master/core...]. # It looks like there is some issue in [JDK9AlpnProvider|https://github.com/undertow-io/undertow/blob/master/core...] to support HTTP2 protocol in this test scenario as HTTP/1.1 is used instead. > SNICombinedWithALPNTestCase fails with oracle JDK 8 261 > ------------------------------------------------------- > > Key: WFCORE-5133 > URL: https://issues.redhat.com/browse/WFCORE-5133 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jean Francois Denise > Assignee: Sonia Zaldana > Priority: Major > > Exception while using oracle JDK 261: > > {code} > at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:444) > at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:439) > at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:430) > at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:347) > at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.performSimpleTest(SNICombinedWithALPNTestCase.java:242) > at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.testSimpleViaHostname(SNICombinedWithALPNTestCase.java:220) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5133) SNICombinedWithALPNTestCase fails with oracle JDK 8 261

by Jan Stourac (Jira)

[ https://issues.redhat.com/browse/WFCORE-5133?page=com.atlassian.jira.plug... ] Jan Stourac commented on WFCORE-5133: ------------------------------------- [Comment here|https://issues.redhat.com/browse/JBEAP-20279?focusedCommentId=152030...] may explain the different results we can see when property is defined and when not. Sonia correctly mentioned issue with 'java.lang.NoSuchFieldException: handshaker' exception from [JDK8AlpnProvider|https://github.com/undertow-io/undertow/blob/master/core...] in her first comment in this issue. As such, my thoughts: # [JDK8AlpnProvider|https://github.com/undertow-io/undertow/blob/master/core...] may need to be updated to work with Oracle JDK8_261+. Although, since JDK8 251+ supports the ALPN natively, we shall try to exploit this native implementation, probably via [JDK9AlpnProvider|https://github.com/undertow-io/undertow/blob/master/core...]. # It looks like there is some issue in [JDK9AlpnProvider|https://github.com/undertow-io/undertow/blob/master/core...] to support HTTP2 protocol in this test scenario as HTTP/1.1 is used instead. > SNICombinedWithALPNTestCase fails with oracle JDK 8 261 > ------------------------------------------------------- > > Key: WFCORE-5133 > URL: https://issues.redhat.com/browse/WFCORE-5133 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jean Francois Denise > Assignee: Sonia Zaldana > Priority: Major > > Exception while using oracle JDK 261: > > {code} > at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:444) > at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:439) > at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:430) > at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:347) > at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.performSimpleTest(SNICombinedWithALPNTestCase.java:242) > at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.testSimpleViaHostname(SNICombinedWithALPNTestCase.java:220) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2020