October 2020 - jboss-jira - Jboss List Archives

[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 updated JGRP-2504: --------------------------------- Attachment: rcvbuf.png > 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, rcvbuf.png > > > 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 Andrew Skalski (Jira)

[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ] Andrew Skalski commented on JGRP-2504: -------------------------------------- I tested TCP and TCP_NIO2, and the throughput issue is now resolved. Thank you for looking into this! {quote}OK, so I read your comment. I understand socket options are inherited, but what sense does SO_SNDBUF make here? This option cannot be set on a ServerSocket anyway (perhaps this can be done in C?), only SO_RCVBUF, so does this mean the send-buffer cannot be set on a socket returned by accept()? {quote} That part of the documentation didn't make sense to me either. Reading through the Linux sources and verifying empirically, the SO_SNDBUF option is definitely being honored, even when it is configured on the accepted socket. {quote}Also: {quote}If the application explicitly configures SO_RCVBUF, this automatic management is disabled {quote} Does this mean, the value of SO_RCVBUF is the *max* value a receive window can have? {quote} Yes. SO_RCVBUF controls the buffer size, which in turn limits the receive window. (The receive window grows/shrinks over time in response to quantity of data received, congestion and packet loss, the rate at which the receiving application consumes the data, etc.) To illustrate, I configured both sites with SO_RCVBUF=200000 and graphed the window size over time during a send/receive test. !rcvbuf.png! > 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, rcvbuf.png > > > 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] (WFLY-13937) Upgrade WildFly Arquillian to 3.0.0.Final

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13937?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-13937: --------------------------------- Description: Upgrade WildFly Arquillian to 3.0.0.Final. Diff: https://github.com/wildfly/wildfly-arquillian/compare/2.2.0.Final...3.0.0... Release Notes: https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=12317120&vers... was: Upgrade WildFly Arquillian to 3.0.0.Final. Diff: https://github.com/wildfly/wildfly-arquillian/compare/2.2.0.Final....3.0.... Release Notes: https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=12317120&vers... > Upgrade WildFly Arquillian to 3.0.0.Final > ----------------------------------------- > > Key: WFLY-13937 > URL: https://issues.redhat.com/browse/WFLY-13937 > Project: WildFly > Issue Type: Component Upgrade > Components: Test Suite > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > Fix For: 21.0.0.Final > > > Upgrade WildFly Arquillian to 3.0.0.Final. > Diff: https://github.com/wildfly/wildfly-arquillian/compare/2.2.0.Final...3.0.0... > Release Notes: https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=12317120&vers... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13937) Upgrade WildFly Arquillian to 3.0.0.Final

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13937?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-13937: --------------------------------- Description: Upgrade WildFly Arquillian to 3.0.0.Final. Diff: https://github.com/wildfly/wildfly-arquillian/compare/2.2.0.Final....3.0.... Release Notes: https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=12317120&vers... was: Upgrade WildFly Arquillian to 3.0.0.Final. Diff: https://github.com/wildfly/wildfly-arquillian/compare/2.2.0.Final....3.0.... > Upgrade WildFly Arquillian to 3.0.0.Final > ----------------------------------------- > > Key: WFLY-13937 > URL: https://issues.redhat.com/browse/WFLY-13937 > Project: WildFly > Issue Type: Component Upgrade > Components: Test Suite > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > Fix For: 21.0.0.Final > > > Upgrade WildFly Arquillian to 3.0.0.Final. > Diff: https://github.com/wildfly/wildfly-arquillian/compare/2.2.0.Final....3.0.... > Release Notes: https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=12317120&vers... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13937) Upgrade WildFly Arquillian to 3.0.0.Final

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13937?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-13937: --------------------------------- Description: Upgrade WildFly Arquillian to 3.0.0.Final. Diff: https://github.com/wildfly/wildfly-arquillian/compare/2.2.0.Final....3.0.... was:Upgrade WildFly Arquillian to 3.0.0.Final. > Upgrade WildFly Arquillian to 3.0.0.Final > ----------------------------------------- > > Key: WFLY-13937 > URL: https://issues.redhat.com/browse/WFLY-13937 > Project: WildFly > Issue Type: Component Upgrade > Components: Test Suite > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > Fix For: 21.0.0.Final > > > Upgrade WildFly Arquillian to 3.0.0.Final. > Diff: https://github.com/wildfly/wildfly-arquillian/compare/2.2.0.Final....3.0.... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-2026) UnsupportedOperationException in SSLEngine using jdk 251+

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-2026?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on ELY-2026: --------------------------------------- The fix contributed to Undertow via https://issues.redhat.com/browse/UNDERTOW-1726 is presently required on the later JDK versions so that the JDK9AlpnProvider is only used on Java 9 or later. However updates to the latest version of Oracle Java 8 and believed to be incoming for OpenJDK 8 have broken the JDK8HackAlpnProvider implementation within Undertow. So we do need to get things working without UNDERTOW-1726 so that fix can be reverted / partially reverted. > UnsupportedOperationException in SSLEngine using jdk 251+ > --------------------------------------------------------- > > Key: ELY-2026 > URL: https://issues.redhat.com/browse/ELY-2026 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.10.9.Final > Reporter: Ricardo Martin Camarero > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.13.1.CR1 > > > Some SSLEngines provided by elytron does not implement the new TLS methods that jdk-8 251+ incorporated from jdk-11. That makes some tests in the wildfly-http-client to fail with the following exception: > {code} > 12:07:31,031 ERROR (XNIO-3 I/O-1) [org.xnio.listener] <ChannelListeners.java:94> XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException: > java.lang.reflect.InvocationTargetException > at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:99) > at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:81) > at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:77) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1211) > at io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1286) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:97) > ... 8 more > Caused by: java.lang.UnsupportedOperationException > at org.wildfly.security.ssl.JDKSpecific.getApplicationProtocol(JDKSpecific.java:35) > at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.getApplicationProtocol(AbstractDelegatingSSLEngine.java:166) > ... 13 more > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5152) Upgrade WildFly Elytron to 1.13.1.Final

by Darran Lofthouse (Jira)

Darran Lofthouse created WFCORE-5152: ---------------------------------------- Summary: Upgrade WildFly Elytron to 1.13.1.Final Key: WFCORE-5152 URL: https://issues.redhat.com/browse/WFCORE-5152 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 13.0.1.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-2026) UnsupportedOperationException in SSLEngine using jdk 251+

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-2026?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-2026: ---------------------------------- Priority: Blocker (was: Major) > UnsupportedOperationException in SSLEngine using jdk 251+ > --------------------------------------------------------- > > Key: ELY-2026 > URL: https://issues.redhat.com/browse/ELY-2026 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.10.9.Final > Reporter: Ricardo Martin Camarero > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.13.1.CR1 > > > Some SSLEngines provided by elytron does not implement the new TLS methods that jdk-8 251+ incorporated from jdk-11. That makes some tests in the wildfly-http-client to fail with the following exception: > {code} > 12:07:31,031 ERROR (XNIO-3 I/O-1) [org.xnio.listener] <ChannelListeners.java:94> XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException: > java.lang.reflect.InvocationTargetException > at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:99) > at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:81) > at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:77) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1211) > at io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1286) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:97) > ... 8 more > Caused by: java.lang.UnsupportedOperationException > at org.wildfly.security.ssl.JDKSpecific.getApplicationProtocol(JDKSpecific.java:35) > at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.getApplicationProtocol(AbstractDelegatingSSLEngine.java:166) > ... 13 more > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-2026) UnsupportedOperationException in SSLEngine using jdk 251+

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-2026?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-2026: ---------------------------------- Fix Version/s: 1.13.1.CR1 > UnsupportedOperationException in SSLEngine using jdk 251+ > --------------------------------------------------------- > > Key: ELY-2026 > URL: https://issues.redhat.com/browse/ELY-2026 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.10.9.Final > Reporter: Ricardo Martin Camarero > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.13.1.CR1 > > > Some SSLEngines provided by elytron does not implement the new TLS methods that jdk-8 251+ incorporated from jdk-11. That makes some tests in the wildfly-http-client to fail with the following exception: > {code} > 12:07:31,031 ERROR (XNIO-3 I/O-1) [org.xnio.listener] <ChannelListeners.java:94> XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException: > java.lang.reflect.InvocationTargetException > at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:99) > at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:81) > at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:77) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1211) > at io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1286) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:97) > ... 8 more > Caused by: java.lang.UnsupportedOperationException > at org.wildfly.security.ssl.JDKSpecific.getApplicationProtocol(JDKSpecific.java:35) > at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.getApplicationProtocol(AbstractDelegatingSSLEngine.java:166) > ... 13 more > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13924) HTTP2 is not working with Oracle JDK8 u261

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13924?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFLY-13924: ------------------------------------ Priority: Blocker (was: Critical) > HTTP2 is not working with Oracle JDK8 u261 > ------------------------------------------ > > Key: WFLY-13924 > URL: https://issues.redhat.com/browse/WFLY-13924 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 20.0.0.Final, 20.0.1.Final, 21.0.0.Beta1 > Reporter: Jan Stourac > Assignee: Flavia Rainone > Priority: Blocker > Fix For: 21.0.0.Final > > > There seems to be some problem with HTTP2 support with new Oracle JDK8 u261 and WildFly since {{20.0.0.Final}} version. When request against server is executed, then HTTP2 is not established and communication remains via HTTP/1.1. > There is no such issue when I use {{WildFly 19.0.0.Final}}. Also, if I switch back to an older Oracle JDK8 u241, there is no such issue even with newer WildFly versions. > This all seems to be tied with backport of ALPN support into the Oracle JDK8 recently and also work in following issue UNDERTOW-1726. > There seems to be a workaround available - to define '-Dio.undertow.protocols.alpn.jdk8' during the server startup. With this property configured, the issue seems to disappear (as such, blocker priority of this may be discussed). > *What is the issue here:* > This is a change in default behavior of the server (HTTP2 not working with Oracle JDK8u261+ since WildFly 20.0.0.Final). We should try to resolve this without default behavior change if possible. Only in case there is really no other solution, we need to document such thing. -- 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