[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 edited comment on JGRP-2504 at 9/30/20 7:22 AM:
---------------------------------------------------------
The attached {{bla5.java}} shows the issue: when line 22 is commented, the receive buffer is not as big as desired. Ditto for {{bla6.java}}, which shows how to do this with ServerSocketChannels.
was (Author: belaban):
The attached {{bla5.java}} shows the issue: when line 22 is commented, the receive buffer is not as big as desired.
> 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
>
>
> 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)
4 years, 12 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 updated JGRP-2504:
---------------------------
Attachment: bla6.java
> 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
>
>
> 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)
4 years, 12 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:
--------------------------------
The attached {{bla5.java}} shows the issue: when line 22 is commented, the receive buffer is not as big as desired.
> 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
>
>
> 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)
4 years, 12 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 updated JGRP-2504:
---------------------------
Attachment: bla5.java
> 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
>
>
> 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)
4 years, 12 months
[JBoss JIRA] (DROOLS-5638) Majority vote operator does not work in mining model
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5638?page=com.atlassian.jira.plug... ]
Gabriele Cardosi closed DROOLS-5638.
------------------------------------
> Majority vote operator does not work in mining model
> ----------------------------------------------------
>
> Key: DROOLS-5638
> URL: https://issues.redhat.com/browse/DROOLS-5638
> Project: Drools
> Issue Type: Bug
> Components: PMML
> Affects Versions: 7.44.0.Final
> Reporter: Jiri Petrlik
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: TrustyAI
>
> Majority vote operator does not work in new PMML implementation. Evaluation fails with the following exception:
> java.lang.NullPointerException
> at org.drools.core.rule.constraint.MvelConstraint.equals(MvelConstraint.java:675)
> at org.drools.core.reteoo.AlphaNode.equals(AlphaNode.java:198)
> at java.base/java.util.HashMap.getNode(HashMap.java:567)
> at java.base/java.util.HashMap.get(HashMap.java:552)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.getMatchingNode(CompositeObjectSinkAdapter.java:523)
> at org.drools.core.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:117)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 12 months
[JBoss JIRA] (WFLY-13919) (7.3.z) "Contains non-LDH ASCII" characters during remote EJB SSL call in IPV6 network
by Ivo Studensky (Jira)
Ivo Studensky created WFLY-13919:
------------------------------------
Summary: (7.3.z) "Contains non-LDH ASCII" characters during remote EJB SSL call in IPV6 network
Key: WFLY-13919
URL: https://issues.redhat.com/browse/WFLY-13919
Project: WildFly
Issue Type: Bug
Components: EJB, Web (Undertow)
Affects Versions: 19.1.0.Final
Reporter: Ivo Studensky
Assignee: Flavia Rainone
*Summary*: " Contains non-LDH ASCII characters " during any remote EJB SSL call in IPV6 network on Kubernetes
*Problem Description*
We are doing EJB call SSL from client container A to EJB located in container B. I reproduced this issue with two different remote EJB SLL call.
Unfortunately, this is only happening on some of our servers. It's difficult to reproduce since we need Kubernetes/IPV6 stack only - and I don't have a test case for it locally.
The wildfly context use to get the ejb (javax.naming.InitialContext) in our app is using this url
java.naming.provider.url=[https://my-server:8443/wildfly-services]
as you can see the hostname is my-server. my-server does not have illegal characters and SNIHostName does not throw an exception when using it in a small unit test.
My assumption is at some point in undertow wildfly code converts the hostname into a IPV6 adress.
*Other notes:*
• The issue is seen on the client side. The client is a java standalone client. The issue is seen under kubernetes.
• The issue is seen with the 19.0.1.Final wildfly-client-all jar. It is also seen with 18.0.0.Final wildfly-client-all jar. It looks to me like an issue in SNIHostName(destinationURI.getHost()) in UndertowXnioSsl.
• I can reproduce this issue with OpenJDK class SNIHostaneme with a local Junit using a IPV6 dummy adress [65:765]
{code:java}
public void testSNIHostName_Case_IPV6()
{
String hostname = "[65:765]";
SNIHostName sniHostname = new SNIHostName(hostname);
}
{code}
{noformat}
java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at java.net.IDN.toASCIIInternal(IDN.java:296)
at java.net.IDN.toASCII(IDN.java:122)
at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99){noformat}
*Logs*
What we see in the log file of the client:
{{2020-07-31 08:46:47,731 INFO [org.wildfly.naming] [RegistrationStateChangeNotification-pool-27-thread-1] WildFly Naming version 1.0.12.Final
2020-07-31 08:46:47,786 INFO [org.wildfly.security] [RegistrationStateChangeNotification-pool-27-thread-1] ELY00001: WildFly Elytron version 1.11.4.Final
2020-07-31 08:46:47,826 INFO [org.xnio] [RegistrationStateChangeNotification-pool-27-thread-1] XNIO version 3.7.7.Final
2020-07-31 08:46:47,837 INFO [org.xnio.nio] [RegistrationStateChangeNotification-pool-27-thread-1] XNIO NIO Implementation Version 3.7.7.Final
2020-07-31 08:46:47,868 INFO [org.jboss.threads] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss Threads version 2.3.3.Final
2020-07-31 08:46:48,004 INFO [org.jboss.remoting] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss Remoting version 5.0.17.Final
2020-07-31 08:46:48,045 INFO [org.jboss.ejb.client] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss EJB Client version 4.0.30.Final
2020-07-31 08:46:48,206 ERROR [com.application.lifecycle.internal.dataservice.ServiceImpl] [RegistrationStateChangeNotification-pool-27-thread-1] RemoteException while accessing ServiceRemote on cluster: Error; nested exception is:
java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
java.rmi.RemoteException: Error; nested exception is:
java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:219)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
at com.sun.proxy.$Proxy12.register(Unknown Source)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:41)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:38)
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:128)
at com.application.lifecycle.internal.dataservice.ServiceImpl.register(ServiceImpl.java:38)
at com.application.lifecycle.internal.model.BusinessTierClusterModelImpl.register(BusinessTierClusterModelImpl.java:94)
at com.application.lifecycle.internal.action.RegisterAction.execute(RegisterAction.java:51)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.service.message.DelegatingMessageReceiver.delegate(DelegatingMessageReceiver.java:68)
at com.service.message.DelegatingMessageReceiver.receive(DelegatingMessageReceiver.java:50)
at com.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
at com.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:450)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:416)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:333)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at java.net.IDN.toASCIIInternal(IDN.java:296)
at java.net.IDN.toASCII(IDN.java:122)
at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:434)
.. 4 more
2020-07-31 08:46:48,208 WARN [com.application.lifecycle.internal.action.RegisterAction] [RegistrationStateChangeNotification-pool-27-thread-1] Failed to register with business tier. Retrying in 10 seconds.
com.Exception: RemoteException while accessing ServiceRemote on cluster
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.handleRemoteException(AbstractStatelessRemoteServiceProxy.java:112)
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:130)
at com.application.lifecycle.internal.dataservice.ServiceImpl.register(ServiceImpl.java:38)
at com.application.lifecycle.internal.model.BusinessTierClusterModelImpl.register(BusinessTierClusterModelImpl.java:94)
at com.application.lifecycle.internal.action.RegisterAction.execute(RegisterAction.java:51)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.service.message.DelegatingMessageReceiver.delegate(DelegatingMessageReceiver.java:68)
at com.service.message.DelegatingMessageReceiver.receive(DelegatingMessageReceiver.java:50)
at com.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
at com.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.rmi.RemoteException: Error; nested exception is:
java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:219)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
at com.sun.proxy.$Proxy12.register(Unknown Source)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:41)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:38)
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:128)
.. 13 more
Caused by: java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:450)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:416)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:333)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at java.net.IDN.toASCIIInternal(IDN.java:296)
at java.net.IDN.toASCII(IDN.java:122)
at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:434)
.. 4 more}}
*Other information:*
Java version:
$ java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
Java arguments:
-Djava.net.preferIPv4Stack=false
tested also with this java arguments :
-Djava.net.preferIPv6Addresses=true
Wildfly server version:
WFLYSRV0049: WildFly Full 19.1.0.Final (WildFly Core 11.1.1.Final)
my-server corresponds to a kubernetes service which redirects to pod my-pod-hostname
In our environment we verified that we can curl between client pod and wildfly pod
>podA
curl -6 -k https://1234:ef7:.......:rt5:8443
curl -6 -k https://my-pod-hostname:8443
Welcome to wildfly
As far as we know the Kubernetes and pods are well configured in IPV6.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 12 months