[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
[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
[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
[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
[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
[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