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