October 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-1224) Remove MAISTRA_SUBS_CHANNEL parameter from jenkins jobs if no longer needed

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1224: ------------------------------------ Summary: Remove MAISTRA_SUBS_CHANNEL parameter from jenkins jobs if no longer needed Key: SWSQE-1224 URL: https://issues.redhat.com/browse/SWSQE-1224 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Assignee: Filip Brychta Do we still need choiceParam('MAISTRA_SUBS_CHANNEL', ['stable', 'old-1.0'], 'Channel used for Maistra/servicemesh subscription') ? If not remove it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

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

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2504: -------------------------------- I also changed the Jira URL, this will show up in the next update of the web site. > 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)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5033) Move org.wildfly.security:wildfly-elytron-jacc into it's own module

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5033?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5033: -------------------------------- Fix Version/s: 13.0.1.Final (was: 13.0.0.Final) > Move org.wildfly.security:wildfly-elytron-jacc into it's own module > ------------------------------------------------------------------- > > Key: WFCORE-5033 > URL: https://issues.redhat.com/browse/WFCORE-5033 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.1.Final > > > Long term it will be desirable for JACC to be within it's own subsystem so it's inclusion can be controlled using layers, however there may be an intermediate step where we split JACC out from the Elytron project so will want to bring it in ideally in it's own module. > The classes within this module have never been public API so we are free to refactor as needed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

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

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2504. ---------------------------- Resolution: Done > 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)

5 years, 7 months

1
0
0 / 0

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

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2504: -------------------------------- OK, it should work now, try it out and let me know. Cheers, > 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)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5688) Cleanup/refactoring public API

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5688?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-5688: ------------------------------------- Description: Refactor "public" API (i.e. API to be used by final user) moving them in the "API" module. Main classes involved: PMMLRuntimeFactory (drools) PmmlPredictionModel (kogito - remove direct access to KiePMMLModel; create an "end-user" DTO representation of KiePMMLModel) PMMLResource (used in both kogito and kie-maven-plugin) (?) was: Refactor "public" API (i.e. API to be used by final user) moving them in the "API" module. Main classes involved: PMMLRuntimeFactory (drools) PmmlPredictionModel (kogito - remove direct access to KiePMMLModel; create an "end-user" DTO representation of KiePMMLModel) PMMLResource (used in both kogito and kie-maven-plugin) > Cleanup/refactoring public API > ------------------------------ > > Key: DROOLS-5688 > URL: https://issues.redhat.com/browse/DROOLS-5688 > Project: Drools > Issue Type: Enhancement > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Refactor "public" API (i.e. API to be used by final user) moving them in the "API" module. > > Main classes involved: > PMMLRuntimeFactory (drools) > PmmlPredictionModel (kogito - remove direct access to KiePMMLModel; create an "end-user" DTO representation of KiePMMLModel) > PMMLResource (used in both kogito and kie-maven-plugin) (?) > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5151) dir-contexts referral-mode attribute upper/lower case discrepancy

by Ricardo Martin Camarero (Jira)

[ https://issues.redhat.com/browse/WFCORE-5151?page=com.atlassian.jira.plug... ] Ricardo Martin Camarero commented on WFCORE-5151: ------------------------------------------------- As the values were transformed to lower case intentionally in ELY-1637/WFCORE-3971, I'm going to send a PR changing the allowed values and default value to be in lower case too (just consistency). The values are really case insensitive because using an Enum and EnumValidator so I think nothing (no transformer) is needed. > dir-contexts referral-mode attribute upper/lower case discrepancy > ----------------------------------------------------------------- > > Key: WFCORE-5151 > URL: https://issues.redhat.com/browse/WFCORE-5151 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 13.0.0.Beta6 > Reporter: Jan Stourac > Assignee: Ricardo Martin Camarero > Priority: Minor > Attachments: reproducer.sh > > > There seems to be a discrepancy of the '/elytron/dir-context[referral-mode]' attribute represented value. > When there is no value set (default is applied), then particular value is printed in upper-case - {{IGNORE}}. Although, when we set custom value, then when we try to read it, it is printed in lower-case now, e.g. {{ignore}} (lower-case is also saved in raw xml configuration). > This behavior started with {{WildFly 15.0.0.Final}} and is still present in {{WildFly 20.0.0.Final}}. Not sure whether this change was intentional. I was able to find only this issue which may be kind of related WFCORE-3971. > In {{WildFly 14.0.0.Final}} there was always upper-case value printed. > What is the issue here: > # If this change was NOT intentional -> consider whether we would like to go to original behavior (upper-case returned always, including raw xml) > # If this change was intentional -> we should probably update so that even default value is lower-case as otherwise this behavior can be confusing for the customer - sometimes there is printed value in upper-case only, otherwise lower-case only. Also, this may be complication for customer automation scripts too. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13939) Upgrade SmallRye Metrics to 2.4.4

by Radoslav Husar (Jira)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13939) Upgrade SmallRye Metrics to 2.4.4

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13939?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13939: ---------------------------------- Description: Relases https://github.com/smallrye/smallrye-metrics/releases/tag/2.4.4 https://github.com/smallrye/smallrye-metrics/releases/tag/2.4.3 Changelog https://github.com/smallrye/smallrye-metrics/compare/2.4.3...2.4.4 https://github.com/smallrye/smallrye-metrics/compare/2.4.2...2.4.3 was: https://github.com/smallrye/smallrye-metrics/releases/tag/2.4.4 Changelog https://github.com/smallrye/smallrye-metrics/compare/2.4.3...2.4.4 https://github.com/smallrye/smallrye-metrics/compare/2.4.2...2.4.3 > Upgrade SmallRye Metrics to 2.4.4 > --------------------------------- > > Key: WFLY-13939 > URL: https://issues.redhat.com/browse/WFLY-13939 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Metrics > Affects Versions: 21.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 22.0.0.Beta1 > > > Relases > https://github.com/smallrye/smallrye-metrics/releases/tag/2.4.4 > https://github.com/smallrye/smallrye-metrics/releases/tag/2.4.3 > Changelog > https://github.com/smallrye/smallrye-metrics/compare/2.4.3...2.4.4 > https://github.com/smallrye/smallrye-metrics/compare/2.4.2...2.4.3 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13936) Upgrade smallrye-fault-tolerance to 4.3.1

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13936?page=com.atlassian.jira.plugi... ] Radoslav Husar edited comment on WFLY-13936 at 10/6/20 5:23 AM: ---------------------------------------------------------------- This is blocked by WFLY-13939 in which {{smalllrye-metrics}} introduces a new module. was (Author: rhusar): This is blocked by WFLY-13939 in which smalllrye-metrics introduces a new module... > Upgrade smallrye-fault-tolerance to 4.3.1 > ----------------------------------------- > > Key: WFLY-13936 > URL: https://issues.redhat.com/browse/WFLY-13936 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Fault Tolerance > Affects Versions: 21.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 22.0.0.Beta1 > > > Brings in new API module. > Release notes: > https://github.com/smallrye/smallrye-fault-tolerance/releases/tag/4.3.1 > Changes: > https://github.com/smallrye/smallrye-fault-tolerance/compare/4.3.0...4.3.1 > Notable changes: > Fixes: > https://github.com/smallrye/smallrye-fault-tolerance/commit/0e85a1ee4c689... > https://github.com/smallrye/smallrye-fault-tolerance/commit/28b2c26fc031a... > Improvements: > https://github.com/smallrye/smallrye-fault-tolerance/commit/af4ca42825c79... > https://github.com/smallrye/smallrye-fault-tolerance/commit/4b5081ba807ea... > "Breaking changes" > https://github.com/smallrye/smallrye-fault-tolerance/commit/e195d42b01f60... - this now requires a new module and new module dependency on 'smallrye-metrics-api' > Deprecations: > https://github.com/smallrye/smallrye-fault-tolerance/commit/b03f9d90d22b0... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 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 October 2020